|
Replies:
22
-
Last Post:
Apr 18, 2006 1:12 PM
by: mgrev
|
|
|
|
|
|
|
Painters in SwingX (and possibly Swing)
Posted:
Mar 29, 2006 11:11 AM
|
|
|
Hi,
(Regarding a little discussion with Romain about whether to have one painter in a component or a number of them...)
Is there any idea to discuss this or have you made up your mind to use the "one"-version?
I write because our component uses Painters a lot (for everything actually, but we call them Decorators) and I suggest you would use:
comp.addPainter(Painter p, int layer)
comp.removePainter(Painter p)
instead of just:
comp.setPainter(Painter p) // (which could be a CompositePainter of course).
But, I'm not going to write if this has been decided or will not matter for the possible Swing JDK inclusion.
Cheers,
Mikael Grev
www.migcalendar.com
Message was edited by: mgrev
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 29, 2006 1:19 PM
in response to: mgrev
|
|
|
Hey Mikael,
I'm pretty biased towards the CompoundPainter approach for a couple of reasons, but I'm definitely open to use cases that I might not have thought of.
Here are some of the reasons I like the CompoundPainter coupled with setPainter (some of these could still be used if there was an addPainter/removePainter API):
* Simple JavaBeans property -- easier to use in a builder 
* CompoundPainter gives us an object to hang effects on, such that all painters within the CompoundPainter will have the effects applied once at the end (this motiviates the need for CompoundPainter, regardless of the API on JXPanel)
* add/remove methods require the developer to maintain state -- they can more easily get tripped up by removing painters that aren't in there, etc
* A CompoundPainter that has add/remove properties could easily be added without losing any of the advantages of abstracting this out
* The implementation is simplier since I don't have to know about multiple painters in the component
* I may want to add a setRolloverPainter, setFocusedPainter, etc to JXPanel and/or other components. This API is simplier and clearer without the add/remove methods
This last point shows the difference in the two approaches, I think. If add/remove methods were on the component, then the mouseListener logic would modify the painter list on the component. If instead I stick with setPainter(), then I can either:
* add setRolloverPainter()
- or -
* write my mouse listener so that it installs a new Painter on mouse over, etc
This second approach has the benefit of making state management easier. That is, I'd create two different Painters (perhaps two different CompoundPainters) for th two different states (normal, rollover) and then swap which one to use. I don't have to know what the exact Painter hierarchy structure is, I can just swap and go.
I'd like to hear what kind of use cases you have though, and why you prefer the add/remove method approach. Are you often swapping the Painters at runtime?
Cheers
Richard
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 3:52 AM
in response to: rbair
|
|
|
Richard,
I think the part that your approach is a JavaBean property is the most interesting one. Though it only matters if it actually can be used in a RAD the way it is intended. For this to work the Painters need to be JavaBeans as well. If not, people still need to manually create the painter and then it is simpler to set it by code directly instead of going over to the "visual" environment to set it. So this is a good point but since for instance it's hard to make a ImagePainter a full JavaBean (since the image can be set as a property on it) this point is maybe mostly good in theory, but won't be used in practice. IMO.
Here are a few reasons to do it the addPainter/removePainter approach.
Decoupling.
You never have to play nice with any other parts of your application. One part can add/remove a painter that does something and another part can add/remove some other painter without breaking anything. The worst thing that could happen is that they get the wrong layering (the wrong one shows up on top). This is especially important if you write components and the user of your components might install painters that you can't control.
Say for instance you want to (in v2.0 of your component) add validation and paint the validation icon in a top layer painter. If the user(s) of your component have decorated your component with say a GlossPainter you're in trouble. You will either replace his painter (bugg) or you can wrap it in a CompoundPainter with your own Validationpainter. The problem with the latter approach is that the user will now get a CompoundPainter back when he expect a GlossPainter (also a bugg).
With the add approach you can always install new painters that live together with other painters.
Ease of use.
comp.addPainter(..) and comp.setPainter(..) has about the same difficulty to users.
comp.addPainter(new Painter1(), 100);
comp.addPainter(new Painter2(), 120);
is simpler than
CompoundPainter compoundPainter = CompoundPainter(new Painter1(), new Painter2());
comp.setPainter(compoundPainter);
though, at least for newbies.
Working with the current framework.
The current background, border, content and foreground paints can be defined in standard layers. They can even be extended without API changes in the future. A lot of paint layers can be defened, losley, without cluttering the API with set/getXxxxPainter(). It would for instance be possible to paint "between" the grid and the CellRenderers in a later release of J(X)Table without API changes.
List is simpler and more common than Tree.
add/remove is a List where optionally every element can be a Tree. get/set will always be a potential Tree with is harder to iterate. Take the use case where you want to replace your painter, maybe because you have it immutable. In a tree where you aren't in 100% control of the painters this is actually impossible since someone might have created their own Compond2Painter which wraps yours. You can never replace that, or even remove it from the component. With the add/remove approach you always knows (within reason) that you painter is in the list and you can find it and replace/remove it. This is very important if you are a 3:rd party component creator or if you are more than one that is "decorating" a component.
Flexibility.
You know you have a list of Painters and an interface to that list you can count on. If you use a ComponetPainter or ListPainter you must rely on instanceof and hope you know about the list interface for the List/CompoundPainter. In an environment where you have little control over all painters this can not be done is a clean way.
You can still use a Compound/ListPainter of course, you just have to hold on to its reference.
Comments to your list:
> Simple JavaBeans property -- easier to use in a builder
The JavaBean spec 1.01 has indexed properties so this wouldn't be a problem spec-wise. I know that IDEs aren't very supportive of this feature thoug and since I'm an Expert on JSR-273 I can say that the indexed spec will not improve or be improved, much to my dislike. So this boils down to if all painters will be written and true JavaBeans and how much this impact will have in the real world. If an IDE vendor wants it could be extremely simple to support the add/remove paradigm as well. But you have a good point here (but only if there are a lot of setXxxPainter() and a quite a few of those open to freely add painters to (e.g. always left empty by the compoent cretors).
> CompoundPainter gives us an object to hang effects on, such that all painters within the CompoundPainter will have the effects applied once at the end (this motiviates the need for CompoundPainter, regardless of the API on JXPanel)
True. But to do this you will have to wrap it and thus change the type of the Painter which the original painter setter might not expect and we have a class missmatch exception on our hands. The original painter can never again be removed or replaced.
The same thing, with the same disadvantages though, can be done with add/remove. You just remove all painters and wrap them. Same thing, one more line, but I admit, slight more "unclean".
> add/remove methods require the developer to maintain state -- they can more easily get tripped up by removing painters that aren't in there, etc
True. But since Component are using the add/remove paradigm I'd expect this to be a smaller problem.
> A CompoundPainter that has add/remove properties could easily be added without losing any of the advantages of abstracting this out
Commented above.
> The implementation is simplier since I don't have to know about multiple painters in the component
I can send you our's. Seriously though, managing a list of painters and paint them in order is not that hard.
> I may want to add a setRolloverPainter, setFocusedPainter, etc to JXPanel and/or other components. This API is simplier and clearer without the add/remove methods.
Commented above. API cluttering and harder to extend.
There was more things that I thougt of last night but I can't remember now. If I do I'll add it later.
Cheers,
Mikael Grev
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 4:00 AM
in response to: mgrev
|
|
|
"this point is maybe mostly good in theory, but won't be used in
practice. IMO."
Wrong. We are working on a providing a full blown Painters editor.
>comp.addPainter(new Painter1(), 100);
>comp.addPainter(new Painter2(), 120);
>is simpler than
>CompoundPainter compoundPainter = CompoundPainter(new Painter1(), new
>Painter2());
>comp.setPainter(compoundPainter);
I strongly disagree. To me, 100 and 120 have no meaning. And even when
you use constants like JLayeredPane does you end up having magic number
that you need to know throughout the application.
>Seriously though, managing a list of painters and paint them in order
>is not that hard.
It's not hard. It's harder.
We get hit all the time because Swing is too complicated so for once we
decided to go with a simple approach. Sure it's a bit less versatile
when you want to do crazy stuff with your painters (even though I still
need to see use cases) but I think hard things should be hard to do and
simple things easy to do, rather than both being equally difficult.
jdnc-interest@javadesktop.org wrote:
> Richard,
>
> I think the part that your approach is a JavaBean property is the most interesting one. Though it only matters if it actually can be used in a RAD the way it is intended. For this to work the Painters need to be JavaBeans as well. If not, people still need to manually create the painter and then it is simpler to set it by code directly instead of going over to the "visual" environment to set it. So this is a good point but since for instance it's hard to make a ImagePainter a full JavaBean (since the image can be set as a property on it) this point is maybe mostly good in theory, but won't be used in practice. IMO.
>
> Here are a few reasons to do it the addPainter/removePainter approach.
>
> Decoupling.
> You never have to play nice with any other parts of your application. One part can add/remove a painter that does something and another part can add/remove some other painter without breaking anything. The worst thing that could happen is that they get the wrong layering (the wrong one shows up on top). This is especially important if you write components and the user of your components might install painters that you can't control.
>
> Say for instance you want to (in v2.0 of your component) add validation and paint the validation icon in a top layer painter. If the user(s) of your component have decorated your component with say a GlossPainter you're in trouble. You will either replace his painter (bugg) or you can wrap it in a CompoundPainter with your own Validationpainter. The problem with the latter approach is that the user will now get a CompoundPainter back when he expect a GlossPainter (also a bugg).
>
> With the add approach you can always install new painters that live together with other painters.
>
> Ease of use.
> comp.addPainter(..) and comp.setPainter(..) has about the same difficulty to users.
>
> comp.addPainter(new Painter1(), 100);
> comp.addPainter(new Painter2(), 120);
>
> is simpler than
>
> CompoundPainter compoundPainter = CompoundPainter(new Painter1(), new Painter2());
> comp.setPainter(compoundPainter);
>
> though, at least for newbies.
>
> Working with the current framework.
> The current background, border, content and foreground paints can be defined in standard layers. They can even be extended without API changes in the future. A lot of paint layers can be defened, losley, without cluttering the API with set/getXxxxPainter(). It would for instance be possible to paint "between" the grid and the CellRenderers in a later release of J(X)Table without API changes.
>
> List is simpler and more common than Tree.
> add/remove is a List where optionally every element can be a Tree. get/set will always be a potential Tree with is harder to iterate. Take the use case where you want to replace your painter, maybe because you have it immutable. In a tree where you aren't in 100% control of the painters this is actually impossible since someone might have created their own Compond2Painter which wraps yours. You can never replace that, or even remove it from the component. With the add/remove approach you always knows (within reason) that you painter is in the list and you can find it and replace/remove it. This is very important if you are a 3:rd party component creator or if you are more than one that is "decorating" a component.
>
> Flexibility.
> You know you have a list of Painters and an interface to that list you can count on. If you use a ComponetPainter or ListPainter you must rely on instanceof and hope you know about the list interface for the List/CompoundPainter. In an environment where you have little control over all painters this can not be done is a clean way.
>
> You can still use a Compound/ListPainter of course, you just have to hold on to its reference.
>
> Comments to your list:
>
>> Simple JavaBeans property -- easier to use in a builder
>
> The JavaBean spec 1.01 has indexed properties so this wouldn't be a problem spec-wise. I know that IDEs aren't very supportive of this feature thoug and since I'm an Expert on JSR-273 I can say that the indexed spec will not improve or be improved, much to my dislike. So this boils down to if all painters will be written and true JavaBeans and how much this impact will have in the real world. If an IDE vendor wants it could be extremely simple to support the add/remove paradigm as well. But you have a good point here (but only if there are a lot of setXxxPainter() and a quite a few of those open to freely add painters to (e.g. always left empty by the compoent cretors).
>
>> CompoundPainter gives us an object to hang effects on, such that all painters within the CompoundPainter will have the effects applied once at the end (this motiviates the need for CompoundPainter, regardless of the API on JXPanel)
>
> True. But to do this you will have to wrap it and thus change the type of the Painter which the original painter setter might not expect and we have a class missmatch exception on our hands. The original painter can never again be removed or replaced.
>
> The same thing, with the same disadvantages though, can be done with add/remove. You just remove all painters and wrap them. Same thing, one more line, but I admit, slight more "unclean".
>
>> add/remove methods require the developer to maintain state -- they can more easily get tripped up by removing painters that aren't in there, etc
>
> True. But since Component are using the add/remove paradigm I'd expect this to be a smaller problem.
>
>> A CompoundPainter that has add/remove properties could easily be added without losing any of the advantages of abstracting this out
>
> Commented above.
>
>> The implementation is simplier since I don't have to know about multiple painters in the component
>
> I can send you our's. Seriously though, managing a list of painters and paint them in order is not that hard.
>
>> I may want to add a setRolloverPainter, setFocusedPainter, etc to JXPanel and/or other components. This API is simplier and clearer without the add/remove methods.
>
> Commented above. API cluttering and harder to extend.
>
> There was more things that I thougt of last night but I can't remember now. If I do I'll add it later.
>
> Cheers,
> Mikael Grev
> [Message sent by forum member 'mgrev' (mgrev)]
>
> http://forums.java.net/jive/thread.jspa?messageID=98637
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://weblogs.java.net/blog/gfx/
http://www.progx.org
http://www.jext.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 5:08 AM
in response to: Romain Guy
|
|
|
Romain Guy wrote:
Just a comment - not about the painters but about simplicity:
>
> We get hit all the time because Swing is too complicated so for once we
> decided to go with a simple approach. Sure it's a bit less versatile
> when you want to do crazy stuff with your painters (even though I still
> need to see use cases) but I think hard things should be hard to do and
> simple things easy to do, rather than both being equally difficult.
>
Instead of your guideline (freely paraphrased) - "hard is hard anyway,
so make at least the simple easy", I prefer to follow JGoodies mantra,
which is :
"[..] makes simple things easy and the hard stuff possible".
Concentrating too much on simplicity might seriously hinder the
usefulness in more complex tasks. Naturally, the weighing is a walk on
the tight rope 
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 5:11 AM
in response to: Kleopatra
|
|
|
That's actually closer to what I think (I have to admit that around 4am
I have hard time phrasing my thoughts in english , thanks for this
nice quote from JGoodies!
Kleopatra wrote:
> Romain Guy wrote:
>
> Just a comment - not about the painters but about simplicity:
>
>>
>> We get hit all the time because Swing is too complicated so for once
>> we decided to go with a simple approach. Sure it's a bit less
>> versatile when you want to do crazy stuff with your painters (even
>> though I still need to see use cases) but I think hard things should
>> be hard to do and simple things easy to do, rather than both being
>> equally difficult.
>>
>
> Instead of your guideline (freely paraphrased) - "hard is hard anyway,
> so make at least the simple easy", I prefer to follow JGoodies mantra,
> which is :
>
> "[..] makes simple things easy and the hard stuff possible".
>
> Concentrating too much on simplicity might seriously hinder the
> usefulness in more complex tasks. Naturally, the weighing is a walk on
> the tight rope
>
> Jeanette
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://weblogs.java.net/blog/gfx/
http://www.progx.org
http://www.jext.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 6:55 AM
in response to: Romain Guy
|
|
|
Use case #1:
You want to paint an error icon over the textfield when it contains "XXX".
How would you write that code?
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 9:30 AM
in response to: mgrev
|
|
|
Hey Mikael,
> For this to work the Painters need to
> be JavaBeans as well.
There are actually two parts here to supporting these as JavaBeans. First, we do actually have BeanInfos for about half of the Painters, and I'm working on them for the other half. The goal is that they will, indeed, be JavaBeans. Second, as Romain mentioned, we are working on a full blown (really cool) editor for Painters.
IconPainter won't be a problem because ide's all have support for Icon (thanks the JLabel, etc, they have to support it). So I don't foresee a problem there. ImagePainter is definitely worse, but I'd take the same approach as the IDE's do with Icons -- provide an editor that looks on the classpath/url/etc to find the image to load and then use ImageIO to read the image and set it on the bean. I haven't done it yet, so I don't know what problems I'm likely to run into, but it seems like it should work.
> Here are a few reasons to do it the
> addPainter/removePainter approach.
>
> Decoupling.
> You never have to play nice with any other parts of
> your application. One part can add/remove a painter
> that does something and another part can add/remove
> some other painter without breaking anything. The
> worst thing that could happen is that they get the
> wrong layering (the wrong one shows up on top). This
> is especially important if you write components and
> the user of your components might install painters
> that you can't control.
Ok, I didn't catch this from the previous post. I assumed (wrongly) that "layer" was "index". More in a minute.
> future. A lot of paint layers can be defened, losley,
> without cluttering the API with set/getXxxxPainter().
> It would for instance be possible to paint "between"
> the grid and the CellRenderers in a later release of
> J(X)Table without API changes.
The main point you are raising here isn't in the Painter API, but in the JXPanel API, right? There's nothing wrong with CompoundPainters or any of that stuff. The main point of contention here is about JXPanel. Basically, is:
setBackgroundPainter(Painter)
setForegroundPainter(Painter)
setGlassPaneLikePainter(Painter)
etc better or worse than
addPainter(Painter, int layer)
There are advantages and disadvantages on both sides. I'll list them, and then suggest we can do both, perhaps.
setXXX Advantages:
* Simple JavaBeans property
* Easy for developers to find -- matches the task oriented mental model
* Simple concepts -- set a painter. Layers are explicit in the function names
* Clear and unambiguous as to what will happen if two painters are at the same "level". The new one will replace the old one
setXXX Disadvantages:
* Multiple painters must *always* be wrapped, which makes it more difficult for the usecase you mentioned with validation
* More API (whether it is clutter or not is debatable:))
addPainter Advantages:
* Allows arbitrary code to insert a painter into the heirarchy
* Less API
* Painters don't *have* to be wrapped. I'd still want to if I wanted effects associated with a subset of the Painters, but I'm not required to wrap everything.
addPainter Disadvantages:
* API doesn't naturally define what happens if two Painters are inserted at the same level
* Due to the above point, you cannot pick a reasonable layer to insert your item into knowing it won't cause a collision -- the likelyhood of collision is small, but definitely possible.
* Not sure how to handle this via JavaBeans (still feeling the edges of the spec)
Now, there is nothing which says we couldn't actually do both. There's no reason that setBackgroundPainter couldn't simply shove the given painter into the well defined location in the layers and be happy. Inserting a Painter at some custom layer will always replace what is there.
I have a really uneasy feeling over the first and second bulleted items under addPainter disadvantages, though. I realize that practically speaking it isn't that big a deal, but it still makes me feel uneasy.
Part of this uneasiness comes from the use case you mentioned. Briefly (to make sure we are on the same page), what if I(speaking as if I were the databinding machinery) wanted to paint some special marker on the "Glass" layer indicating validation state? I would create my validation Icon, load it into an Icon painter, set it to be in the bottom right corner (or someplace) and then... insert it at what layer? What if the application was already using the "Glass" layer? Do I just replace it? I must, it seems. Or do I start searching above that layer for the first open layer?
It just starts to get a little dicey. But I don't have any counter solution right now. You could use borders or the glass pane, maybe. I'll have to think on it.
Richard
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 12:55 PM
in response to: rbair
|
|
|
Richard,
I think we are 100% on the same page since I would write the same advantage/disadvantage list. Your suggestion to include both approaches is very compelling and when I come to think about it, it actually has all the advantages and the down sides can be removed, if we just can define how the approaches should interact. IMO.
How about this for starters:
If you SET a painter you will replace the painter SETted with that method before it, but nothing else.
The SET API methods (such as setBackgroudPainter()) has layers (int) logically attached to them. Say 100, 200 and 300 (for Bg, Fg and Glass) or whatever and this is clearly stated in the JavaDoc. This is something one would only have to care about if using the ADD methods though (which means it won't complicate things for the bean users).
If using ADD you can never replace anything, not even if you add on a layer specified above.
If two ADDed painters get the same layer the later added is painted on top (later). This is logical if you think of the natural sorting and is easily implemented by just using a stable soring algorithm over the Painters collection.
If ADDed painters have the same layer as the SETed ones the ADDed are painted on top. Mainly since that is probably what the user is expecting and it defeats bug reports of the type: "I do comp.addPainter(new MyPainter(), 100) but nothing shows!!".
For me what's above is the natural way and how I would expect things to work. The implementation is IMO trivial.
A note on the layer clash problem. The only thing that would happen if people accidentally added two painters to the same layer is a visual glitch, which is not that severe, the app will still run. If on the other hand someone tried to make the same thing with Compounding an unknown painter you might get a ClassCastException when the user tries to re-get it and cast it to -his- Painter type. That would mean the Component wouldn't work at all.
To address your last concern regarding the validation icon. Something like:
addPainter(new ValidationPainter(), 350);
or
addPainter(new ValidationPainter(), Component.GLASS_LAYER);
or
addPainter(new ValidationPainter(), Component.GLASS_LAYER + 50);
or
addPainter(new ValidationPainter(), Integer.MAX_VALUE);
All which would work. The difference is in style, how clear you want to be and how sure you are you want to be "on-top". All you need to do this is to look at the JavaDoc for addPainter() OR addGlassPanePainter().
I have mentioned Painters to Scott a about a year ago and he said they where thinking about it, and had been for a while. Please make sure he sees this thread.
Cheers,
Mikael
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Apr 14, 2006 11:19 AM
in response to: mgrev
|
|
|
Hey Mikael,
Good list. Can you write up some proposed API/JavaDoc for this?
Thanks!
Richard
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Apr 16, 2006 6:21 PM
in response to: rbair
|
|
|
Richard,
I'll try to cook something up. Should I e-mail it to you?
Cheers,
Mikael
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Apr 17, 2006 9:48 AM
in response to: mgrev
|
|
|
Hey Mikael,
I think I've gotten a signed JCA from you, right? If so, the best thing to do would be to get commit access to the incubator and submit the code there. That way people can get access to it and see what's happening. If you haven't signed the JCA, its best to get it here: https://swinglabs.dev.java.net/documentation/JDNC_JCA.pdf, and then just email it to my sun email.
Richard
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Apr 18, 2006 1:11 PM
in response to: rbair
|
|
|
Hi Richard,
I'm 100% novice when it comes to OSS development, "commit access" and CVS (I use Subversion with IDEA..). But I'll do my best.
Yes, I've signed the JCA. (For the EA work in JSR 273, but I guess it's the same?)
Cheers,
Mikael
Btw, do you know if there is any way to change the email address that gets notifications about posts here? I don't have that grev@telia.com account any more...
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 5:37 AM
in response to: mgrev
|
|
|
And what about a LayeredPainter that would have the API proposed by Mikael? Thus simple things would remain easy and complex things would be definitely possible.
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 6:59 AM
in response to: gfx
|
|
|
Do you mean that all Painters should be layearable? Otherwise I see no difference between LayeredPainter and CompoundPainter, but I may be missing the point?
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 8:53 AM
in response to: mgrev
|
|
|
> Do you mean that all Painters should be layearable?
> Otherwise I see no difference between LayeredPainter
> and CompoundPainter, but I may be missing the point?
>
Earlier when designing I was talking with Scott about the problem (more for what we'd do in Swing than SwingLabs) and we talked about the "zorder" phenomenon. Basically, duplicate what JLayeredPane does.
There are some definitely advantages *if* the components know the difference between background and foreground. Otherwise it becomes less convincing (not saying there isn't a point, just that it becomes harder to convince).
Meanwhile, we have Painter and CompoundPainter, and could have LayeredPainter which would be like CompoundPainter but have layers. That may not satisfy your requirement, but it would work, and that is what Romain is referring to, I believe.
The only difference is how they do their job. Compound just takes an array, end of story.
Just for the record, all designs discussed so far have some element of nastiness involved.
I'll address the other points in a separate message.
Richard
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 10:57 AM
in response to: mgrev
|
|
|
I did not say ALL painters. I said ONE painter could be layerable. Like
Compound is special.
jdnc-interest@javadesktop.org wrote:
> Do you mean that all Painters should be layearable? Otherwise I see no difference between LayeredPainter and CompoundPainter, but I may be missing the point?
> [Message sent by forum member 'mgrev' (mgrev)]
>
> http://forums.java.net/jive/thread.jspa?messageID=98698
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://weblogs.java.net/blog/gfx/
http://www.progx.org
http://www.jext.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 7:55 AM
in response to: mgrev
|
|
|
Can someone give a brief description of Painters and how they affect or interact with the components UI delegates? Are there any concerns with affecting the L&F, for example?
Thanks
Erik
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 8:56 AM
in response to: evickroy
|
|
|
Hey Erik,
> Can someone give a brief description of Painters and
> how they affect or interact with the components UI
> delegates? Are there any concerns with affecting the
> L&F, for example?
Painters are simply painting delegates. The classes are all found in org.jdesktop.swingx.painter. So, if a backgroundPainter is set on a JXPanel, then instead of painting its own background, the panel will delegate to the painter to do the job.
What the Painter does is up to the painter. For example, you could have a ComponentPainter that simply calls "paintComponent", thus delegating -back- to the component (there are times you want this, for example if you want to paint the normal LAF code and then put a motion blur on it). Or you could use a BasicGradientPainter and have a gradient for your background, no LAF involved.
Right now this is only on Panels. The point is to avoid having to subclass to paint special effects.
Richard
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Mar 30, 2006 2:00 PM
in response to: rbair
|
|
|
Thanks for the info Richard!
So for SwingX components, you could use a JXPainter to bypass or extend the "Look" of a component?
Thanks again
Erik
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Apr 14, 2006 11:19 AM
in response to: evickroy
|
|
|
Hey Erik,
> So for SwingX components, you could use a JXPainter
> to bypass or extend the "Look" of a component?
It depends. In the case of JXPanel, setting the background painter will bypass the look of the component. In the case of JXTitledPanel, the header background is specified as a painter, so it is both a part of the natural LAF mechanism for that component, as well as a way to override/bypass the laf.
At the heart, Painter is just a delegate mechanism. It can be used as either a bypass mechanism (as is the case for JXPanel), or as a natural part of the LAF (as is the case with the JXTitledPanel).
CHeers
Richard
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Apr 14, 2006 1:19 PM
in response to: rbair
|
|
|
Richard,
> At the heart, Painter is just a delegate mechanism.
> It can be used as either a bypass mechanism (as is
> the case for JXPanel), or as a natural part of the
> LAF (as is the case with the JXTitledPanel).
So as a custom L&F author, will Painters cause problems for me creating custom delegates for SwingX components? That' my biggest fear. It should be just as easy to create custom UI delegates for SwingX components as it is to create them for the standard Swing components.
Thanks
Erik
|
|
|
|
|
|
|
|
|
Re: Painters in SwingX (and possibly Swing)
Posted:
Apr 14, 2006 1:34 PM
in response to: evickroy
|
|
|
> So as a custom L&F author, will Painters cause
> problems for me creating custom delegates for SwingX
> components? That' my biggest fear. It should be
> just as easy to create custom UI delegates for SwingX
> components as it is to create them for the standard
> Swing components.
No, it won't change anything for you. Its the same as if somebody took a JXPanel, overrode it, and then put in their own custom painting code (which totally bypasses the look and feel).
Richard
|
|
|
|
|
java.net RSS
