> It seems to boil down to the fact that unlike the DOM in a browser
> it's really hard to know when a widget is added/removed from the
> hierarchy... and as a bonus, there can be multiple hierarchies at the
> same time.

Yes, it seems that things are a bit more uncertain in Swing. Although,
now that I think about it, you can manipulate the DOM at your heart's
content, and the style will remain consistent. I may be missing
something here, maybe there is a good way to do this, but it's not
obvious to me. I suspect the solution would involve maintaining extra
information about what style rule has been applied to which
element/component etc, how to reverse it etc. Not trivial at all.

> I wonder if you could use the ContainerListener approach, but queue up
> all of the changes and then apply them all at once with invokeLater or
> something. That would (mostly) eliminate duplicate applications of the
> stylesheet.

I did think of implementing a simplified version of what you're
describing by providing automatic stylesheets that are only applied
when a java.awt.Window is made visible (setVisible(true)). But what if
a window is being re-used and it's just hidden when it's not
necessary. Maybe I could have a flag that ensures that it's applied
only once.

But... there is also the fact that clarity allows you to modify the
"categories" that a component belongs to ("categories" are meant to be
used in the same way as the class in HTML/CSS). With CSS, if you
modify the classes of a DOM element, the correct style (and therefore
look) is applied automatically. This is something I would like to
implement in Clarity, but I think it would take a lot of careful
planning not to mess this up.

>> The problem with this solution is that it has the potential to result
>> in the same stylesheet being applied to the component more than once
>> (although now that I think about it, maybe not). This should never
>> happen, because styles in clarity are just a bunch of "mutators",
>> basically a bit of code that can contain anything (for example a
>> "style" could add a listener that changes the background on mouse
>> over) and definitely has side-effects, so "applying" it twice to a
>> component could have unforeseen and hard to debug consequences.
>
> Yep. It seems like it's best to have the requirement that styles be
> idempotent so applying them multiple times won't hurt anything.

I can see how this would make things simpler, but there is no way to
enforce this (unless I use some carefully controlled syntax for the
stylesheets, which I'm reluctant to implement). Also, it removes the
opportunity to create a style that says "matching components should
have a blue background which should turn to red when the mouse moves
over them". Unless I tag some listeners with meta-data flagging them
as originating from the stylesheet, but then I would probably have to
keep track of which rule it was that added the listener, so that if a
subsequent application of the stylesheet a different rule matches this
rule also has to be applied etc. As you can see, this can become a
huge can of worms that is partly because I'd like to make stylesheets
respond to state (changes in the categories of components), and partly
because it's just a hard problem!

>> Does that make sense?
>
> Yep. Thanks!

It really helps me talking things through :-)