|
Replies:
17
-
Last Post:
Sep 20, 2007 2:46 AM
by: osbald
|
|
|
|
|
|
|
Req: For flat toolbar buttons
Posted:
Sep 18, 2007 4:39 AM
|
|
|
Just trying to work out how to do this myself as much as asking if we've already got components like this anywhere. I've got a need for something like JToggleButton, but for use in a toolbar (or a titledpanel decoration so alpha-painter support would be handy). But I'd rather not have the button decoration in this case (yucky and dated?). Just the selected/unselected state and possibly a rollover. These properties seem to be used by a couple of delegates while the BasicToggleButtonUI isn't fully functional by itself.. which seems both a bit odd and quite awkward for my first idea.
I then wondered if I can't use a JXButton as a base component with a background painter ~ which should null out the delegate painting if I understand the javadoc. Although this too seems to depend on LAF, setting a background painter seems to remove the button decorations for WindowsPLAF, but not Metal/Ocean to get rid of those setBorderPainted(false) seems to work - but the reverse dosn't hold true for WindowsPLAF?? who is correct here?
JXButton still isnt quite right. I'd need to make some of the 'optional' rollover & selected painting more explict. Although I plan to have a mix of toogle and normal push button icons/labels in my toolbar. Could get so far with JXHyperLinks too.. hmmm. Can't quite decide if this is a component issue or purely a ui delegate/PLAF one.
In a nutshell what I'm after is a toolbar and both stateful and normal button components that can be mixed with separators and supports a 'flat' mode of painting..?
- Richard
|
|
|
|
|
|
|
Re: Req: For flat toolbar buttons
Posted:
Sep 18, 2007 5:17 AM
in response to: osbald
|
|
|
> I then wondered if I can't use a JXButton as a base
> component with a background painter ~ which should
> null out the delegate painting if I understand the
> javadoc. Although this too seems to depend on LAF,
> setting a background painter seems to remove the
> button decorations for WindowsPLAF, but not
> Metal/Ocean to get rid of those
> setBorderPainted(false) seems to work - but the
> reverse dosn't hold true for WindowsPLAF?? who is
> correct here?
It doesn't really "null out" the delegate painting. What javadoc says is that it will not call super.paintComponent() as long fg or bg painters are set. And it actually says that by default, painters delegate painting to UI delegates.
What I would try in your case is to set background painter to null.
HTH
Jan
|
|
|
|
|
|
|
|
|
Re: Req: For flat toolbar buttons
Posted:
Sep 18, 2007 5:36 AM
in response to: rah003
|
|
|
>What I would try in your case is to set background painter to null.
Didn't try that, I'd assumed setting the painters to null would restore their original (super.paintComponent()) state 
It still doesn't work for Metal/Ocean BTW, is the button decoration being painted by a border here?
|
|
|
|
|
|
|
|
|
Stranger & Stranger
Posted:
Sep 18, 2007 6:01 AM
in response to: osbald
|
|
|
Ok It seems JToolbar already tries to do some of this via the PLAF delegates alone.
If I add a bunch of buttons (supposed to add components or only actions?) Windows XP PLAF will attempt to remove the decorations if I set toolbar.setRollover(true). The property has some odd effects. setRollover(true) removes the decorations from JButton and JToggleButton as advertised but now my JXButton is collapsed to "..." and still showing its button shape. While setRollover(false) still won't show any button decoration for JButton, but it now will for JToggleButton while JXButton looks much like it would normally (but not imploded).
None of the above has any kind of effect on Metal/Ocean.. Strikes me a very odd having this logic in the toolbar ui delegate. Wonder what Nimbus might do? Quite how the Toolbar is handling this I shudder to think..
Is this tar I've waded into again?
PS I'd probably need a more general JX/Painter friendly container for use in titledpane decorations.
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 18, 2007 6:43 AM
in response to: osbald
|
|
|
The weirdness you see can be (hopefully) explained by the fact that setting rollover to true causes rolloverBorder to be installed on buttons in toolbar. So if the button was big enough to display text without border it might be just too small to display text with the border, hence ... instead of text. If it had border of same size before set to rollover is will be able to display the text even after. Also (non)existence of default borders in different LAFs explains why sometimes you see changes in behaviour and sometimes not.
You can check UIManager.get("ToolBar.rolloverBorder") and UIManager.get("ToolBar.nonrolloverBorder"); to see respective borders.
While Metal will install its own compound border and with inside rollover border, windows laf does not install any borders and with rollover enabled gets default (provided by BasicButtonUI) border installed on the button making the area left for text smaller then it was without border.
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 18, 2007 7:22 AM
in response to: rah003
|
|
|
Not sure it's that straightforward. Seems to be null for both UIManager.get("ToolBar.rolloverBorder") and UIManager.get("ToolBar.nonrolloverBorder") under XP for me. I see quite different painting behaviour between the two rollover & selected states when going from true to false. Esp with the toggle button which now appears both flat & rounded when selected and wrongly uses the classic etched square button when rollover is false. Hmm WindowsLookAndFeel has a "ToolBar.rolloverBorderProvider" instead of those other two properties which are only set in Metal.. because Metal is painting the button decoration as part of its composite border?
The button decorations aren't being painted by the border under Windows. Setting the border to null just makes for a smaller button - not a 'flat' one (nor does setBorderPainted(false)). In any case all three button types in my toolbar should get/set the same border (if its a Toolbar property) so why the difference in appearance? I guess something with all the overriding of the normal painting and this stamp component? under JXButton is no doubt part of a regression problem here.
Are there any more containers that will purposely deviate from their subcomponents installed UIDefaults like this?
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 18, 2007 7:49 AM
in response to: osbald
|
|
|
> Not sure it's that straightforward. Seems to be null
> for both UIManager.get("ToolBar.rolloverBorder") and
> UIManager.get("ToolBar.nonrolloverBorder") under XP
> for me. I see quite different painting behaviour
I thought, I just said that: windows laf does not install any borders and with rollover enabled gets default (provided by BasicButtonUI) border installed
> between the two rollover & selected states when going
> from true to false. Esp with the toggle button which
> now appears both flat & rounded when selected and
> wrongly uses the classic etched square button when
> rollover is false. Hmm WindowsLookAndFeel has a
> "ToolBar.rolloverBorderProvider" instead of those
> other two properties which are only set in Metal..
> because Metal is painting the button decoration as
> part of its composite border?
>
> The button decorations aren't being painted by the
> border under Windows. Setting the border to null just
> makes for a smaller button - not a 'flat' one (nor
> does setBorderPainted(false)). In any case all three
> button types in my toolbar should get/set the same
> border (if its a Toolbar property) so why the
> difference in appearance?
> I guess something with all the overriding of the normal painting and this stamp
> component? under JXButton is no doubt part of a
> regression problem here.
Indeed. The stamp button was attempt to split painting of the foreground and background which is quite tricky to do. What it does is to make stamp transparent and no decorated to paint foreground and then again make it decorated but without text to paint background. In my opinion the only proper way to fix that is to either rewrite existing UI delegates or write new ones for JXButton only ...
> Are there any more containers that will purposely
> deviate from their subcomponents installed UIDefaults
> like this?
... I wish I knew ...
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 18, 2007 8:03 AM
in response to: rah003
|
|
|
>I thought, I just said that: windows laf does not install any borders and with rollover
> enabled gets default (provided by BasicButtonUI) border installed
I though you were explaining how the decorations vanish and why JXButton might implode - but its not a borders alone issue. Suspect that BorderProvider for Windows is making some outdated/awkward choices.
Just bashing my head against the desk as I found out I can't have a transparent JToolbar (setOpaque() dosnt do anything!). I wasn't going to use it in its intended context, but 'dock' it to a table under a tabbed pane for advanced filtering and visualisation options (that were otherwise half a dozen ad-hoc buttons cluttering the ui). Pulling this stunt works:
JToolBar toolBar = new JToolBar() {
protected void paintComponent(Graphics g) {
}
};
But the rollover=true selected state for a togglebutton is very light against an XP tabs background (white on white). - curses! foiled again.
>> Are there any more containers that will purposely
>> deviate from their subcomponents installed UIDefaults
>> like this?
> ... I wish I knew ...
Makes me a little nervous about other PLAFs and especially Synth based ones. Thats ontop of our patchy LookAndFeelAddons consistency and linux support 
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 18, 2007 10:04 AM
in response to: osbald
|
|
|
Something that may be of interest to you is the JXToolBar that resides in my incubator. It is painter-aware and by default creates JXButtons, when using add(Action). It allows the setting of painters for itself and for the JXButtons that it contains.
Karl
|
|
|
|
|
|
|
|
|
JXToolBar (Loosely)
Posted:
Sep 19, 2007 3:45 AM
in response to: kschaefe
|
|
|
Sounds interesting - although I'm adding a mixture of component types to my toolbar and it's not a usual below-menubar-toolbar. More a complex-component toolbar where I wanted the LAF, separators and layout of a toolbar but not the other behaviour.
Guess this'll effectively 'patch' (steamroller) the issue with JXButton decorations persisting into a LAF that shouldn't be showing the decorations. Not sure the buttons wouldn't still implode if extended from JToolbar.. should try it for myself.
Often wonder about the wisdom (in hindsight) over some of the miscellaneous utility methods that were added at the component level. Doesn't it encourage back practises if you can get/set model values via the component rather than be forced to use the models..? Should all components be written to support 'both' usage patterns?
Message was edited by: osbald
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 19, 2007 3:36 AM
in response to: osbald
|
|
|
Found another niggle this morning, if I disable any of my actions/buttons in the toolbar then they dont appear disabled if rollover=true (WindowsPLAF). i.e. text isnt 'greyed out' - any other hints via button decoration would naturally be missing.
- Richard
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 19, 2007 6:17 AM
in response to: osbald
|
|
|
May be just as well you're putting l&f fidelity on the backburner with Nimbus.. still finding problems over here.. despite disable buttons not appearing disabled under windows the text inside the buttons are still offset.. without their surrounding button decorations it now looks like the text on my buttonbar is all very slightly wonky. Created ButtonAndBarsIssues.java in my incubator to remind me to raise some issues or something.
Not entirely clear what can be done nor where it should be done.
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 19, 2007 7:24 AM
in response to: osbald
|
|
|
Could you give it shot one more time? ... JXButton from the latest (#497) build? I did few changes to it ... mainly got rid of JStampButton in it ... seems to work fine with all existing tests and few extra ones ... maybe it fixes your problem as well.
Jan
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 19, 2007 8:00 AM
in response to: rah003
|
|
|
Thanks Jan! Just tried it and it's a definite improvement, the button decorations vanish as expected and it dosn't implode on itself when the toolbar rollover is active.
Couple of differences from a vanilla JButton under Windows PLAF. It dosn't show either a rollover or selected state and the disabled state isn't obvious (although the latter's no different from JButton now).
Does solve a couple of artefacts with the Metal PLAF where the JXButton was being rendered with a raised gradient (other components had lost this when in the toolbar - dont know which is correct). Along with some small 1 pixel cruft that appeared around the edge of the button. But it also lacks the rollover highlighting, Metal dosnt seem to have an obvious 'painted' selected state.
Just noticed (under 5.0) JXButton text seems to be anti-aliased by default, is that intentional? Only really noticed as my example mixes several JButtons with JXButtons on the same dialog.
- Richard
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 19, 2007 9:14 AM
in response to: osbald
|
|
|
AbstractPainter anti-aliases by default. If the painters are enabled then that might be the cause.
Karl
|
|
|
|
|
|
|
|
|
Re: Stranger & Stranger
Posted:
Sep 19, 2007 10:29 AM
in response to: osbald
|
|
|
> Couple of differences from a vanilla JButton under
> Windows PLAF. It dosn't show either a rollover or
> selected state and the disabled state isn't obvious
> (although the latter's no different from JButton
> now).
That is on a toolbar or in normal panel? I tried and worked in my test hmm.
> Does solve a couple of artefacts with the Metal PLAF
> where the JXButton was being rendered with a raised
> gradient (other components had lost this when in the
> toolbar - dont know which is correct). Along with
> some small 1 pixel cruft that appeared around the
> edge of the button. But it also lacks the rollover
> highlighting, Metal dosn't seem to have an obvious
> 'painted' selected state.
I assume that is all on jdk 5, right? I have to admit I did most of the testing on 6 and there it seemed to be fine. I'll have a look at those but if those problems occur only on 5, it might take a while. My biggest concern was the internal stampButton that seemed to be anything but correct. Could file an issue for it? BTW you mentioned some test exposing the issue, care to commit it in head rather then keeping it in incubator?
As for antialiasing, I think it is enabled by default not only for painters but for most of JXxxx components.
Jan
|
|
|
|
|
|
|
|
|
JToolBars secret LAF contract
Posted:
Sep 20, 2007 2:39 AM
in response to: rah003
|
|
|
>> Couple of differences from a vanilla JButton under
>> Windows PLAF. It dosn't show either a rollover or
>> selected state and the disabled state isn't obvious
>> (although the latter's no different from JButton
>> now).
> That is on a toolbar or in normal panel? I tried and worked in my test hmm.
Yes I'm talking about in the Toolbar and the toolbars rollover set to true - not the buttons rollover they're two different things which is kinda confusing. The toolbar PLAF seems to add new temporary rollover (pale ghosted outline) and selected (darker depressed button) to its contained buttons. I'd guess its down to that BorderProvider installed into the WindowsLookandFeel (well hope so really - otherwise its the delegates doing all this black magic).
I've just tried with 6.0 and disappointingly while somethings are better (disabled state & opaque setting on toolbar) others have regressed or rather display new behaviour that makes them hard to use. eg. the toolbar focus-holder under 6.0 now have a new painted border looking much like the usual rounded button like outline. This makes the toggled state of a JToggleButton (which'll have the focus) really hard to see - you have to switch focus after clicking the button to really see any state change.. JXButton also lacks this additional 'focused' outline BTW.
The other immediate wrinkle was the change to the selected painting state of a button means there's no feedback on my JXButtons that overrides the background painter under 6.0.. well only the focus reticule which dosnt really count.
> you mentioned some test exposing the issue, care to commit it in head rather then
> keeping it in incubator?
I'm not sure how useful it is - it's a visual jobbie with a bunch of commandline flags to toggle the LAF (too lazy to keep typing the long winded defaultlaf overrides). It displays over half a dozen quirks and bugs depending on the PLAF and JVM in question some on the runtime some swingx.
|
|
|
|
|
|
|
|
|
Antialiasing
Posted:
Sep 20, 2007 2:46 AM
in response to: rah003
|
|
|
> AbstractPainter anti-aliases by default. If the painters are enabled then that might
> be the cause.
> As for antialiasing, I think it is enabled by default not only for painters but for most
> of JXxxx components.
Just wondering if it should be.. or should the JXComponents honour the same system properties the default components do. It is visually jarring when you mix JComponents with JXComponents under 5.0. 6.0 Would turn on the sub-pixel antialiasing (under windows at least) is that true for JXComponets too or do they stick to their own (what I guess is java2d) aliasing?
Maybe its just me, but if I've no immediate plans to use a painter etc.. I'll always use a JButton or JLabel over an JXButton or JXLabel.
|
|
|
|
|
java.net RSS
