|
Replies:
20
-
Last Post:
Nov 2, 2007 5:59 AM
by: Kleopatra
|
|
|
|
|
|
|
SwingX and third party LAFs
Posted:
May 31, 2007 8:06 PM
|
|
|
I've been making the second round of development of Substance plugin for SwingX, adding UI delegates JXHeader, JXLoginPanel, JXTipOfTheDay and JXTitledPanel, and there are some issues across the different components. Obviously, they have been written by different people, but it appears that the review process may lack some cross-component guidelines for developing the UI delegates.
Here are the areas, from less important to more important (for me as a LAF developer that needs to provide plugin for the SwingX components).
1. Consistent naming of the UIManager entries. Some components use three-part names (JXTitledPanel.title.font, JXLoginPanel.banner.darkBackground) and some use two-part names (TipOfTheDay.foreground, TaskPane.titleOver).
2. Some basic UI delegates don't have all the install / uninstall methods (should be six, two for defaults, two for listeners and two for components). This is not a good practice to follow - specifically for Substance i install animation listeners and other settings, and for some components i'm forced to do so in the installUI
3. Painting of the background. Taking the following five: BasicStatusBarUI, BasicHeaderUI, BasicLoginPanelUI, BasicMonthViewUI and BasicTitlePaneUI. Here is how they paint the background:
* Some provide the usual paint*Background - BasicMonthViewUI.paintMonthStringBackground and BasicStatusBarUI.paintBackground
* Some use painters - BasicHeaderUI.createBackgroundPainter and JXTitledPanel.title.painter UIManager entry
* Some use image - BasicLoginPanelUI.getBanner
The last one is the worst, since it's called before the component has parent and screen location, which severely limits the advanced capabilities (such as screen-bound watermarks, for example). The first one is OK, since it follows the usual core Swing UI delegate contracts. The second one is perhaps the best for SwingX, enforcing the use of painters while still combining the runtime power and flexibility. But even here, in some cases the painter is created in an API method, and in some cases the painter is set on the (non typesafe) UIManager.
Now that we have Synthetica and Substance providing UI delegates for SwingX, and Jasper has plans to provide full support in Nimbus, these issues should be addressed before the final release. While changing the existing contracts will affect the existing code (Synthetica and Substance), going forward (more third-party LAFs), this would be a correct decision.
I will gladly help in discussing the possible approaches in remedying the above and in reviewing the changes.
Thanks
Kirill
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 1, 2007 1:22 AM
in response to: kirillcool
|
|
|
|
|
While this may be slightly off topic I wrote an extension to the ComponentUI
class which can be found in my incubator that ensures that at least the
contract side of things (un/installXXX) is done properly (along with a
number of other fixes for problems not mentioned here). I posted a thread
about it a while ago but got no responses:
http://forums.java.net/jive/thread.jspa?messageID=212912
Personally I think this would help especially in the cases mentioned by
Kirill where the components are completely new.
What do you think?
[att1.html]
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 1, 2007 11:06 AM
in response to: kirillcool
|
|
|
Hey Matt/Kirill,
Thanks for bringing this up. Kirill, I'd be happy to follow your lead on this. Let me know the way you prefer it to be done, and why you prefer it that way, and I'll be happy to update the UI delegates to match.
I haven't enforced any guidelines on UIDelegates up to this point, but since as you point out Substance, Synthetica, Nimbus, and more will be supporting SwingX components, I'd like to improve this situation.
Richard
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 5, 2007 5:39 PM
in response to: rbair
|
|
|
Richard,
I've been thinking this over, and i think that i'd prefer the core way of doing things, namely paintBackground methods. There are two alternatives, images and painters, and both are at this point inferior to the usual core approach.
The image approach (as in LoginPanelUI) is by far the worst. You have to know the size in advance, recompute it on label change and on resolution change, and on top of that you can't provide advanced effects such as watermarking, animations etc.
The painter approach looks better than paintBackground() API when you look at the SwingX as a separate project that provides its own core UI delegates. However, in a broader context of third-party LAFs it's just an extra overhead. I can't speak for Synthetica and Nimbus (and other LAFs), but in Substance i have my own internal APIs to paint backgrounds. So, in order to provide a SwingX painter (such as in Header or TitledPanel), i'll have to create a painter that delegates back to my own core painting layer. The code becomes more complicated, and the performance doesn't get better (one extra level of call stack).
This might change in the future, when SwingX painters API is stabilized, moved to JDK and in general becomes accepted as a standard way to paint stuff. Until this happens in both JDK and in third-party LAFs, i think that it's better to have the traditional approach.
This doesn't mean that core SwingX delegates can't use painters as implementation of paintBackground. You can still continue creating the painters and call them in paintBackground, and we (third-party LAF developers) will use our own internal routines to paint the background of SwingX components.
The changes will be in the following places:
1. BasicHeaderUI and BasicTitledPanelUI to stop using painters. This is by far the trickiest ones, since you're just setting them on the matching JX components. Looking at the code, i will understand your decision to continue using painters for these classes. If you do, the other delegates (MonthViewUI, StatusBarUI, LoginPanelUI and TaskPaneUI) should start using painters as well.
2. BasicLoginPanelUI shouldn't use an image, and instead paint the background and foreground separately. Thinking about it - why doesn't it use a JXHeader? What's so different there?
Thanks
Kirill
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 11, 2007 1:29 PM
in response to: kirillcool
|
|
|
Kirill, et al.
I am doing some work on the JXLoginPanel and it would seem like a good time to tackle these L&F issues. Can you file bug reports for the problem areas?
Karl
|
|
|
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 14, 2007 7:53 AM
in response to: kirillcool
|
|
|
> 1. Consistent naming of the UIManager entries. Some components use three-part names
> (JXTitledPanel.title.font, JXLoginPanel.banner.darkBackground) and some use
> two-part names (TipOfTheDay.foreground, TaskPane.titleOver).
Any naming pattern preference?
> 2. Some basic UI delegates don't have all the install / uninstall methods (should be six, two for defaults,
> two for listeners and two for components). This is not a good practice to follow - specifically for
> Substance i install animation listeners and other settings, and for some components i'm forced to do
> so in the installUI
Ok, I'm looking at this ... started with BasicTitledPanelUI ... let me know if there are any problems ... I'll try to keep you posted on all the changes.
> 3. Painting of the background. Taking the following five: BasicStatusBarUI, BasicHeaderUI,
> BasicLoginPanelUI, BasicMonthViewUI and BasicTitlePaneUI. Here is how they paint the
> background:
LoginPanel is taken care of by Karl. For the I'll try to see whether I can come up with some combination of painters and paint*Background that would work well ... most likely following your suggestion of providing paint*Background and using painters to paint it there ... will see how this works.
Jan
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 14, 2007 3:44 PM
in response to: rah003
|
|
|
> > 1. Consistent naming of the UIManager entries. Some
> components use three-part names
> > (JXTitledPanel.title.font,
> JXLoginPanel.banner.darkBackground) and some use
> > two-part names (TipOfTheDay.foreground,
> TaskPane.titleOver).
>
> Any naming pattern preference?
It's usually ComponentName.PropertyName, so why reinvent the wheel and introduce three-part names?
> > 2. Some basic UI delegates don't have all the
> install / uninstall methods (should be six, two for
> defaults,
> > two for listeners and two for components). This is
> not a good practice to follow - specifically for
> > Substance i install animation listeners and other
> settings, and for some components i'm forced to do
> > so in the installUI
>
> Ok, I'm looking at this ... started with
> BasicTitledPanelUI ... let me know if there are any
> problems ... I'll try to keep you posted on all the
> changes.
Thanks, let me know when the changes are made so i can see and test them.
> > 3. Painting of the background. Taking the following
> five: BasicStatusBarUI, BasicHeaderUI,
> > BasicLoginPanelUI, BasicMonthViewUI and
> BasicTitlePaneUI. Here is how they paint the
> > background:
>
> LoginPanel is taken care of by Karl. For the I'll try
> to see whether I can come up with some combination of
> painters and paint*Background that would work well
> ... most likely following your suggestion of
> providing paint*Background and using painters to
> paint it there ... will see how this works.
Like i pointed out, in some cases that would be problematic, since some of the JX components have a background painter functionality. For these, the UI delegate simply installs a UI-specific painter which then gets called by the SwingX internals. In such a case, it's perhaps better to leave the current model.
By the way, a UI delegate should check if the current painter is UIResource. If it's not, then it's a painter that has been set explicitly by the application and should not be changed.
Thanks
Kirill
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 15, 2007 2:24 AM
in response to: kirillcool
|
|
|
Would someone like to volunteer to document these rules/conventions
once the decisions have been made? Could go on
http://wiki.java.net/bin/view/Javadesktop/SwingLabsSwingX
or a sub-page.
We already have some coding conventions written down, this would be a
good (and useful) extension to our documentation.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 19, 2007 12:38 AM
in response to: kirillcool
|
|
|
> > > 1. Consistent naming of the UIManager entries.
> Some
> > components use three-part names
> > > (JXTitledPanel.title.font,
> > JXLoginPanel.banner.darkBackground) and some use
> > > two-part names (TipOfTheDay.foreground,
> > TaskPane.titleOver).
> >
> > Any naming pattern preference?
>
> It's usually ComponentName.PropertyName, so why
> reinvent the wheel and introduce three-part names?
>
I have changed naming to 2-part for JXTitledPanel ... you might want to update all of your dependencies.
I've also fixed #502 - you can now configure insets for both caption and surrounding decoration.
Last but not least I've fixed gradient painting that was broken since painter overhaul job.
Let me know if there is anything else on JXTitledPanel before I move on another one.
cheers,
Jan
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 19, 2007 2:19 AM
in response to: rah003
|
|
|
Thank you for fixing all relevant issues - for me it works fine now.
Wolfgang
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 19, 2007 8:59 AM
in response to: rah003
|
|
|
Works for me as well, including the new naming for the UIManager keys and the LAF switch.
Thanks
Kirill
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 19, 2007 9:15 AM
in response to: kirillcool
|
|
|
All right then. I'll move on the next one then.
I thought it would be "consistent use of painters across UI delegates", but if there is anything more nagging ... speak now or forever hold your peace  ... meaning - I'm open to suggestions as always.
Jan
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Nov 1, 2007 10:00 AM
in response to: kirillcool
|
|
|
> > > 1. Consistent naming of the UIManager entries.
> Some
> > components use three-part names
> > > (JXTitledPanel.title.font,
> > JXLoginPanel.banner.darkBackground) and some use
> > > two-part names (TipOfTheDay.foreground,
> > TaskPane.titleOver).
> >
> > Any naming pattern preference?
I created bug 629 for addressing the remaining three-part names in the addons.
The following properties have been changed as a result:
JXDatePicker.arrowDown.image > JXDatePicker.arrowIcon
JXLoginPanel.error.icon > JXLoginPanel.errorIcon
JXLoginPanel.banner.font > JXLoginPanel.bannerFont
JXLoginPanel.banner.foreground > JXLoginPanel.bannerForeground
JXLoginPanel.banner.darkBackground > JXLoginPanel.bannerDarkBackground
JXLoginPanel.banner.lightBackground > JXLoginPanel.bannerLightBackground
I did not address any name that come from resource bundles. There are still plenty of three-part names there.
Karl
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Nov 1, 2007 2:45 PM
in response to: kschaefe
|
|
|
Thanks. I'll try it out the week of November 12th after Substance 4.1 is released and i start working on 4.2
Kirill
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Nov 2, 2007 5:12 AM
in response to: kschaefe
|
|
|
not really related to this - but anyway, taking the opportunity...
we still have some naming-convention violations (though we had an open
issue about it, but can't find it right now) which bug: the use of "JX"
for non-components. This applies for all component-specific YYAddOns
and (eeekk!) JXDatePickerFormatter
I would suggest to rename (drop at least the J, maybe the X as well) to
comply with conventions.
Thoughts?
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Nov 2, 2007 5:39 AM
in response to: Kleopatra
|
|
|
I think the JX prefix is a known, but undocumented issue. We also have the Aqua -> MacOS issues for the popup fix. We might as well take a whack at these now. We have to do it sooner or later.
Do you want to file an issue for the JX-rename stuff?
Karl
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Nov 2, 2007 5:59 AM
in response to: kschaefe
|
|
|
jdnc-interest@javadesktop.org schrieb:
> I think the JX prefix is a known, but undocumented issue. We also have the Aqua -> MacOS issues for the popup fix. We might as well take a whack at these now. We have to do it sooner or later.
>
> Do you want to file an issue for the JX-rename stuff?
>
done
https://swingx.dev.java.net/issues/show_bug.cgi?id=631
forgot to assign it to you, grab it - pleeease ;.)
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 15, 2007 3:25 AM
in response to: rah003
|
|
|
For JXTitledPanel/BasicTitledPanelUI I've already filled in some bug reports (including bugfix proposals) which are still open. Please take a look at issue 500, 501, 502.
I've also posted some other issues which cause problems on LAF change but unfortunately nobody takes care about...
Thanks,
Wolfgang
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 15, 2007 4:56 AM
in response to: wzberger
|
|
|
> For JXTitledPanel/BasicTitledPanelUI I've already
> filled in some bug reports (including bugfix
> proposals) which are still open. Please take a look
> at issue 500, 501, 502.
>
> I've also posted some other issues which cause
> problems on LAF change but unfortunately nobody takes
> care about...
Thanks Wolfgang. I'll have a look.
Jan
|
|
|
|
|
|
|
|
|
Re: SwingX and third party LAFs
Posted:
Jun 15, 2007 8:52 AM
in response to: rah003
|
|
|
#500 & #501 should be fixed now. Give it try and let me know.
|
|
|
|
|
java.net RSS
