|
Replies:
79
-
Last Post:
Nov 2, 2006 9:17 AM
by: johnpm
|
|
|
|
|
|
|
JXStatusBar ready for public review
Posted:
Sep 12, 2006 3:54 PM
|
|
|
Hey crew,
The JXStatusBar is ready for external review.
Overview
"JXStatusBar is a container for JComponents that is typically placed at the bottom of a form and runs the entire width of the form. There are 2 important functions that <code>JXStatusBar</code> provides.
"First, <code>JXStatusBar</code> provides a hook for a pluggable look and feel. There is a definite look associated with status bars on Windows XP and prior versions of Windows. By implementing a subclass of JComponent, we provide a way for the pluggable look and feel system to modify the look of the status bar.
"Second, <code>JXStatusBar</code> comes with its own layout manager. Each item is added to the <code>JXStatusBar</code> with a <code>JXStatusBar.Constraint</code> as the constraint argument. The <code>JXStatusBar.Constraint</code> contains an <code>Insets</code> object, as well as a "weight". The weight is used the same as the <code>GridBagLayout</code>. The weights of each constraint are added together to form a total weight. Each individual weight then is used as a percentage of the whole. For example:
/* a will get 30% of the free space because .3 + .3 + .4 = 1.0 and 1.0 * .3 = 30% */
bar.add(a, new JXStatusBar.Constraints(.3));
/* b will get 30% of the free space because .3 + .3 + .4 = 1.0 and 1.0 * .3 = 30% */
bar.add(b, new JXStatusBar.Constraints(.3));
/* c will get 40% of the free space because .3 + .3 + .4 = 1.0 and 1.0 * .4 = 40% */
bar.add(c, new JXStatusBar.Constraints(.4));
"Constructing a <code>JXStatusBar</code> is very straitforward:
JXStatusBar bar = new JXStatusBar();
JLabel statusLabel = new JLabel("Ready");
bar.add(statusLabel, new JXStatusBar.Constraints(1.0); /*weight of 0.0 and no insets*/
JProgressBar pbar = new JProgressBar();
bar.add(pbar); /*weight of 0.0 and no insets*/
"Two common use cases for status bars include tracking application status and progress. <code>JXStatusBar</code> does not manage these tasks, but instead special components exist or can be created that do manage these tasks. These are then placed within the <code>JXStatusBar</code>. For example, if your application has a TaskManager or some other repository of currently running jobs, you could easily create a TaskManagerProgressBar that tracks those jobs. This component could then be added to the <code>JXStatusBar</code> like any other component."
Action Please look over the API and give me your thoughts. I'd love to be able to put this component back marked as REVIEWED by the end of the week .
Jeanette, I know you had some questions as to whether there was even a need for this component. I hope I outlined that adequately above.
Thanks, Richard
|
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 13, 2006 4:43 AM
in response to: rbair
|
|
|
Hi Richard,
> > The JXStatusBar is ready for external review. >
good!
> > Jeanette, I know you had some questions as to whether there was even a need for this component.
My doubt is not about a statusbar, but a statusbar in the current form. It is quite far away from the rich vision, citing Patrick (in the refactor statusbar thread in Mar http://forums.java.net/jive/thread.jspa?messageID=90832)
"3) A "status bar" is like a custom toolbar, in that "status beans" can be added, removed, hidden and shown, and reordered on the bar. Each bean can have its own popup or notification window, its own properties pane, beans can be added from a standard dialog, beans can be grouped (to show or hide as a set), plus there are a standard set of status beans that SwingX supports out of the box and that are integrated with things like binding and notification (e.g. "in-progress" load or save for dataset, concurrent running tasks, log/messages, etc.)."
The current state is (Patrick again, same thread) -
"It sounds like you've whittled it down to "a JPanel subclass with a utility layout manager".
with the caveat that the current "utilitiy layout manager" doesn't seem to be very useful to quickly build simple bars (like discussed in the earlier threads). There had been lots of discussion about _what_ is wanted in a simple layout, but I don't see any of it reflected in the current api.
The LF argument is a strong one (ignoring the missing implementations right now, having the xp image on metal looks quite weird But I think any full-fledged component needs some flesh besides LF. Here the minimal flesh (still thinny but better than skin only <g>) would be to make the layout _really_ easy. That'll include but is not limited to hiding the gbl - I wouldn't want to learn about "weight" when trying to position components left or right.
So my suggestion is collect typical layout use-cases (the older threads have some), and try to implement those. Most probably an enhanced api will shake out 
Jeanette
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 13, 2006 5:03 AM
in response to: Kleopatra
|
|
|
Jeanette
Thanks for reviewing the older threads, that's helpful.
My feedback:
1) glad we're moving forward, nice summary of the API, Richard
2) I agree that having a component just for LnF is not really enough to justify it
3) The GBL stuff comes from the most basic use-case of wanting a message area (label) in the status bar, usually pinned to the left edge, which should fill the available size when one resizes the status bar. The easiest way to do that was to use a GBL. I agree we can hide some of this using factory methods, or maybe some enumerations when adding the component (bar.add(messageLbl, LEFT, FILL), bar.add(clock, RIGHT, FIXED)).
4) There were several long threads about the status bar which in retrospect seem rather academic, since I believe no one, outside of the few of us interested (mainly Amy, Richard, and I AFAIR) has ever mentioned using it. Likewise the demo I did a long time back got almost no feedback.
5) I still think that adding, removing, grouping, hiding components is all useful and should be a part of the bar's API.
6) There should be a few simple factories, like a) message area only b) message area + clock c) message area + progress bar c) message area + mem usage indicator
7) I personally think that a status bar is a great, simple component for SwingX with which we can offer a whole number of useful status components out of the box. It can be a cheap way to provide a useful component set that lacks the hair-pulling complexities of things like JXTreeTable. On the other hand, there needs to be some interest...
Regards Patrick
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 13, 2006 11:02 AM
in response to: Patrick Wright
|
|
|
> 2) I agree that having a component just for LnF is > not really enough > to justify it
Why not?
> The easiest way to do that was to use a GBL. I > agree we can hide > some of this using factory methods, or maybe some > enumerations when > adding the component (bar.add(messageLbl, LEFT, > FILL), bar.add(clock, > RIGHT, FIXED)).
If we come up with the right enums, this could be possible. It would never give the flexibility that weight does ("not only do I want these two fields to fill, but I want one of them to get 30% of the free space and the other to get 70% of the free space"). However, I would tend to agree that the level of flexibility allowed by "weight" does not justify the cost in learning the API.
If we simply had an enum, ResizeBehavior {FIXED, FILL}, then we could probably cover all our major use cases. If two items are added with FILL, then they each get 1/2 of the free space. Perhaps even simpler would be a boolean, though an enum would allow for extension later on if we get another resize behavior.
> 5) I still think that adding, removing, grouping, > hiding components is > all useful and should be a part of the bar's API.
Does it really need to be part of the API? Adding and removing, for instance are already supported via the normal add and remove methods. Grouping is another question, what does that mean, exactly?
If you mean it would be nice to have a popup menu with actions for allowing the user to add/remove/rearrange items, then that's a different story. Such behavior could be built on this API, but wouldn't require any changes to the API.
> 6) There should be a few simple factories, like > a) message area only > b) message area + clock > c) message area + progress bar > c) message area + mem usage indicator
We could have these, but I don't know if they are really that useful. At least, from the GUI builder point of view it is moot since the bean spec doesn't allow for such things (and none of the GUI builders I know of have extensions to allow use of factories).
The bigger issue is somebody still needs to write the clock, mem usage indicator, and a progress bar bean that participates as a larger app-framework-task-progress-consumer. 
I absolutely think such beans have to be created, and there is nothing in this API that precludes their use. I mean, they are just components in the end.
And that is one of the core points. A JXClock component would be useful both in a status bar and outside one. A mem-usage indicator could likewise be useful outside of a status bar. It follows that by allowing the user to embed any component in the status bar, we allow components to be reused across a variety of contexts, and allow users to use existing custom components on the status bar.
> 7) I personally think that a status bar is a great, > simple component > for SwingX with which we can offer a whole number of > useful status > components out of the box. It can be a cheap way to > provide a useful > component set that lacks the hair-pulling > complexities of things like > JXTreeTable. On the other hand, there needs to be > some interest...
I totally agree that having a set of useful status components out of the box would be GREAT!
The App Framework JSR (296) is interested in a status bar component. One reason we probably haven't heard a lot of interest is because folks are just using a JPanel with components on it for their status bar -- precisely the kind of API being proposed, and it meets their needs. They probably aren't paying much attention to LAF issues, or are only using a cross platform LAF. And I bet nobody is going the extra mile with user configurable bars. That doesn't mean it isn't a cool idea!
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 13, 2006 11:27 AM
in response to: rbair
|
|
|
Hi Richard
On 9/13/06, jdnc-interest@javadesktop.org <jdnc-interest@javadesktop.org> wrote: > > 2) I agree that having a component just for LnF is > > not really enough > > to justify it > > Why not?
Because the lack of status bar graphical attributes, which are (or seem to be) OS-specific is a limitation of the Swing implementation of the components for those LnFs. It seems to be eye candy, doesn't it?
> If we come up with the right enums, this could be possible. It would never give the flexibility that weight does ("not only do I want these two fields to fill, but I want one of them to get 30% of the free space and the other to get 70% of the free space"). However, I would tend to agree that the level of flexibility allowed by "weight" does not justify the cost in learning the API.
I think we could have both, if you pass in a decimal, you get full flexibility, if you use enums, you get less flexibility. We just need to play around with it. The goal is to make the message/text area drop-dead simple, and to make it easy to "stack" other components along the bar, allowing for nice layout while resizing (as far as I can see it).
> If we simply had an enum, ResizeBehavior {FIXED, FILL}, then we could probably cover all our major use cases. If two items are added with FILL, then they each get 1/2 of the free space. Perhaps even simpler would be a boolean, though an enum would allow for extension later on if we get another resize behavior.
Agreed
> > 5) I still think that adding, removing, grouping, > > hiding components is > > all useful and should be a part of the bar's API. > > Does it really need to be part of the API? Adding and removing, for instance are already supported via the normal add and remove methods. Grouping is another question, what does that mean, exactly?
This is just an interest of mine, not sure if others find it useful. The status bar is for status information, and it makes sense (to me) that some components on it are context-dependent. For example, I may want to make a "data transfer" component visible while transfer was going on, and invisible otherwise. I may also want to add/remove components at runtime. What I don't want is to lose my layout when I do this, so the thrust of my proposal was to have the status bar API help me do this. If I make a component invisible, will the other components move? I don't want them to. What if I remove and re-add the component (or replace with another instance as needed)--can I keep the position the old one was in? Seems a high priority that these things don't move around unless the frame resizes.
I was trying to figure out a solution to those "problems" with this question. I won't fight it, as long as we can do something like--anchor/left, anchor/right, fill.
> > If you mean it would be nice to have a popup menu with actions for allowing the user to add/remove/rearrange items, then that's a different story. Such behavior could be built on this API, but wouldn't require any changes to the API.
Unless it's like the column control popup, which does interact with the table.
> > > 6) There should be a few simple factories, like > > a) message area only > > b) message area + clock > > c) message area + progress bar > > c) message area + mem usage indicator > > We could have these, but I don't know if they are really that useful. At least, from the GUI builder point of view it is moot since the bean spec doesn't allow for such things (and none of the GUI builders I know of have extensions to allow use of factories).
Why not useful? We can come up with *some* list. The point is we want people who need a status bar to create one really easily. Why not help them out? I wouldn't put these in the API, but maybe a utility class. Just want to say it should be possible.
> > The bigger issue is somebody still needs to write the clock, mem usage indicator, and a progress bar bean that participates as a larger app-framework-task-progress-consumer. 
Well, I posted a couple of components in the incubator when I first worked on this. Not sure about progress bar, a little more complicated (since to be useful I think you need to be able to collect results from more than one process.
> I absolutely think such beans have to be created, and there is nothing in this API that precludes their use. I mean, they are just components in the end. > > And that is one of the core points. A JXClock component would be useful both in a status bar and outside one. A mem-usage indicator could likewise be useful outside of a status bar. It follows that by allowing the user to embed any component in the status bar, we allow components to be reused across a variety of contexts, and allow users to use existing custom components on the status bar.
No, they have to fit within a 20-pix or so height and be of a reasonable width, and possibly support configuration via a popup menu, or action via single or double-click. I agree on reuse in general and they might have reusable models of some kind (like a GC/mem usage callback), but I'd argue this is one type of component that needs to look good within the context of a status bar.
> I totally agree that having a set of useful status components out of the box would be GREAT!
Good.
> The App Framework JSR (296) is interested in a status bar component. One reason we probably haven't heard a lot of interest is because folks are just using a JPanel with components on it for their status bar -- precisely the kind of API being proposed, and it meets their needs. They probably aren't paying much attention to LAF issues, or are only using a cross platform LAF. And I bet nobody is going the extra mile with user configurable bars. That doesn't mean it isn't a cool idea!
I need to think more about the GUI builder issue, and where that fits in. Maybe a compromise is to have the JXStatusBar with no components built in, then a ".simple" package with a couple of utility, pre-built subclasses--one with just a message bar, one with message bar and clock (or just properties to configure these). We're using the ".simple" idea in Flying Saucer to collect front-facing convenience-oriented APIs and I think it's a good way to get people up and running quickly--while still allowing for more flexible, complex APIs. That would be a good compromise, from my POV.
Cheers Patrick
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 13, 2006 11:50 AM
in response to: Patrick Wright
|
|
|
Just a quick comment or two -
I really like the idea of having a status bar component that I can plug any bean into, rather whan having a generic JPanel subclass where the message and progress indicator is always in the same place. (Though I think common use cases like this should be readily available).
Is there going to be a SwingLabs StatusBar and a JSR296 StatusBar?
--Bill
On 9/13/06, Patrick Wright < pdoubleya@gmail.com> wrote: > > Hi Richard > > On 9/13/06, jdnc-interest@javadesktop.org <jdnc-interest@javadesktop.org> > wrote: > > > 2) I agree that having a component just for LnF is > > > not really enough > > > to justify it > > > > Why not? > > Because the lack of status bar graphical attributes, which are (or > seem to be) OS-specific is a limitation of the Swing implementation of > the components for those LnFs. It seems to be eye candy, doesn't it? > > > If we come up with the right enums, this could be possible. It would > never give the flexibility that weight does ("not only do I want these two > fields to fill, but I want one of them to get 30% of the free space and the > other to get 70% of the free space"). However, I would tend to agree that > the level of flexibility allowed by "weight" does not justify the cost in > learning the API. > > I think we could have both, if you pass in a decimal, you get full > flexibility, if you use enums, you get less flexibility. We just need > to play around with it. The goal is to make the message/text area > drop-dead simple, and to make it easy to "stack" other components > along the bar, allowing for nice layout while resizing (as far as I > can see it). > > > If we simply had an enum, ResizeBehavior {FIXED, FILL}, then we could > probably cover all our major use cases. If two items are added with FILL, > then they each get 1/2 of the free space. Perhaps even simpler would be a > boolean, though an enum would allow for extension later on if we get another > resize behavior. > > Agreed > > > > 5) I still think that adding, removing, grouping, > > > hiding components is > > > all useful and should be a part of the bar's API. > > > > Does it really need to be part of the API? Adding and removing, for > instance are already supported via the normal add and remove methods. > Grouping is another question, what does that mean, exactly? > > This is just an interest of mine, not sure if others find it useful. > The status bar is for status information, and it makes sense (to me) > that some components on it are context-dependent. For example, I may > want to make a "data transfer" component visible while transfer was > going on, and invisible otherwise. I may also want to add/remove > components at runtime. What I don't want is to lose my layout when I > do this, so the thrust of my proposal was to have the status bar API > help me do this. If I make a component invisible, will the other > components move? I don't want them to. What if I remove and re-add the > component (or replace with another instance as needed)--can I keep the > position the old one was in? Seems a high priority that these things > don't move around unless the frame resizes. > > I was trying to figure out a solution to those "problems" with this > question. I won't fight it, as long as we can do something > like--anchor/left, anchor/right, fill. > > > > > If you mean it would be nice to have a popup menu with actions for > allowing the user to add/remove/rearrange items, then that's a different > story. Such behavior could be built on this API, but wouldn't require any > changes to the API. > > Unless it's like the column control popup, which does interact with the > table. > > > > > > 6) There should be a few simple factories, like > > > a) message area only > > > b) message area + clock > > > c) message area + progress bar > > > c) message area + mem usage indicator > > > > We could have these, but I don't know if they are really that useful. At > least, from the GUI builder point of view it is moot since the bean spec > doesn't allow for such things (and none of the GUI builders I know of have > extensions to allow use of factories). > > Why not useful? We can come up with *some* list. The point is we want > people who need a status bar to create one really easily. Why not help > them out? I wouldn't put these in the API, but maybe a utility class. > Just want to say it should be possible. > > > > > The bigger issue is somebody still needs to write the clock, mem usage > indicator, and a progress bar bean that participates as a larger > app-framework-task-progress-consumer.  > > Well, I posted a couple of components in the incubator when I first > worked on this. Not sure about progress bar, a little more complicated > (since to be useful I think you need to be able to collect results > from more than one process. > > > > I absolutely think such beans have to be created, and there is nothing > in this API that precludes their use. I mean, they are just components in > the end. > > > > And that is one of the core points. A JXClock component would be useful > both in a status bar and outside one. A mem-usage indicator could likewise > be useful outside of a status bar. It follows that by allowing the user to > embed any component in the status bar, we allow components to be reused > across a variety of contexts, and allow users to use existing custom > components on the status bar. > > No, they have to fit within a 20-pix or so height and be of a > reasonable width, and possibly support configuration via a popup menu, > or action via single or double-click. I agree on reuse in general and > they might have reusable models of some kind (like a GC/mem usage > callback), but I'd argue this is one type of component that needs to > look good within the context of a status bar. > > > > I totally agree that having a set of useful status components out of the > box would be GREAT! > > Good. > > > The App Framework JSR (296) is interested in a status bar component. One > reason we probably haven't heard a lot of interest is because folks are just > using a JPanel with components on it for their status bar -- precisely the > kind of API being proposed, and it meets their needs. They probably aren't > paying much attention to LAF issues, or are only using a cross platform LAF. > And I bet nobody is going the extra mile with user configurable bars. That > doesn't mean it isn't a cool idea! > > I need to think more about the GUI builder issue, and where that fits > in. Maybe a compromise is to have the JXStatusBar with no components > built in, then a ".simple" package with a couple of utility, pre-built > subclasses--one with just a message bar, one with message bar and > clock (or just properties to configure these). We're using the > ".simple" idea in Flying Saucer to collect front-facing > convenience-oriented APIs and I think it's a good way to get people up > and running quickly--while still allowing for more flexible, complex > APIs. That would be a good compromise, from my POV. > > > Cheers > Patrick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net > For additional commands, e-mail: jdnc-help@jdnc.dev.java.net > > [att1.html]
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 13, 2006 8:06 PM
in response to: Bill Snyder
|
|
|
I would definitely use JXStatusBar. I have built simple ones myself by mixing other components, never really satisfactorily.
Two things I would like to see: 1. addSeparator(int width); 2. Some way of handling a global instance of JXStatusBar. I'm not sure if it should be included as part of JXStatusBar or handled by the developer. The scenario is where I have a base frame with the status bar, and on it I display a number of different panels, all separate classes, which may want to access the status bar on the base frame, i.e. only one status bar for the whole application. I realize the status bar can be accessed via the base frame, and perhaps that's the best way. I'm open on this.
I would not be too concerned about things like clock (I've got one at bottom right, right now), or memory usage indicator. While I probably wouldn't use a progress indicator, I agree it would probably be useful for some
I too, don't really like weights, but I think they are a good option. It's not clear, but it appears that the weights do not have to add up to 1.0 Does this mean I can use weights of 3, 1 and 1 which means the first one is 3 times the width of the other two. If so, weights are fine by me. (Even if I have to use 3.0, 1.0 and 1.0)
I think a popup to allow the user to fiddle with the layout is not a good idea.
> The status bar is for status information, and it makes sense (to me) > that some components on it are context-dependent. For example, I may > want to make a "data transfer" component visible while transfer was > going on, and invisible otherwise. I may also want to add/remove > components at runtime. What I don't want is to lose my layout when I > do this, so the thrust of my proposal was to have the status bar API > help me do this. If I make a component invisible, will the other > components move? I don't want them to. What if I remove and re-add the > component (or replace with another instance as needed)--can I keep the >position the old one was in? Seems a high priority that these things > don't move around unless the frame resizes.
I agree with this
My ideal status bar would be set up with a specified number of fixed compartments of varying sizes, with the ability to add a component to a compartment, remove it, or hide it, without affecting the adjacent compartments, i.e. if a component was removed or hidden, the compartment would remain and be blank. The only time things would change would be on a resize or if another compartment was added.
This would require an API including methods such as addCompartment(weight) add(component, index) (this will replace an existing component in this compartment) perhaps add(component, weight) (this will add another compartment to the end remove(index) setVisible(index, boolean)
< If we simply had an enum, ResizeBehavior {FIXED, FILL}, then we could probably cover all our major use cases. If two items are added with FILL, then they each get 1/2 glad we're moving forward, nice summary of the API, Richard Agree Keep up the good work
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 9:36 AM
in response to: rturnbull
|
|
|
> Two things I would like to see: > 1. > addSeparator(int width);
What would this method be specified to do? would the extra width become padding split between the left and right sides?
> 2. > Some way of handling a global instance of > JXStatusBar.
I think you are right, this seems more like an App framework issue than a component issue.
> I too, don't really like weights, but I think they > are a good option. > It's not clear, but it appears that the weights do > not have to add up to 1.0
That's correct -- same with GBL. By convention we add them up to 1.0, because it is easier to read the code and determine what percentage of free space each cell gets.
> I think a popup to allow the user to fiddle with the > layout is not a good idea.
Ok.
> > The status bar is for status information, and it > makes sense (to me) > > that some components on it are context-dependent. > For example, I may > > want to make a "data transfer" component visible > while transfer was > > going on, and invisible otherwise. I may also want > to add/remove > > components at runtime. What I don't want is to lose > my layout when I > > do this, so the thrust of my proposal was to have > the status bar API > > help me do this. If I make a component invisible, > will the other > > components move? I don't want them to. What if I > remove and re-add the > > component (or replace with another instance as > needed)--can I keep the > >position the old one was in? Seems a high priority > that these things > > don't move around unless the frame resizes. > > I agree with this
This is a really interesting idea, and one that deserves a bit more thought. So exploring it a bit:
There seem to be two desires. Sometimes you want a "cell" or "compartment" to remain the same size and in the same position, even if the component within that cell is not visible. Sometimes you want the cell to not be visible at all, but to be able to become visible later.
Adding to the trickery, it isn't just the "cell" contents you want to be removed, but also the separator prefixing it (or postfixing it, but only one separator).
For example: messagearea | num | scroll | progress
could become: messagearea | | scroll | progress
or: messagearea | scroll | progress
and later be restored.
Of course all this is possible with the current API -- just not very easy to do so (because you have to maintain the state indicating where a component was, and remove/add the separator, etc.).
To add to the difficulty, in different LAFs you may/may not want the separators painted. Mac OS X applications don't tend to use status bars, and when they have a status like component it is basically a center aligned label, sometimes with buttons on the left and right (see ITunes). I could imagine other arrangmentts in other LAFs as well (besides using a separator).
This needs more thought.
> < If we simply had an enum, ResizeBehavior {FIXED, > FILL}, then we could probably cover all our major use > cases. If two items are added with FILL, then they > each get 1/2 of the free space. Perhaps even simpler > would be a boolean, though an enum would allow for > extension later on if we get another resize > behavior. > > Agree > But I would like to see it applied to the bar rather > than the individual components
What do you mean?
Cheers Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 1:12 PM
in response to: rbair
|
|
|
When I have implemented status bar components I have used a border to draw the separators, with the border always being drawn on the trailing edge (apart from the final component, unless you're running on a platform with a drag-handle, which the status bar layout detects and accounts for). Regardless of how it's handled, I don't think there should be a separate separator component in the bar.
I'm not sure that allowing a variable separator width is the correct approach, this should probably be determined by the UI delegate based on platform.
I agree that the "layout fiddling popup" is a Bad Thing.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 1:19 PM
in response to: iphillips
|
|
|
> I agree that the "layout fiddling popup" is a Bad Thing.
Not to pick on you, but my original suggestion (months ago) was that some status bar components might have a popup for configuration or control, the way that task tray items in Windows do. An example might be a memory usage widget which, when you hover over it, shows you a little graph of recent usage, or using a popup menu, allows you to recover memory. Or you could bring a popup over a progress bar and stop or pause a process, or configure the display of the bar. It's really up to the individual widgets to do this, though.
Separately, in one of my earlier proposals I suggested having the status bar be configurable via a small properties dialog, so components could be added, moved, removed, or configured. That is also outside of the status bar proper, although would work along with it.
Just to clarify, at least from my POV Patrick
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 9:47 AM
in response to: Bill Snyder
|
|
|
> Is there going to be a SwingLabs StatusBar and a > JSR296 StatusBar?
Technically, there will probably be a clone of JXStatusBar in JSR 296 to avoid a dependency on an external project, but in reality they should be the same component. I don't know that for sure though, just shooting from the hip.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 9:14 PM
in response to: rbair
|
|
|
Just to clarify:
Two things I would like to see: > 1. > addSeparator(int width); >What would this method be specified to do? would the extra width become padding split between the left and right sides? This is to save me having to write:
JSeparator s = new JSeparator();
s.setSize(new Dimension(5, 0);
statusBar.add(s);
> There seem to be two desires. Sometimes you want a "cell" or "compartment" to remain the same size and in the same position, even if the component within that cell is not visible. Sometimes you want the cell to not be visible at all, but to be able to become visible later.
> Adding to the trickery, it isn't just the "cell" contents you want to be removed, but also the separator prefixing it (or postfixing it, but only one separator).
>For example: >messagearea | num | scroll | progress
What I would like is for messagearea | num | scroll | progress to become messagearea | ...... | scroll | progress
i.e the compartments/cells/slots (call them what you will :)) remain whether they contain anything or not. (without the dots - dots included to improve visibility. Warning: appearance will depend on font used ;))
> < If we simply had an enum, ResizeBehavior {FIXED, > FILL}, then we could probably cover all our major use > cases. If two items are added with FILL, then they > each get 1/2 of the free space. Perhaps even simpler > would be a boolean, though an enum would allow for > extension later on if we get another resize > behavior. > > Agree > But I would like to see it applied to the bar rather > than the individual components
> What do you mean?
I guess here I am asking for two different styles of StatusBar. One where cells are FIXED, as above, and one where the cells appear and disappear to FILL the bar. Might be a bit tricky to include both in the one component. Anyway I think you've covered it. I withdraw this request.
As for your summary:
> Doesn't Go Far Enough I agree we should concentrate on handling the layout of the components. I don't think it is feasable to put component logic in the StatusBar without knowing what the components are. Perhaps its a TODO to later provide some standard components (the only one I could see universal agreement on is a message:), perhaps a progress bar). In the meantime I would subclass StatusBar and provide my own.
> Layout Manager Enhancements Still not sure we can ditch weights. How do you handle the case of two component where you want one to always have two thirds of the bar and the other one third. I think they should be kept for FILL
> Status Bar Component Management Perhaps as well as FIXED and FILL we could also have FIXED_PERM, FIXED_TEMP and FILL_TEMP. (names subject to change) If a FIXED_PERM is removed or hidden, its cell remains. If a _TEMP is hidden, its space is reclaimed but is reallocated if the item is made visible again.
But the last use case raises the point - can components only be added to the end. If you could specify where to add them we wouldn't need _TEMP (assuming we need it in the first place :))
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 10:57 PM
in response to: rturnbull
|
|
|
I'd suggest that we have two components, the generalized form, with no built-in components, then a utility subclass which includes a message area (and possibly other components).
The pre-packaged JXStatusBarWhatever can go in a different package, maybe .optional or .simple as I suggested before, so we can feel more free to work on it later.
I agree that there will be different notification mechanisms in various apps, but don't see why we can't provide a pre-build bar with "setStatus(text)". This seems pretty common, and there's no reason to ask developers to either create their own, or to always remember to add the message-component, then look it up by name and call setText() on that.
I guess I'm leaning toward's Richard's idea that JXStatusBar manages LnF decorations and layout, and that's it, more or less:
1) Look and feel: JXStatusBar provides the following LnF-specific features a) status bar visual decorations (like resizing handle in corner) b) standard, fixed height c) borders for embedded components, automatically added d) default spacing between components
2) Layout A principle task, perhaps the principle task, of JXStatusBar is to manage the layout of its components. The status bar needs to a) allow a component to grow or shrink with frame/bar resize b) allow a component to have a fixed size c) force the height of a component to fit d) maintain the order (LtoR) of components on the bar e) allow "anchoring" of components so that they appear to remain in the same place, relative to the size of the frame f) allow components to be hidden and made visible while preserving their size and placement on the bar
Patrick
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 1:41 AM
in response to: Patrick Wright
|
|
|
I agree with Patrick. Two components seems to make sense.
I guess the JXStatusBar 'container' would be more akin to the JToolBar or something. But I bet most folks are going to come to a class called JXStatusBar and expect to be able to set a status message and or progress; we just need to be careful how we present things. [att1.html]
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 1:47 AM
in response to: Bill Snyder
|
|
|
It seems somehow similar as well to dialogs, JDialog and JOptionPane, where the latter can create the correct button set for me...
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 1:48 AM
in response to: Patrick Wright
|
|
|
True.
On 9/15/06, Patrick Wright <pdoubleya@gmail.com> wrote: > > It seems somehow similar as well to dialogs, JDialog and JOptionPane, > where the latter can create the correct button set for me... > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net > For additional commands, e-mail: jdnc-help@jdnc.dev.java.net > > [att1.html]
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 2:56 AM
in response to: Patrick Wright
|
|
|
Patrick Wright wrote:
> I guess I'm leaning toward's Richard's idea that JXStatusBar manages > LnF decorations and layout, and that's it, more or less: > > > 1) Look and feel: JXStatusBar provides the following LnF-specific features > a) status bar visual decorations (like resizing handle in corner) > b) standard, fixed height > c) borders for embedded components, automatically added > d) default spacing between components > > 2) Layout > A principle task, perhaps the principle task, of JXStatusBar is to > manage the layout of its components. The status bar needs to > a) allow a component to grow or shrink with frame/bar resize > b) allow a component to have a fixed size > c) force the height of a component to fit > d) maintain the order (LtoR) of components on the bar > e) allow "anchoring" of components so that they appear to remain in > the same place, relative to the size of the frame > f) allow components to be hidden and made visible while preserving > their size and placement on the bar > >
+100! Excellent requirements summary 
The only thing I would like to add is
aa) allow distinct components to have the same size
Jeanette
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 8:38 AM
in response to: Kleopatra
|
|
|
> aa) allow distinct components to have the same size
That sounds reasonable.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 8:37 AM
in response to: Patrick Wright
|
|
|
> I'd suggest that we have two components, the > generalized form, with no > built-in components, then a utility subclass which > includes a message > area (and possibly other components).
I'm still thinking this over . It's almost like a JNStatusBar!
> I agree that there will be different notification > mechanisms in > various apps, but don't see why we can't provide a > pre-build bar with > "setStatus(text)". This seems pretty common, and > there's no reason to > ask developers to either create their own, or to > always remember to > add the message-component, then look it up by name > and call setText() > on that.
The main reason is, you can't be sure the dev won't remove the message component. Then what will your setStatus method do?
Sure, we can document "don't do that!", but I never like API that brittle. This is the design tension.
> 1) Look and feel: JXStatusBar provides the following > LnF-specific features > a) status bar visual decorations (like resizing > ing handle in corner) > b) standard, fixed height > c) borders for embedded components, automatically > lly added > d) default spacing between components
+1
> 2) Layout > A principle task, perhaps the principle task, of > JXStatusBar is to > manage the layout of its components. The status bar > needs to > a) allow a component to grow or shrink with > ith frame/bar resize > b) allow a component to have a fixed size > c) force the height of a component to fit > d) maintain the order (LtoR) of components on the > the bar
+1
> e) allow "anchoring" of components so that they > hey appear to remain in > the same place, relative to the size of the frame
I'm dubious about this point. How common would this be? I can't imagine where this would be used.
> f) allow components to be hidden and made visible > ble while preserving > their size and placement on the bar
I think (f) has a sister (fprime) that suggests that an alternative behavior would be to hide the component and have it appear "removed".
Doing one or the other would be trivial (it's all just code in the layout manager), but doing both is the tricky part. I think both need to be supported, I just haven't seen a good way to do it yet.
It is always possible that the behavior you describe in (f) is the only behavior, and if you want (fprime) you really DO have to remove the component from the bar. Since they can be added/removed from a specific index (as opposed to constructing the bar only from left to right), this isn't SOOO bad. But even so, I would rather avoid it if I could. Hmmm.
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 9:02 AM
in response to: rbair
|
|
|
> I'm still thinking this over . It's almost like a JNStatusBar!
Sure, whatever it's called.
> The main reason is, you can't be sure the dev won't remove the message component. Then what will your setStatus method do?
They can remove any component on any container we provide for them. They could do this to the login panel, right? Or any other. Throw an exception when they try to remove it. Or let them remove it and run to the Swing forums, where they will be sharply chastized.
I'd probably have alternate constructors, off the top of my head, one of which allows you to pass in a JComponent to act as the text area, so you could have something customized, and another constructor which built and bound one for you.
> > Sure, we can document "don't do that!", but I never like API that brittle. This is the design tension.
It's not tension. The Swing API is an open API. You can add and remove as you please. "don't remove that" works.
Remember we'd be talking about a subclass of JXStatusBar which advertises itself as a message-status bar. If you remove the message area...well, you need more coffee before you approach the KB.
> > e) allow "anchoring" of components so that they > > hey appear to remain in > > the same place, relative to the size of the frame > > I'm dubious about this point. How common would this be? I can't imagine where this would be used.
Need to think it over. I was trying to describe how some SB elements appear in the same place, e.g. anchored to a given location, even when you resize. I think this may be the same thing as saying, they are fixed-width components which are aligned (L, R) on the bar with fixed spacing between them.
> > > f) allow components to be hidden and made visible > > ble while preserving > > their size and placement on the bar > > I think (f) has a sister (fprime) that suggests that an alternative behavior would be to hide the component and have it appear "removed". > > Doing one or the other would be trivial (it's all just code in the layout manager), but doing both is the tricky part. I think both need to be supported, I just haven't seen a good way to do it yet. > > It is always possible that the behavior you describe in (f) is the only behavior, and if you want (fprime) you really DO have to remove the component from the bar. Since they can be added/removed from a specific index (as opposed to constructing the bar only from left to right), this isn't SOOO bad. But even so, I would rather avoid it if I could. Hmmm.
Well, you can handle f) by having a tiny panel to swap out with the other. If you remove, why not just layout again?
Patrick
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 10:56 AM
in response to: Patrick Wright
|
|
|
> > The main reason is, you can't be sure the dev won't > remove the message component. Then what will your > setStatus method do? > > They can remove any component on any container we > provide for them. > They could do this to the login panel, right? Or any > other. Throw an > exception when they try to remove it.
Yes, they could even do this with a JComboBox -- but that isn't a normal use case. Adding and removing components from a status bar *is* a normal use case. It just means that if somebody removes the progress bar, for instance, they have to be sure to put *that exact* progress bar back into the status bar later, and not a new version. Or, you'd have to add more API to JXStatusBar for adding and removing these special components (either public or protected).
My point is there is a lot more API implied beyond just setStatus and setProgress. I worry about the corner cases.
> I'd probably have alternate constructors, off the top > of my head, one > of which allows you to pass in a JComponent to act as > the text area, > so you could have something customized, and another > constructor which > built and bound one for you.
Yes, that is one way to do it. Although remember that this approach will not work for people using a GUI builder.
In the GUI Builder, hopefully, people would just add additional components to the bar and move them around -- not remove one of the existing ones and replace it with their own and then wonder why it doesn't work.
> Remember we'd be talking about a subclass of > JXStatusBar which > advertises itself as a message-status bar. If you > remove the message > area...well, you need more coffee before you approach > the KB.
For a subclass of JXStatusBar, I don't mind so much having this kind of requirement. I'm still trying to see if we really need a subclass, or if there is a way to satisfy the requirements in one class.
> > > f) allow components to be hidden and made visible > > > ble while preserving > > > their size and placement on the bar > > > > I think (f) has a sister (fprime) that suggests > > that an alternative behavior would be to hide the > > component and have it appear "removed". > > Well, you can handle f) by having a tiny panel to > swap out with the > other. If you remove, why not just layout again?
I'm not sure I understand what you mean by "a tiny panel to swap out with the other"?
Here is an example use case for removing/adding components on the fly (fprime). Consider a status bar who's contents would be dynamically changed in response to GUI state -- for example if you are in a document you might dynamically add a "cursor position indicator" component to the status bar, and remove it when focus is elsewhere (maybe in an entirely different part of the app).
Here is an example use case for simply hiding the component but preserving the "cell" (f). The progress bar will most likely be hidden, except when a progress event is occuring. As this may happen frequently (progress tasks starting/stopping), we would want a stable location for the bar.
Both use cases seem pretty reasonable.
Here are several approaches I've been considering:
Plan A Do nothing special. (fprime) would be the commonly supported use case. For example:
bar.add(message);
bar.add(cursorLocIndicator);
JPanel progPanel = new JPanel();
progPanel.add(progress);
bar.add(progPanel);
...
/* causes the "cell" to disappear, and everything
to be layed out */
cursorLocIndicator.setVisible(false);
...
/* causes the "cell" to reappear, in the same place
it used to be */
cursorLocIndicator.setVisible(true);
...
/* causes the progress bar to disappear, but keeps
the cell where it is -- no layout changes */
progress.setVisible(false);
Plan A works great for the (fprime) case, but horrible for the (f) case.
Plan B Tweak the layout manager so that invisible components are still layed out, just obviously not painted. (f) would be the common use case. For example:
bar.add(message);
bar.add(cursorLocIndicator);
bar.add(progress);
...
/* causes the "cell" to disappear, and everything
to be layed out */
bar.remove(1);
...
/* causes the "cell" to reappear, in the same place
it used to be */
bar.add(cursorLocIndicator, 1);
...
/* causes the progress bar to disappear, but keeps
the cell where it is -- no layout changes */
progress.setVisible(false);
Plan B has the advantage of avoiding anything particularly hacky. In fact, it lives by the semantics that already exist, except for this small tweak in the layout manager. The problem with Plan B is that requires a controller of some kind that keeps the state when components are added or removed.
Plan C Introduce full blown API to control the "cells", and what is in them. Every added component would be automatically wrapped in a Container. API would exist for making the cells visible or invisible. For example:
bar.add(message);
bar.add(cursorLocIndicator);
bar.add(progress);
...
/* causes the "cell" to disappear, and everything
to be layed out */
bar.getCell(cursorLocIndicator).setVisible(false);
...
/* causes the "cell" to reappear, in the same place
it used to be */
bar.getCell(cursorLocIndicator).setVisible(true);
...
/* causes the progress bar to disappear, but keeps
the cell where it is -- no layout changes */
progress.setVisible(false);
The advantage to Plan C is that there isn't a need to store any additional state (such as what index items belong in). The disadvantages include an extra JComponent per cell, and the fact that statusBar.getComponent(0) != message. In other words, what you think you are doing (adding a JLabel to the status bar) is not what you are really doing (adding a JComponent to the status bar, and adding a JLabel to that).
Plan Summary I favor Plan B, but also like Plan C. I don't really like Plan A much.
What do you think? Are there other plans I should be considering? Which of these do you like, and why?
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 12:42 PM
in response to: rbair
|
|
|
> Yes, they could even do this with a JComboBox -- but that isn't a normal use case. Adding and removing components from a status bar *is* a normal use case. It just means that if somebody removes the progress bar, for instance, they have to be sure to put *that exact* progress bar back into the status bar later, and not a new version. Or, you'd have to add more API to JXStatusBar for adding and removing these special components (either public or protected).
I disagree. I think we have two cases, one where people want a drop-in status bar showing a message area + one other thing (date, progress bar), which covers the most common usage, and a second case where people want a way to have status bar behavior without having to struggle with the layout problem (and decorations) themselves.
I think however we do it, people can always poke inside the container and remove things, that's how Swing works, it's an open API. We shouldn't protect people from their own, err, creativity and willingness to explore. I also think if we have two options: a) message bar is a jlabel and b) message bar is a custom component, we'll cover most of what people want anyway.
So I'm not worried about the add/remove case.
> My point is there is a lot more API implied beyond just setStatus and setProgress. I worry about the corner cases.
I don't think so; it's setStatus(text) and setProgress(pct complete, total). Pretty straightforward.
> > > I'd probably have alternate constructors, off the top > > of my head, one > > Yes, that is one way to do it. Although remember that this approach will not work for people using a GUI builder.
Well, I just want some way to pass in a custom text area. Don't know much about the best alternatives for a GUI builder. How do you pass in a custom panel to a dialog in a GUI builder?
> In the GUI Builder, hopefully, people would just add additional components to the bar and move them around -- not remove one of the existing ones and replace it with their own and then wonder why it doesn't work.
That requires documentation. Make it clear that JNStatusBar is "not to be trifled with".
(you're probably against closures too, haha ;D)
> For a subclass of JXStatusBar, I don't mind so much having this kind of requirement. I'm still trying to see if we really need a subclass, or if there is a way to satisfy the requirements in one class.
OK. Maybe there is an external component that is pre-configured that one can just add? e.g. with message, message/date, whatever. Problem is you can't directly access the text without having a handle to that widget.
> > Well, you can handle f) by having a tiny panel to > > swap out with the > > other. If you remove, why not just layout again? > > I'm not sure I understand what you mean by "a tiny panel to swap out with the other"?
I meant creating an empty panel that's the same size as the component you're replacing, and swap them, to keep the layout manager simple.
The rest I need to sleep on, have a nice weekend!
Patrick
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 3:42 PM
in response to: Patrick Wright
|
|
|
> > > I'd probably have alternate constructors, off the > top > > > of my head, one > > > > Yes, that is one way to do it. Although remember > that this approach will not work for people using a > GUI builder. > > Well, I just want some way to pass in a custom text > area. Don't know > much about the best alternatives for a GUI builder. > How do you pass in > a custom panel to a dialog in a GUI builder?
getter/setter methods. JSR 273 might make this easier to deal with.
> > For a subclass of JXStatusBar, I don't mind so much > having this kind of requirement. I'm still trying to > see if we really need a subclass, or if there is a > way to satisfy the requirements in one class. > > OK. Maybe there is an external component that is > pre-configured that > one can just add? e.g. with message, message/date, > whatever. Problem > is you can't directly access the text without having > a handle to that > widget.
At that point, you might as well just use a JLabel . Here's the basic code:
/*create the status bar*/
JXStatusBar bar = new JXStatusBar();
/*create and add the message label*/
JLabel messageLabel = new JLabel("Ready");
bar.add(messageLabel, JXStatusBar.Constraint.ResizeBehavior.FILL);
/*create and add the progress bar*/
JProgressBar progress = new JProgressBar();
bar.add(progress);
It's true that nearly EVERY status bar is going to have these two components added to it, so in a sense it is 4 wasted lines of code. On the other hand, it is only 4 lines of code (which nobody is going to end up writing more than once anyway, as they'll probably just subclass JXStatusBar and do it that way, or use a util method, or use the GUI builder).
Incidently, WinForms (or is it WPF? Have to check again...) does it this way. There is no special API on the status bar. But if you get a chance to use Visual Studio, you'll see why it doesn't matter. Their builder experience with the status bar is good enough that it takes less time to configure a bar than it does to read this sentence. Well, maybe about the same.
> The rest I need to sleep on, have a nice weekend! You to!
Thanks Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 8:25 AM
in response to: rturnbull
|
|
|
> > Layout Manager Enhancements > Still not sure we can ditch weights. > How do you handle the case of two component where you > want one to always have two thirds of the bar and the > other one third. I think they should be kept for FILL
Is that really going to be a common request? It seems like the 90% case is going to be one resizable slot (the message text) and then a whole bunch of fixed size slots. The question is whether it is worth introducing weight when most of the time nobody cares. Instead, for the 10% (or probably less) case where people want a "weight" like mechanism, they could replace the layout manager with GBL or FormLayout or something.
> > Status Bar Component Management > Perhaps as well as FIXED and FILL we could also have > FIXED_PERM, FIXED_TEMP and FILL_TEMP. (names subject > to change) > If a FIXED_PERM is removed or hidden, its cell > remains. > If a _TEMP is hidden, its space is reclaimed but is > reallocated if the item is made visible again.
This would be a tidy solution. The problem, as I see it, is that you couldn't have a cell which under some circumstances is hidden but keeps it's cell, and in other circumstances is hidden and appear "removed".
The only solution for this that I've found, is to, for example, use a JPanel and put the progress bar or whatnot on the panel. Hide the panel, the whole thing appears "removed". Hide the component, and the cell remains.
I don't like this much either. Perhaps using constraints would cover the common case and this workaround I've described could be used in the extreme case. Hmph.
> But the last use case raises the point - can > components only be added to the end. If you could > specify where to add them we wouldn't need _TEMP > (assuming we need it in the first place :))
No, just like any JComponent, components can be added with an index -- anywhere.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 3:40 AM
in response to: Patrick Wright
|
|
|
Patrick Wright wrote:
a quick comment (no nitpicking intended):
> >>If you mean it would be nice to have a popup menu with actions for allowing the user to add/remove/rearrange items, then that's a different story. Such behavior could be built on this API, but wouldn't require any changes to the API. > > > Unless it's like the column control popup, which does interact with the table. >
As far as the special column control functionality is concerned it's from the control to the table. from the table's perspective, the control is just an arbitrary component that needs to be positioned in the trailing corner of a surrounding scroll pane, if any.
With a powerful enough layout in place, I think the statusbar can be left unaware of any special "control" component, developers could add it with something like:
add(control, fixed-size, trailing)
If it turns out that they are doing so for practically all statusbar, we could add an option to future apis.
My 0.02 Euro 
Jeanette
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 9:24 AM
in response to: Patrick Wright
|
|
|
> On 9/13/06, jdnc-interest@javadesktop.org > <jdnc-interest@javadesktop.org> wrote: > > > 2) I agree that having a component just for LnF > is > > > not really enough > > > to justify it > > > > Why not? > > Because the lack of status bar graphical attributes, > which are (or > seem to be) OS-specific is a limitation of the Swing > implementation of > the components for those LnFs. It seems to be eye > candy, doesn't it?
I don't understand. I think what you are getting at is "why stop at the 80% mark. If we just go a little further, it will do everything I want it to". That's a ok thing -- I just think it is already at the 100% mark . If, for the sake of argument, a status bar really did boil down to just a panel with a special layout manager and custom look and feel impls on each platform: wouldn't that be reason enough to do it?
> > If we come up with the right enums, this could be > possible. It would never give the flexibility that > weight does ("not only do I want these two fields to > fill, but I want one of them to get 30% of the free > space and the other to get 70% of the free space"). > However, I would tend to agree that the level of > flexibility allowed by "weight" does not justify the > cost in learning the API. > > I think we could have both, if you pass in a decimal, > you get full > flexibility, if you use enums, you get less > flexibility. We just need > to play around with it. The goal is to make the > message/text area > drop-dead simple, and to make it easy to "stack" > other components > along the bar, allowing for nice layout while > resizing (as far as I > can see it).
I'm not in favor of both, simply because the mixture of concepts is worse than just sticking with one or the other. Right now I'm favoring the enum approach. After all, you can always set your own layout manager on the status bar if you have an extremely tricky layout.
> > Does it really need to be part of the API? Adding > and removing, for instance are already supported via > the normal add and remove methods. Grouping is > another question, what does that mean, exactly? > > This is just an interest of mine, not sure if others > find it useful. > The status bar is for status information, and it > makes sense (to me) > that some components on it are context-dependent. For > example, I may > want to make a "data transfer" component visible > while transfer was > going on, and invisible otherwise. I may also want to > add/remove > components at runtime. What I don't want is to lose > my layout when I > do this, so the thrust of my proposal was to have the > status bar API > help me do this. If I make a component invisible, > will the other > components move? I don't want them to. What if I > remove and re-add the > component (or replace with another instance as > needed)--can I keep the > position the old one was in? Seems a high priority > that these things > don't move around unless the frame resizes.
This is worth discussing in a separate subthread. I'll respond to this in a moment.
> > > 6) There should be a few simple factories, like > > > a) message area only > > > b) message area + clock > > > c) message area + progress bar > > > c) message area + mem usage indicator > > > > We could have these, but I don't know if they are > really that useful. At least, from the GUI builder > point of view it is moot since the bean spec doesn't > allow for such things (and none of the GUI builders I > know of have extensions to allow use of factories). > > Why not useful? We can come up with *some* list. The > point is we want > people who need a status bar to create one really > easily. Why not help > them out? I wouldn't put these in the API, but maybe > a utility class. > Just want to say it should be possible.
I would be supportive of a StatusBarFactory in the utils package. I don't imagine they'd be overly used because I imagine devs would develop their own factory method for creating a status bar if it is done often (it seems everybodies app has different needs).
> > The bigger issue is somebody still needs to write > the clock, mem usage indicator, and a progress bar > bean that participates as a larger > app-framework-task-progress-consumer.  > > Well, I posted a couple of components in the > incubator when I first > worked on this. Not sure about progress bar, a little > more complicated > (since to be useful I think you need to be able to > collect results > from more than one process.
The real part I'm afraid of, is more code reviews 
> > And that is one of the core points. A JXClock > component would be useful both in a status bar and > outside one. A mem-usage indicator could likewise be > useful outside of a status bar. It follows that by > allowing the user to embed any component in the > status bar, we allow components to be reused across a > variety of contexts, and allow users to use existing > custom components on the status bar. > > No, they have to fit within a 20-pix or so height and > be of a > reasonable width, and possibly support configuration > via a popup menu, > or action via single or double-click. I agree on > reuse in general and > they might have reusable models of some kind (like a > GC/mem usage > callback), but I'd argue this is one type of > component that needs to > look good within the context of a status bar.
In some cases I'd agree (a pretty, visual analog style clock doesn't belong in the status bar), but in other cases component reuse is completely valid. Besides, the stock 'n standard components in all status bars seem to be icons, labels, and sometimes a progress bar.
> > The App Framework JSR (296) is interested in a > status bar component. One reason we probably haven't > heard a lot of interest is because folks are just > using a JPanel with components on it for their status > bar -- precisely the kind of API being proposed, and > it meets their needs. They probably aren't paying > much attention to LAF issues, or are only using a > cross platform LAF. And I bet nobody is going the > extra mile with user configurable bars. That doesn't > mean it isn't a cool idea! > > I need to think more about the GUI builder issue, and > where that fits > in. Maybe a compromise is to have the JXStatusBar > with no components > built in, then a ".simple" package with a couple of > utility, pre-built > subclasses--one with just a message bar, one with > message bar and > clock (or just properties to configure these). We're > using the > ".simple" idea in Flying Saucer to collect > front-facing > convenience-oriented APIs and I think it's a good way > to get people up > and running quickly--while still allowing for more > flexible, complex > APIs. That would be a good compromise, from my POV.
Personally, my approach would be to do something along the lines of what you see in Visual Studio (if you haven't checked it out in a while, you should give it a go). They have a very rich editor in the builder for configuring a status bar (and a menu bar, but that's another story). JSR 273 (Design time API for JavaBeans) would allow this kind of rich interaction.
Thanks Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 3:32 AM
in response to: rbair
|
|
|
jdnc-interest@javadesktop.org wrote: >>2) I agree that having a component just for LnF is >>not really enough >>to justify it > > > Why not? > >
Because it doesn't feel "weighty" enough <g>.
The longer version of the same:
We are in OO-land. Classes are providing services on their data/state. A well-designed class should be responsible for "one thing" and handle it completely (there are names to all these aspects, which I'm too lazy to look up ...). A component which only adds state (like "single-row dimension", LF) leaves the dirty details of its usage to the developer. That's suboptimal ...
When reading the (current and older) messages, the consent seems to be:
- the "one thing" of the statusbar might be a highly specialized layout with a strong emphasis on ease-of-use - specialized statusbar beans are a nice-to-have, but independent from the statusbar core.
First step in making things "easy" is to understand the requirements - there are some ideas, but they are not yet focused. So I'll repeat my suggestion from the earlier message:
".. to collect typical layout use-cases (the older threads have some), and try to implement those. Most probably an enhanced api will shake out :-)"
Another good place to look for real-world requirements is to find out how the top 3-5 programs each of us is using daily show their statusbar. Starting:
Thunderbird on win2k (from left to right): - fixed size icon - message area which gets all free space - two slots of equal size for unread/total number of messages in folder PLUS: the gaps between all these
win2k Explorer; - message area which gets all free space - fixed "small" sized area to show size of current selected item - fixed "wide" sized area (3 times the previous" for (?? always seems to show "Arbeitsplatz" PLUS: the gaps between them, same size and look as in Thunderbird
Eclipse (view dependent, but with a strong consistency) - all (nearly=): a separator which marks the start of a fixed size trailing space (where the progess info goes, if available) - before the separator, fixed and equal sized slots for location, document status, search mode ... PLUS: special type gaps - visible only if a slot is filled
We should put that collection somewhere (on the twiki page of the statusbar?).
In terms of layout, Patricks list of factory-created standard bars boil down to
- add(somewidget, growing-all-free-space, leading) - (optional) add(somewidget, fixed-space, trailing)
Both Patrick and Ray came up with the use-cases where they need fixed "compartments" (I tend to call them "slots" - but then, you are the natives which can be filled/emptied without disturbing the overall layout. That's in-line with the examples above.
I don't see how the current statusbar/layout can support any of those quite common use-cases (except the very simplistic leading/trailing - but even then it's not obvious (turning my brain to blank whenever I see "weight" that trailing is the same as "zero-weight if the leading comp has a non-zero-weight".
Hmmm... the requirements remind me of a one-row FormLayout with auto-gaps 
Cheers Jeanette
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 9:11 AM
in response to: Kleopatra
|
|
|
> We are in OO-land. Classes are providing services on > their data/state. A > well-designed class should be responsible for "one > thing" and handle it > completely (there are names to all these aspects, > which I'm too lazy to > look up ...). A component which only adds state (like > "single-row > dimension", LF) leaves the dirty details of its usage > to the developer. > That's suboptimal ...
That's not a very specific explanation of perceived short comings . I need concrete points as to where the API fails! It's nice to say "it needs to allow the user to do status bar stuff easily", but I contend it already does that. So I need specific shortcomings pointed out, with proposed enhancements/changes.
> Thunderbird on win2k (from left to right): > - fixed size icon > - message area which gets all free space > - two slots of equal size for unread/total number of > messages in folder > PLUS: the gaps between all these
JXStatusBar bar = new JXStatusBar();
bar.add(iconLabel);
bar.addSeparator();
bar.add(messageLabel, new JXStatusBar.Constraint(1.0));
bar.addSeparator();
bar.add(unreadMessagesLabel); /*has a min size*/
bar.addSeparator();
bar.add(totalMessagesLabel); /*same min size as unreadMessagesLabel*/
/*note: the unread/total messages section on
Thunderbird are _not_ the same size. On my
screenshot: 68px to 57px. What they appear
to have is a "min" size that is respected when
there is no text, and a preferred size thereafter.
However, if you really wanted to have equal size
elements, you can use custom labels that mirror
each others preferred sizes. The alternative is
to add more complexity to the API. I contend this
is not a good idea, because you don't really want
fixed size labels (you don't know what font will
be used for different LAFs, etc), though you may
want labels that at least have the same size.*/
> win2k Explorer; > - message area which gets all free space > - fixed "small" sized area to show size of current > selected item > - fixed "wide" sized area (3 times the previous" for > (?? always seems to > show "Arbeitsplatz" > PLUS: the gaps between them, same size and look as in > Thunderbird
JXStatusBar bar = new JXStatusBar();
bar.add(messageLabel, new JXStatusBar.Constraint(1.0));
bar.addSeparator();
bar.add(fileSizeLabel); /*fileSizeLabel has a min size*/
bar.addSeparator();
bar.add(extraLabel); /*has a min size*/
Note that the "gaps" you refer to are automatically included when you add a separator. Also note that JXStatusBar.Constraint can take an Insets, allowing you to manually specify additional gaps if you so chose.
> Eclipse (view dependent, but with a strong > consistency) > - all (nearly=): a separator which marks the start of > a fixed size > trailing space (where the progess info goes, if > available) > - before the separator, fixed and equal sized slots > for location, > document status, search mode ... > PLUS: special type gaps - visible only if a slot is > filled
Nearly every screenshot I found on google had fewer components than this on the statusbar, leading me to believe that it changes based on the perspectives you have open. Also, I don't know what you mean by special type gaps?
JXStatusBar bar = new JXStatusBar();
bar.add(messageLabel, new JXStatusBar.Constraint(1.0));
bar.addSeparator();
bar.add(locationLabel); /*has min size*/
bar.addSeparator();
bar.add(docStatusLabel); /*has min size*/
bar.addSeparator();
bar.add(searchModeLabel); /*has min size*/
bar.addSeparator();
bar.add(progressBar); /*has min size*/
> I don't see how the current statusbar/layout can > support any of those > quite common use-cases (except the very simplistic > leading/trailing - > but even then it's not obvious (turning my brain to > blank whenever I see > "weight" that trailing is the same as "zero-weight > if the leading > comp has a non-zero-weight".
I hope I've adequately shown in the above code samples how all of those scenarios are handled with the current API. Note that the implementation doesn't respect minimum sizes yet, but that's a bug.
Cheers Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 2:47 AM
in response to: rbair
|
|
|
jdnc-interest@javadesktop.org wrote: >>We are in OO-land. Classes are providing services on >>their data/state. A >>well-designed class should be responsible for "one >>thing" and handle it >>completely (there are names to all these aspects, >>which I'm too lazy to >>look up ...). A component which only adds state (like >>"single-row >>dimension", LF) leaves the dirty details of its usage >>to the developer. >>That's suboptimal ... > > > That's not a very specific explanation of perceived short comings .
It's my general answer to your general question ("why not design a component just for LF").
> I need concrete points as to where the API fails!
you got them, obviously it had been a productive time while I slept <g> Patrick did an excellent summary of requirements this morning - nothing I could add.
Just a couple of comments:
- usually a "separator" is different from a "gap" (or insets/padding whatever you like to call it). Whether to use the one or other probably is an LF issue. In your code snippets, I want to get rid of the addSeparator() - usually there must be some kind of distance between adjacent components to make them look eye-pleasing.
- the question whether min size should be defined in the component added to a container or in the layout manager is a rather old one (you could search the swing forum for some rather heated debates <g>). For me, it's definitely the layout manager.
- you are right - Thunderbird's two trailing labels are not the same size, but they probably should So assuming they are are equal size, that's a case the current statusbar layout can't handle - the basic task is the same as with having "slots/cells/compartments".
- you are probably aware of it, just for completeness: FormLayout does all we might want out-of-the-box. The important thing about it is, that it has the natural (my opinion) metaphor: layoutout cells which can be filled or unfilled by components with optional layout cells that constitute the white-space between the filled/unfilled component cells. And it has the concept of grouping: cells can be kept the same size.
Cheers Jeanette
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 8:30 AM
in response to: Kleopatra
|
|
|
> - usually a "separator" is different from a "gap" (or > insets/padding > whatever you like to call it). Whether to use the one > or other probably > is an LF issue. In your code snippets, I want to get > rid of the > addSeparator() - usually there must be some kind of > distance between > adjacent components to make them look eye-pleasing.
I agree. Yesterday as I was thinking about this I decided I'd like to remove the "addSeparator" API entirely, and leave it up to the LAF. All Windows status bars have these separators.
> - the question whether min size should be defined in > the component added > to a container or in the layout manager is a rather > old one (you could > search the swing forum for some rather heated debates > <g>). For me, it's > definitely the layout manager.
I would probably prefer using the layout manager too, simply because none of the other layout managers really use the min size of the component.
> - you are right - Thunderbird's two trailing labels > are not the same > size, but they probably should So assuming they > are are equal size, > that's a case the current statusbar layout can't > handle - the basic task > is the same as with having > "slots/cells/compartments".
You could certainly code this up easily enough (panels that mirror each others preferred size), but I agree it would be nice to have better support for it.
> - you are probably aware of it, just for > completeness: FormLayout does > all we might want out-of-the-box. The important thing > about it is, that > it has the natural (my opinion) metaphor: layoutout > cells which can be > filled or unfilled by components with optional layout > cells that > constitute the white-space between the > filled/unfilled component cells. > And it has the concept of grouping: cells can be kept > the same size.
I'm not that familiar with FormLayout. I've looked at it several times, and never liked the syntax for definining the constraints
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 6:21 AM
in response to: Kleopatra
|
|
|
just a quick follow-up: I added a JXStatusBarVisualCheck to the test package where we can play with use-cases... feel free to add methods!
Have a nice weekend everybody! Jeanette
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 13, 2006 10:46 AM
in response to: Kleopatra
|
|
|
> The current state is (Patrick again, same thread) - > > "It sounds like you've whittled it down to "a JPanel > subclass with a > utility layout manager".
That about sums it up 
> with the caveat that the current "utilitiy layout > manager" doesn't seem > to be very useful to quickly build simple bars (like > discussed in the > earlier threads). There had been lots of discussion > about _what_ is > wanted in a simple layout, but I don't see any of it > reflected in the > current api. [trim] > make the layout _really_ easy. That'll include but is > not limited to > hiding the gbl - I wouldn't want to learn about > "weight" when trying to > position components left or right.
Here I don't really agree (but would love to be shown a simpler layout manager construct that has the same simple API).
JXStatusBar bar = new JXStatusBar();
JLabel statusLabel = new JLabel("Ready");
bar.add(statusLabel, new JXStatusBar.Constraints(1.0));
JProgressBar pbar = new JProgressBar();
bar.add(pbar);
This, to me, is much simpler than the corrosponding GBL code. I don't, in the API, expose the GBL layout in any way (in fact, I don't even use GBL internally, it is a custom layout manager).
True, weight is obnoxious the first time you use it. On the other hand, I like reusing a concept from a widely used layout manager (even if everybody swears at it :-)).
More in the next mail...
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 10:59 AM
in response to: rbair
|
|
|
Where are the status bits?
I expected to see someting like: public void setStatus(String status) public void statusChanged(StatusEvent se)
If I have to inject my own widgets and maintain their state elsewhere, then I'm not going to use JXStatusBar for my status bar.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 11:30 AM
in response to: ktm
|
|
|
Are we really talking about two status bar components? (1) A simple status bar that has a text message/progress bar area and then an (2) advanced status bar that custom renders beans)? Or are we trying to combine the two ideas?
Perhaps the JXStatusBar *should* just be a JPanel sublcass with a simple message/progress area. Like the original.<https://That was useful to me right out of the box.
Then a fully customizable status bar could something extra, that could be plugged into the JXStatusBar via a getStatusBarComponent() method or something.
Anyway, just some thoughts.
--Bill
On 9/14/06, jdnc-interest@javadesktop.org <jdnc-interest@javadesktop.org> wrote: > > Where are the status bits? > > I expected to see someting like: > public void setStatus(String status) > public void statusChanged(StatusEvent se) > > If I have to inject my own widgets and maintain their state elsewhere, > then I'm not going to use JXStatusBar for my status bar. > [Message sent by forum member 'ktm' (ktm)] > > http://forums.java.net/jive/thread.jspa?messageID=153177 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net > For additional commands, e-mail: jdnc-help@jdnc.dev.java.net > > [att1.html]
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 2:47 PM
in response to: Bill Snyder
|
|
|
> Are we really talking about two status bar > components? (1) A simple status > bar that has a text message/progress bar area and > then an (2) advanced > status bar that custom renders beans)? Or are we > trying to combine the two > ideas?
I hope we can have one component. My thinking is that typical applications would create a status bar and put components on it, but would thereafter not refer to the status bar very much. Mostly they would be calling methods on the components on the status bar directly.
This approach has the distinct advantage of supporting arbitrary application infrastructure. Progress, for example, isn't a matter of communicating via some complicated scheme the progress state and tasks to the JXStatusBar. Rather, some other bit of application logic takes care of that, and simply set the progress state on a progress bar. The progress bar could also have a mouse click handler installed that opens some application specific task dialog (like Eclipse does).
To help simplify this, I see developers creating a subclass of JProgressBar that automatically receives notification from the event bus or other progress notificaiton system of the application, and handling the click duties. This custom component would then be placed on the status bar.
There are other similar schemes (for example, NetBeans has an error icon which, if clicked, would open an error pane) which are also valid for a progress bar. Clearly we can't support ALL of these in API, so at some point supporting arbitrary custom components is necessary.
From a development standpoint (particular from within the IDE), most of this is moot anyway. Building a status bar in the IDE should be like falling off a log. Most of the concern with the current API has less to do with capabilities and more to do with verbosity (which folks using a GUI builder won't care about much, because the IDE is busy writing the code instead of the developer). It seems folks want more built in API sugar, rather than constructing a status bar from pieces.
This tendency can be hazardous, because it can lead to simplistic tools that nobody can use. It can likewise be bad business to not build in any API goodness, because it can lead to a flexible tool that nobody uses. 
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 2:37 PM
in response to: ktm
|
|
|
> Where are the status bits? > > I expected to see someting like: > public void setStatus(String status) > public void statusChanged(StatusEvent se) > > If I have to inject my own widgets and maintain their > state elsewhere, then I'm not going to use > JXStatusBar for my status bar.
Why is that? What would be wrong with subclassing JXStatusBar and adding such widgets by default, if your application warrents it?
Originally, the JXStatusBar (as Bill pointed out in another response) had such API. There were a couple of distinct problems with it. First, it didn't make it easy to add arbitrary widgets (or even common ones like a progress bar). Second, it was tied heavily with an event/progress/message infrastructure. I didn't like having the component be that tied to the infrastructure precisely because people could be using event buses or any number of other message/progress notification schemes.
That said, I can see benefit in having at least the main message area being included in the component by default, and bringing with it a setStatus method. At least, that is one less component that you have to haul around. However, following that logic, I should also add a progress API, which is not a good idea at this point (JSR 296 will likely define a more interesting API including Tasks and a more appropriate progress system).
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 2:57 PM
in response to: rbair
|
|
|
Folks,
I wanted to summarize the discussion thus far, hoping to pull together some of the disparate threads of discussion. These are the topics I consider "open" (meaning, persuade me!).
Doesn't Go Far Enough There appears to be a majority that is concerned that the current API doesn't go far enough. In essence, the current API favors putting status presentation logic in the components of the status bar, rather than in the status bar itself. If I'm reading correctly, several people have expressed the desire to move more status bar logic into the status bar, and out of the components.
For example, ktm said: "I expected to see someting like: public void setStatus(String status) public void statusChanged(StatusEvent se)"
I'm very reticent to change my stance on this, but I'm still thinking this over.
Layout Manager Enhancements Some think the layout manager as specified is too complicated (using the "weight" system). At least one is also concerned that it doesn't handle the main use cases (though I hope to have answered that).
I'm really considering ditching weights and going with an enum containing two values: FIXED and FILL. FIXED would respect Math.max(minSize, prefSize).
Status Bar Component Management This covered the use cases surrounding how to manage the components in the status bar. For example, you might want to hide a component, but have the layout manager still reserve its space (including the separator). Or, you might want to hide a component and effectively have it removed from the status bar, but if made visible again, it would effectively be back in it's original location.
I consider this a critical use case that must be met.
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 14, 2006 6:49 PM
in response to: rbair
|
|
|
On 9/14/06, jdnc-interest@javadesktop.org <jdnc-interest@javadesktop.org> wrote: > > Folks, > > I wanted to summarize the discussion thus far, hoping to pull together > some of the disparate threads of discussion. These are the topics I consider > "open" (meaning, persuade me!). > > Doesn't Go Far Enough > There appears to be a majority that is concerned that the current API > doesn't go far enough. In essence, the current API favors putting status > presentation logic in the components of the status bar, rather than in the > status bar itself. If I'm reading correctly, several people have expressed > the desire to move more status bar logic into the status bar, and out of the > components. > > For example, ktm said: > "I expected to see someting like: > public void setStatus(String status) > public void statusChanged(StatusEvent se)" > > I'm very reticent to change my stance on this, but I'm still thinking this > over.
I don't think we need to provide a full event infrastructure, but there should be a way to update status text and a progress indicator. Most developers are going to expect this basic stuff from a status bar. It should be as simple as setStatus(String status) and setProgress(String descrption, int progress). statusChanged/progressChanged doesn't have to be in there.
If guts of the JXStatusBar are going to be beans, say a StatusItem interface, why not just make a default StatusMessageItem and ProgressItem and make their visibility configurable? That way the JXStatusBar is usable out-of-the-box.
Those who want to make a really cool looking status bar can then add their own StatusItem components using the JXStatusBar APIs.
Layout Manager Enhancements > Some think the layout manager as specified is too complicated (using the > "weight" system). At least one is also concerned that it doesn't handle the > main use cases (though I hope to have answered that). > > I'm really considering ditching weights and going with an enum containing > two values: FIXED and FILL. FIXED would respect Math.max(minSize, > prefSize). > > Status Bar Component Management > This covered the use cases surrounding how to manage the components in the > status bar. For example, you might want to hide a component, but have the > layout manager still reserve its space (including the separator). Or, you > might want to hide a component and effectively have it removed from the > status bar, but if made visible again, it would effectively be back in it's > original location. > > I consider this a critical use case that must be met.
FIXED and FILL enums would simplify things. If we are going all out - I think there should be a ResizeSparator that could allow one to resize the items of the JXStatusBar. It'd also be great of there was a way to group items to together, and reorder by drag and drop. (I am getting inspired here looking at the XP task bar...) [att1.html]
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 8:19 AM
in response to: Bill Snyder
|
|
|
> > For example, ktm said: > > "I expected to see someting like: > > public void setStatus(String status) > > public void statusChanged(StatusEvent se)" > > > > I'm very reticent to change my stance on this, but > > I'm still thinking this > > over. > > > I don't think we need to provide a full event > nt infrastructure, but there > should be a way to update status text and a progress > indicator. Most > developers are going to expect this basic stuff from > a status bar. It > should be as simple as setStatus(String status) and > setProgress(String > descrption, int progress). > statusChanged/progressChanged doesn't have to be > in there. > > If guts of the JXStatusBar are going to be beans, > s, say a StatusItem > interface, why not just make a default > StatusMessageItem and ProgressItem > and make their visibility configurable? That way the > JXStatusBar is usable > out-of-the-box.
I would be willing to have a constructor (heck, maybe even the default constructor) such that the JXStatusBar by default has message and progress areas. The troublesome part is adding API (setStatus, setProgress) because that will break if anybody removes the message and/or progress components from the status bar.
> FIXED and FILL enums would simplify things. If we > we are going all out - I > think there should be a ResizeSparator that could > allow one to resize the > items of the JXStatusBar. It'd also be great of there > was a way to group > items to together, and reorder by drag and drop. (I > am getting inspired here > looking at the XP task bar...)
This sounds like a feature enhancement. Down the road we could add another enum type, and add the appropriate logic to the UI delegates. This seems like gold-plating right now though -- I don't know of any status bars (FireFox, Windows Explorer, etc) that allows dynamic resizing of the cells.
Cheers Richard
|
|
|
|
|
|
|
|
Process [was - Re: JXStatusBar ready for public review]
Posted:
Sep 15, 2006 4:30 AM
in response to: rbair
|
|
|
Richard,
nice summary 
What I'm wondering: where do we go from here?
To recap the review process until now:
- the first (in you initial process announcement) impression about JXStatusBar was "as good as reviewed" - it seems to have passed the first internal review session without causing much excitement (? just guessing, not being part of it) - during the last days of public discussion it turned out that the abstraction "statusbar" had not yet been properly defined - the discussion converged to this summary and Patricks list of concrete requirements
As I see it, there's a heap of work ahead, both in design and implementation - when should that be done, pre- or post-swingx 1.0?
The options:
- interrupt the review process and replace our current "review" hat with the "design/implementation" hat until the comp receives its "reviewed" status
- stay in review mode: concede that the comp is not yet near enough to ready to make it to "reviewed" in a reasonable time frame and mark its status as "future"
I think we'll reach similar points of decision with other parts of swingx (there are more obvious construction sites than statusbar <g>), so we should have a strategy of how to handle it. My heart tells me to do the former, but that might well mean a release sometime in 2010 given our sparse resources ...
Thoughts?
Jeanette
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: Process [was - Re: JXStatusBar ready for public review]
Posted:
Sep 15, 2006 8:46 AM
in response to: Kleopatra
|
|
|
> What I'm wondering: where do we go from here?
I'm have a few more things to think about, and then I'll go rev the API. Remember, this is an API review, not an implementation review. It doesn't usually take very long to rev an API, especially one as simple as JXStatusBar.
> - the discussion converged to this summary and > Patricks list of concrete > requirements
Almost all of which, BTW, are already covered by the API and implementation.
> As I see it, there's a heap of work ahead, both in > design and > implementation - when should that be done, pre- or > post-swingx 1.0?
I don't think so. Most of the changes to the API are subtle/trivial (removing addSeparator, tweaks to the JXStatusBar.Constraint). Whether to have a .simple package with a JNStatusBar or some such thing (with setStatus, setProgress methods) is not relevant to *this* API, as it is built upon it.
My ultimate goal here is to release a SwingX 1.0. I want to review all the components we have. Where necessary, I'm happy with having a list of additional components we need to build, but for starters lets just get the stuff we have finalized.
> The options: > > - interrupt the review process and replace our > current "review" hat with > the "design/implementation" hat until the comp > receives its "reviewed" > status > > - stay in review mode: concede that the comp is not > yet near enough to > ready to make it to "reviewed" in a reasonable time > frame and mark its > status as "future"
Neither is necessary. By the end of today there will be another API posted, and an opportunity for another round of discussions. This may happen 2 or 3 times (or more!). People don't always agree on design (c.f. AbstractBean discussion!), but that doesn't mean a decision won't be made and the design finished. It is just a status bar, after all.
You don't see this, but APIs like JXErrorPane have gone through quite a few major API rev's due to the internal reviews. We have a LOT of work to do to review all these components.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 4:08 PM
in response to: rbair
|
|
|
I've done some more design work, and wanted to post with my findings. There is virtually no new API (addSeparator was removed, and Constraint is now:
public static class Constraint {
public static enum ResizeBehavior {FILL, FIXED}
public Constraint() {
this(ResizeBehavior.FIXED, null);
}
public Constraint(Insets insets) {
this(ResizeBehavior.FIXED, insets);
}
public Constraint(ResizeBehavior resizeBehavior) {
this(resizeBehavior, null);
}
public Constraint(ResizeBehavior resizeBehavior, Insets insets) {
this.resizeBehavior = resizeBehavior;
this.insets = insets == null ? new Insets(0, 0, 0, 0) : (Insets)insets.clone();
}
public ResizeBehavior getResizeBehavior() {
return resizeBehavior;
}
public Insets getInsets() {
return (Insets)insets.clone();
}
}
> Layout Manager Enhancements [trim] > I'm really considering ditching weights and going > with an enum containing two values: FIXED and FILL. > FIXED would respect Math.max(minSize, prefSize).
There was also a new request added by Jeanette to handle cells having the same size in relation to each other (presumably, not a fixed pixel size, but that they would take on whatever the largest preferred size of the group is).
I wrote an implementation of the layout manager that does both of these things (FIXED and FILL and cell groups), and I don't really like the "cells having the same size in relation to each other" part.
The design tension here is that the layout manager must be *simple*. The point isn't to support every layout situation imaginable (again: you can always use your own layout manager. In fact, I suspect most GUI builder types won't use this layout manager at all, but will just use GroupLayout. And for JGoodies fans, you can just use FormLayout if you need a really complicated status bar). The point is to support the 80-90% case very well, and let everything else be possible.
I don't see the requirement of cells containing the same width being that common. The workaround also isn't very difficult -- set the preferred size on each of the components, or use a different layout manager.
This is also the reason why I do like FIXED/FILL as opposed to weight. I think it addresses the 80% case.
In my mind, the most common use case will be:
A status bar with a message area with FILL followed and prefixed by one or more FIXED cells.
Every status bar we've looked at so far has fit with this general meme. Here is sample code. Note how only FILL is specified since usually only one component is going to have this attribute, and all the rest are FIXED by default:
//create and add the message label
JLabel messageLabel = new JLabel("Ready");
bar.add(messageLabel, JXStatusBar.Constraint.ResizeBehavior.FILL);
//create and add the mouse position indicator
final JLabel mousePositionLabel = new JLabel("");
bar.add(mousePositionLabel);
//create and add the progress bar
JProgressBar progress = new JProgressBar();
bar.add(progress);
> Status Bar Component Management In a previous message I listed plans A-C. I still favor B.
Cheers Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 20, 2006 8:24 PM
in response to: rbair
|
|
|
Plan B works for me.
>The problem with Plan B is that requires a controller of some kind that keeps the state when components are added or removed. I don't quite understand this. Don't all components maintain their own status. If I'm missing something, I would think it safe to assume that if a component is removed then added again it would be the same as when adding it the first time.
What is happening with this? Where can I get the latest source? I notice in CVS that JXTitledSeparatator is being updated as changes are agreed on, but JXStatusBar has had no movement for 3 weeks, and still uses weights. I would like to try the revised component.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 21, 2006 8:06 AM
in response to: rturnbull
|
|
|
> Plan B works for me. > > >The problem with Plan B is that requires a > >controller of some kind that keeps the state when > >components are added or removed. > > I don't quite understand this. Don't all components > maintain their own status. > If I'm missing something, I would think it safe to > assume that if a component is removed then added > again it would be the same as when adding it the > first time.
Somebody has to remember what the index of the component was. So if it was: bar.remove(3); //remove the 4th item, then somebody has to remember it was at index 3 to add it back in to the same place.
> What is happening with this? > Where can I get the latest source? > I notice in CVS that JXTitledSeparatator is being > updated as changes are agreed on, but JXStatusBar has > had no movement for 3 weeks, and still uses weights. > I would like to try the revised component.
I've been making the changes locally, but haven't updated CVS. I'll do so. Usually I don't update the components until after the reviews, to keep from making too many incompatible changes (I'd rather do it in one shot).
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 23, 2006 7:26 PM
in response to: rbair
|
|
|
Hi Richard
Tried out the JXStatusBar. Works well for me. setVisible(true/false) work fine, and the FIXED areas are maintaining there size on manual resizing. It even works with the FILL area in the middle 
A small problem and a few minor quibbles:
If you don't include at least 1 FILL area you get a divide by zero exception in Layout.layoutContainer().
There are no separators between the cells. I can add one myself and it works, but I have to remember to remove it if I remove the component. I would like to see all components added with a trailing separator, except the last. (I suppose in practice it means all added with a leading separator except the first.)
I would like to see some easy way of specifying the width of FIXED cells. I can do it myself with something like
l1 = new JLabel("In progress");
Dimension d = l1.getPreferredSize();
Dimension d2 = new Dimension(100, d.height);
l1.setPreferredSize(d2);
and it works, but its a bit messy and I have to do it for each FIXED component. Usually I only want to set the width - I don't want to intefere with the height. I guess this would require adding a width to constraints.
If I perform a bar.remove() or bar.add() after the bar has been displayed, I then have to do a bar.validate() to get it to show. I would like 'bar' to do it for me.
bar.add(comp, index) following bar.remove(idx) is a bit of a question, as bar.remove(idx) looses the constraints. (This is part of the component 'state' you referred to earlier) I'm not sure if this would be the expected behaviour. It's not a problem for me - I just point it out. I think it can be covered by the documentation. If you remove a component, it's removed. It's as if it was never there.
Also, I guess you already know, a lot of the documentation still need updating 
I can do some coding for some of these things if you like (If you want me to do some coding could you explain how you would want me to go about it. I have signed the agreement.)
Thanks Ray
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 25, 2006 3:06 AM
in response to: rturnbull
|
|
|
Hi Ray,
wonderful feedback (inclusive catching the reason for the dividebyzero).
Just a side comment (preaching again 
> > I would like to see some easy way of specifying the width of FIXED cells. I can do it myself with something like > > l1 = new JLabel("In progress");
> Dimension d = l1.getPreferredSize();
> Dimension d2 = new Dimension(100, d.height);
> l1.setPreferredSize(d2);
>
> and it works, but its a bit messy and I have to do it for each FIXED component. > Usually I only want to set the width - I don't want to intefere with the height. > I guess this would require adding a width to constraints.
To drive your point further: a layout which requires a setXXSize to make it work is broken. As a general rule client code must never ever call any of the setXXSize (with xx = pref, max, min). Doing so shortcuts each and every internal xxSize computation - which moves the responsibility to do so to the code which called the setXXSize. The overtake must be complete - "not interfere with height" is not possible, as you already noticed.
> > I can do some coding for some of these things if you like
greeeaaat, Richard sure will love it! Maybe you could start in the incubator?
Thanks a lot Jeanette
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 25, 2006 5:18 AM
in response to: Kleopatra
|
|
|
> To drive your point further: a layout which requires a setXXSize to make > it work is broken. As a general rule client code must never ever call > any of the setXXSize (with xx = pref, max, min). Doing so shortcuts each > and every internal xxSize computation - which moves the responsibility > to do so to the code which called the setXXSize. The overtake must be > complete - "not interfere with height" is not possible, as you already > noticed. >
[[ APPLAUSE! ]]
+1
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 25, 2006 8:27 AM
in response to: rturnbull
|
|
|
> setVisible(true/false) work fine, and the FIXED areas > are maintaining there size on manual resizing. > It even works with the FILL area in the middle 
Rich: 1 Bugs: 0
> If you don't include at least 1 FILL area you get a > divide by zero exception in > Layout.layoutContainer().
Rich: 1 Bugs: 1
> There are no separators between the cells. I can add > one myself and it works, but I have to remember to > remove it if I remove the component. > I would like to see all components added with a > trailing separator, except the last. > (I suppose in practice it means all added with a > leading separator except the first.)
Rich: 1 Bugs: 2
Yes, the LAF implementation should be drawing separators (not physically adding them, as that would throw off the getComponents() and getComponentCount() methods.). I just haven't finished the PLAF implementation yet.
> I would like to see some easy way of specifying the > width of FIXED cells. I can do it myself with > something like > > l1 = new JLabel("In progress");
> Dimension d = l1.getPreferredSize();
> Dimension d2 = new Dimension(100, d.height);
> l1.setPreferredSize(d2);
>
> and it works, but its a bit messy and I have to do it > for each FIXED component. > Usually I only want to set the width - I don't want > to intefere with the height. > I guess this would require adding a width to > constraints.
Sounds like it should be done, alright.
> If I perform a bar.remove() or bar.add() after the > bar has been displayed, I then have to do a > bar.validate() to get it to show. > I would like 'bar' to do it for me.
Hmmm, I'm going to run this one by Scott. The question I have is whether any other Swing components do this. I don't want to break semantics with existing Swing, even if I agree it's a pain!
> bar.add(comp, index) following bar.remove(idx) is a > bit of a question, as bar.remove(idx) looses the > constraints. > (This is part of the component 'state' you referred > to earlier) > I'm not sure if this would be the expected > behaviour. > It's not a problem for me - I just point it out. I > think it can be covered by the documentation. If you > remove a component, it's removed. It's as if it was > never there.
Yes, that is the expected behavior, just like with all other Swing components. It is a pain if you are adding/removing components a lot -- that's for sure!
> I can do some coding for some of these things if you > like > (If you want me to do some coding could you explain > how you would want me to go about it. I have signed > the agreement.)
Ya, sure, that would be great! There are two ways to go, either one is fine, whatever suits you. The first would be to develop against the main tree and submit patches to this thread. The second would be to develop in the incubator and give a pointer from this thread.
I really appreciate your help! Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 26, 2006 1:31 AM
in response to: rbair
|
|
|
I have created an issue https://swingx.dev.java.net/issues/show_bug.cgi?id=392 and attached a patch file with some fixes/enhancements.
Changes are:
Stop divide by zero exception.
Update documentation
Add preferredWidth to JXStatusBar.Constraint for FIXED resize behavior. I have added a setPreferredWidth(int width) method to the constraint. I did not wish to add any more constructors, although that would be helpful, but I did not think I should do it. I will leave that to more senior members if they think them neccessary 
I was a little surprised by the replies to my setPreferredSize suggestion (although I did say it was messy). I use Eclipse and in the visual editor the setxxSize properties are shown and I use them to try and get components to display the size I want. It seems I should not be doing this. I would be interested to know what method I should be using. The biggest problem I find laying out Swing components is to get them to display in the size I want. They even seem to change between the Eclipse VE and running, although thats probably an Eclipse problem.
I have not done anything about the separator. LAF is outside my sphere of competence. I would have overridden all the add(), remove() and getComponent.. methods to allow for the separators.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 26, 2006 1:39 AM
in response to: rturnbull
|
|
|
> I have not done anything about the separator. LAF is outside my sphere of competence. > I would have overridden all the add(), remove() and getComponent.. methods to allow for the separators.
I don't know if this is a LAF responsibility or not, but different programs on Windows, at least, follow different standard; some use a separator, but Firefox, for example, seems to be using a lowered bevel border (which was what I proposed in a much earlier revision of status bar). My sense is that one shouldn't have to add separators manually unless one wants "full control"; we could provide a parameter to the constructor as to what type of (automatic) separators one wants, or else just say it's an LAF responsibility.
By the way, Ray, I thought your feedback was, *as always*, *excellent*. Please keep it up! It's great work on your part, and always well presented and communicated.
Regards Patrick
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 26, 2006 7:31 AM
in response to: Patrick Wright
|
|
|
+1 on LAF being responsible for as much Look and Feel as possible.
Erik
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 26, 2006 8:57 AM
in response to: Patrick Wright
|
|
|
> I don't know if this is a LAF responsibility or not, > but different > programs on Windows, at least, follow different > standard; some use a > separator, but Firefox, for example, seems to be > using a lowered bevel > border (which was what I proposed in a much earlier > revision of status > bar). My sense is that one shouldn't have to add > separators manually > unless one wants "full control"; we could provide a > parameter to the > constructor as to what type of (automatic) separators > one wants, or > else just say it's an LAF responsibility.
Which OS are you running? In screenshots I've found of XP, it looks like status bars always use the separator (even for FireFox), whereas in W2K (iirc) and earlier platforms the status bar looked like it had lowered bevel borders for each "cell".
If it becomes a request, we could add a client property for the UI delegates to listen to indicating that they shouldn't paint the cell borders/separators automatically (similar to how we can turn off painting of the divider for a split pane).
> By the way, Ray, I thought your feedback was, *as > always*, > *excellent*. Please keep it up! It's great work on > your part, and > always well presented and communicated.
+1!
Cheers Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 26, 2006 9:13 AM
in response to: rbair
|
|
|
> Which OS are you running? In screenshots I've found of XP, it looks like status bars always use the separator (even for FireFox), whereas in W2K (iirc) and earlier platforms the status bar looked like it had lowered bevel borders for each "cell".
I'm running WinXP but with classic Windows look, due to client request (comes up in documentation/screenshot issues sometimes). So that's how they are painted in FF on Windows Classic, it seems. IDEA uses separators, Thunderbird and VMWare use borders.
Patrick
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 27, 2006 3:31 PM
in response to: Patrick Wright
|
|
|
Hey Patrick,
> I'm running WinXP but with classic Windows look, due > to client request > (comes up in documentation/screenshot issues > sometimes). So that's how > they are painted in FF on Windows Classic, it seems. > IDEA uses > separators, Thunderbird and VMWare use borders.
I've finished the JXStatusBar plaf implementation for Windows classic. Please give it a try when you get a chance. There might be a pixel off here and there, but overall it looks really good. I tested on XP with Windows Classic set.
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 27, 2006 8:50 PM
in response to: rbair
|
|
|
Tried out the latest JXStatusBar.
Couple of minor bugs (I think)
Laid out a bar with FIXED, FILL, FIXED When I removed the first FIXED, the last FIXED moved. Tracked it to line in BasicStatusBarUI.preferredLayoutSize() When checking whether to allow for separator, have line: if (constraints.size() < count) Think it should be if (count < constraints.size())
Second, spacing didn't seem quite right. I think it is because in BasicStatusBarUI.preferredLayoutSize() you include the bar insets in the preferred size. Then in BasicStatusBarUI.layoutContainer(), when calculating availableSpace, you subtract them again. Anyway when I commented out one subtracting insets, the width of all the components, separators and insets added up to the width of the bar.
Apart from those, everything else looks fine.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 26, 2006 8:52 AM
in response to: rturnbull
|
|
|
Hey Ray,
> I have created an issue > https://swingx.dev.java.net/issues/show_bug.cgi?id=392
Thank you!
I've applied the patch. I also added a few more Constraint constructors (let me know if they are sufficient). I also added the plaf logic for painting the separators. The layout manager was also moved to the PLAF for implementation reasons (the layout manager needs to know the size of the separators, and rather than adding a method to the StatusBarUI to do so, I decided to move the layout manager to the plaf).
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 26, 2006 8:52 AM
in response to: rbair
|
|
|
Oh, I haven't closed the issue, I'm awaiting feedback that all is well.
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 27, 2006 2:19 AM
in response to: rbair
|
|
|
> Oh, I haven't closed the issue, I'm awaiting feedback > that all is well. > > Richard
I've tried the new version - here's the feedback.
I think Constructor Constraint(ResizeBehavior resizeBehavior, Insets insets, int minPrefWidth) should be removed. Width only applies for FIXED. FIXED is the default if you don't specify anything. If you see the method setPreferredWidth(int) it sets preferred width to 0 if resize behaviour not FIXED regardless of what is passed in. There is no code in the layout to check that preferredWidth is only being used for FIXED - if FILL, it is assumed to be zero.
The only constructor missing is Constraints(Inset inset, int minPrefWidth) If this is added, I think setPreferredWidth() could be removed, unless someone feels there may be a need to change the width after a component has been added or constraints created.
The separators are not showing. I don't know why - its getting beyond me. It appears the code in BasicStatusBarUI.paint(), line x += comp.getWidth() would not be correct, as the area on the bar for most components would be greater than their width. This could cause the separators to be in the wrong place, It's possible they are being overridden by the components, but I would have thought the components are being painted first.
But I may be completely wrong. Have to read up on 'Painting in AWT and Swing'
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 27, 2006 11:10 AM
in response to: rturnbull
|
|
|
Hey Ray,
Your Constructor advise is sound -- I've committed the changes you've outlined.
> The separators are not showing. > I don't know why - its getting beyond me.
Argh. Sorry about that. I have it painting separators now, though they need to be tweaked (I'll get to it after lunch). Incidently, the reason it was being painted before, is because non-parented components don't paint.
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 27, 2006 2:53 AM
in response to: rturnbull
|
|
|
Hi Ray,
> > I was a little surprised by the replies to my setPreferredSize suggestion (although I did say it was messy). I use Eclipse and in the visual editor the setxxSize properties are shown and I use them to try and get components to display the size I want.
looks like again a builder is supporting bad habits 
About the "why not":
http://forums.java.net/jive/thread.jspa?threadID=9612
should contain most of the points (never made it to summarize)
> It seems I should not be doing this. I would be interested to know what method I should be using. > The biggest problem I find laying out Swing components is to get them to display in the size I want. They even seem to change between the Eclipse VE and running, although thats probably an Eclipse problem. >
As to the "what else" - use a powerful enough LayoutManager like JGoodies FormLayout. It has the screws at the right places. GBL simply isn't good enough - and at the same time overly complicated to use - to solve everyday problems (ducking <g> but googling most probably will turn up Karsten's very profound arguments)
Cheers Jeanette
--------------------------------------------------------------------- To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 27, 2006 10:36 PM
in response to: Kleopatra
|
|
|
> Hi Ray, > > > > > I was a little surprised by the replies to my > setPreferredSize suggestion (although I did say it > was messy). I use Eclipse and in the visual editor > the setxxSize properties are shown and I use them to > try and get components to display the size I want. > > looks like again a builder is supporting bad habits >  > > About the "why not": > > http://forums.java.net/jive/thread.jspa?threadID=9612 > > should contain most of the points (never made it to > summarize) > > > As to the "what else" - use a powerful enough > LayoutManager like > JGoodies FormLayout. It has the screws at the right > places. GBL simply > isn't good enough - and at the same time overly > complicated to use - to > solve everyday problems (ducking <g> but googling > most probably will > turn up Karsten's very profound arguments) > > Cheers > Jeanette
Read the thread. Whew - nearly came to blows there. How did you know whether I would back Holland or Germany. Fairly convinced. Must have a look at JGoodies FormLayout
Thanks
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 28, 2006 6:59 PM
in response to: rturnbull
|
|
|
> Must have a look at JGoodies FormLayout > > Thanks
You really should. We wouldn't survive without it. I believe the GroupLayout satisfies most of the style guide concerns that were voiced in that thread.
Erik
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 6:39 AM
in response to: rbair
|
|
|
I hope I'm not too late, but I like the current API for the JXStatusBar. It has what a lot other of the other components' apis lack, which is simplicity.
To my mind, it is the domain of an app framework, be it JSR 296/Spring RCP/Eclipse RCP/Netbeans, to provide the application specific facilities, such as setStatus(String) or setProgress(int).
I think swing has fallen into this trap too much, of adding to much app framework facilities into what should be a GUI toolkit. There should be a clearer division of responsibilities, like the eclipse/jface/swt relationship.
Just my 2p, Dan.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Sep 15, 2006 8:47 AM
in response to: dgodfrey99
|
|
|
> I hope I'm not too late, but I like the current API > for the JXStatusBar. It has what a lot other of the > other components' apis lack, which is simplicity. > > To my mind, it is the domain of an app framework, be > it JSR 296/Spring RCP/Eclipse RCP/Netbeans, to > provide the application specific facilities, such as > setStatus(String) or setProgress(int).
I couldn't agree more.
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Oct 6, 2006 1:30 PM
in response to: rbair
|
|
|
I might be using the JXStatusBar incorrectly, and if so I apologize, but I believe there to be a miscalculation when figuring out the space for FILLed components. Here is an example of what I did.
JXStatusBar statusBar = new JXStatusBar(); JXStatusBar.Constraint c = new JXStatusBar.Constraint(JXStatusBar.Constraint.ResizeBehavior.FILL); statusBar.add(new JLabel("Label1", c)); statusBar.add(new JLabel("Label2", c)); statusBar.add(new JLabel("Label3", c));
With this I was expecting a status bar with 3 labels where each one occupied 1/3 of the space. What I initially got was 3 very small labels and a bunch of blank space. I believe that this had to do with the calculation for the percentage of blank space and a double/int typecasting issue. After I fixed that I then had 1 label that took 1/3 of the space, one that took less than that, and the final taking even less. I believe this to be a result of calculating the space for the FILLed component as its layed out by taking a portion from the availableSpace which gets decrimated each time a component is added.
I believe that the following patch fixes both issues.
BasicStatusBarUI.java Index: src/java/org/jdesktop/swingx/plaf/basic/BasicStatusBarUI.java =================================================================== RCS file: /cvs/swingx/src/java/org/jdesktop/swingx/plaf/basic/BasicStatusBarUI.java,v retrieving revision 1.8 diff -r1.8 BasicStatusBarUI.java 281,282c281 < double weight = numFilledComponents > 0 ? 1 / numFilledComponents : 0; < --- > double weight = numFilledComponents > 0 ? 1.0 / (double)numFilledComponents : 0.0; 291a291,300 > //figure out how much available space there will be > for (int i=0; i < parent.getComponentCount(); i++) { > Component comp = parent.getComponent(i); > Constraint c = constraints.get(comp); > Constraint.ResizeBehavior rb = c == null ? null : c.getResizeBehavior(); > if (rb != null && rb != Constraint.ResizeBehavior.FILL) { > Insets insets = c.getInsets(); > availableSpace -= c == null ? 0 : c.getPreferredWidth() - insets.left - insets.right; > } > } 302c311 < availableSpace -= spaceToTake; --- > //availableSpace -= spaceToTake;
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Oct 6, 2006 1:34 PM
in response to: bconnors
|
|
|
Excellent! Thanks for the patch. I must have missed some things when converting from percentage weights to FILL constraints. I'll apply that shortly.
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Oct 6, 2006 4:20 PM
in response to: rbair
|
|
|
Hmmm, NetBeans is complaining and I can't quite tell from this patch where this is applied. Did you create the patch using the latest from CVS?
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Oct 6, 2006 4:53 PM
in response to: rbair
|
|
|
hmmm... yes I created against the latest version. In fact I used cvs diff to create the patch against what I had checked out. I'm not a netbeans users so I can't really help you there. Perhaps the issue is because I didn't create the patch from the root of the cvs project. The patch itself applies to the layoutContainer(...) method of the LayoutManager created inside BasicStatusBarUI. The typecast change occurs where the double weight is defined (line 281) and the logic that calculate the available space begins at line 291. I also commented out line 302. I have also reattached a patch created from the root of the CVS repository. Hope this helps.
Index: src/java/org/jdesktop/swingx/plaf/basic/BasicStatusBarUI.java =================================================================== RCS file: /cvs/swingx/src/java/org/jdesktop/swingx/plaf/basic/BasicStatusBarUI.java,v retrieving revision 1.8 diff -r1.8 BasicStatusBarUI.java 281,282c281 < double weight = numFilledComponents > 0 ? 1 / numFilledComponents : 0; < --- > double weight = numFilledComponents > 0 ? 1.0 / (double)numFilledComponents : 0.0; 291a291,300 > //figure out how much available space there will be > for (int i=0; i < parent.getComponentCount(); i++) { > Component comp = parent.getComponent(i); > Constraint c = constraints.get(comp); > Constraint.ResizeBehavior rb = c == null ? null : c.getResizeBehavior(); > if (rb != null && rb != Constraint.ResizeBehavior.FILL) { > Insets insets = c.getInsets(); > availableSpace -= c == null ? 0 : c.getPreferredWidth() - insets.left - insets.right; > } > } 302c311 < availableSpace -= spaceToTake; --- > //availableSpace -= spaceToTake;
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Oct 30, 2006 11:26 AM
in response to: bconnors
|
|
|
It's been a while since the last bug/rfe for JXStatusBar. It looks pretty much complete. If there are no objections, I'd like to mark this component as "REVIEWED" and get it off my todo list.
Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 1, 2006 8:33 AM
in response to: rbair
|
|
|
Is the XP colours RFE (issue 295) to be done? If not, can anyone point me to how I can determine the current XP theme so I can override the JXStatusBar use of the same colour for all themes?
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 1, 2006 9:35 AM
in response to: johnpm
|
|
|
Found how to do that in the meantime, so here's a filthy hack that works. I made the "silver-" pngs by cropping the relevant bits from the IE taskbar (which is 23 pixels high rather than 22 like the current status bar pngs but otherwise is the same).
public WindowsStatusBarUI() {
try {
// filthy hack to get correct color match for XP silver color scheme
String pngprefix = "resources/" +
(OS.getWindowsVisualStyle().contains("etallic")
? "silver-"
: "");
leftImage = ImageIO.read(getClass().getResource(pngprefix+"statusbar-left.png"));
middleImage = ImageIO.read(getClass().getResource(pngprefix+"statusbar-middle.png"));
rightImage = ImageIO.read(getClass().getResource(pngprefix+"statusbar-right.png"));
} catch (Exception e) {
//hmmmm... should log this I guess
}
}
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 1, 2006 10:42 AM
in response to: johnpm
|
|
|
Looks about right . Has a bug been filed for this yet?
Thanks! Richard
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 1, 2006 10:42 AM
in response to: rbair
|
|
|
Just saw, I guess there is. Now I just need an XP machine and some pngs...
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 1, 2006 4:54 PM
in response to: rbair
|
|
|
Just came across another problem, maybe it is something I don't have set up correctly? Get this error when I try to use the Metal L&F (on an XP machine):
UIDefaults.getUI() failed: no ComponentUI class for: org.jdesktop.swingx.JXStatusBar[,0,0,0x0,invalid,layout=java.awt.FlowLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=] java.lang.Error at javax.swing.UIDefaults.getUIError(UIDefaults.java:691) at javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:117) at javax.swing.UIDefaults.getUI(UIDefaults.java:721) at javax.swing.UIManager.getUI(UIManager.java:860) at org.jdesktop.swingx.plaf.LookAndFeelAddons.getUI(LookAndFeelAddons.java:283) at org.jdesktop.swingx.JXStatusBar.updateUI(JXStatusBar.java:173) at javax.swing.JPanel.<init>(JPanel.java:64) at javax.swing.JPanel.<init>(JPanel.java:87) at javax.swing.JPanel.<init>(JPanel.java:95) at org.jdesktop.swingx.JXPanel.<init>(JXPanel.java:111) at org.jdesktop.swingx.JXStatusBar.<init>(JXStatusBar.java:122)
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 1, 2006 11:27 PM
in response to: johnpm
|
|
|
Are you building from source? Sometimes I have to do a build all, even when I haven't touched the LAF code.
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 2, 2006 1:34 AM
in response to: rbair
|
|
|
Yes, am building from source, but somehow I managed to miss the metal plaf status bar file, all OK now - sorry for the false alarm.
Message was edited by: johnpm
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 2, 2006 2:20 AM
in response to: johnpm
|
|
|
Two more problems I'm having:
- If the L&F is changed while my app is running the status bar ends up a few pixels tall, can't get it to correct itself even explicitly calling revalidate() on it or calling validate() on its container. It is added as BorderLayout.SOUTH
- I have a couple of labels on the bar just added using add(component), the first label has text that varies. When it changes, the separator between the text moves but the top and bottom parts stay where they were (until something causes a full repaint like minimising or obscuring with another window). Can't upload an image just now, but for a hint of what I mean, it ends up looking something like this:
----------------------------------------------
|
|
Label whose text got longer|other label
|
|
----------------------------------------------
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 2, 2006 8:09 AM
in response to: johnpm
|
|
|
Thanks for reporting these. Can you provide a small runnable test case that shows the problems, so we can write unit tests and know when we've fixed the bug?
Thanks Richard
> - If the L&F is changed while my app is running the > status bar ends up a few pixels tall, can't get it to > correct itself even explicitly calling revalidate() > on it or calling validate() on its container. It is > added as BorderLayout.SOUTH > > - I have a couple of labels on the bar just added > using add(component), the first label has text that > varies. When it changes, the separator between the > text moves but the top and bottom parts stay where > they were (until something causes a full repaint like > minimising or obscuring with another window). Can't > upload an image just now, but for a hint of what I > mean, it ends up looking something like this: > > > ----------------------------------------------
> |
> |
> Label whose text got longer|other label
> |
> |
> ----------------------------------------------
>
|
|
|
|
|
|
|
|
Re: JXStatusBar ready for public review
Posted:
Nov 2, 2006 9:17 AM
in response to: rbair
|
|
|
Here you go. The separator problem doesn't occur if you start up with Metal L&F, I guess because you only added the extension of the separator to full height for the Windows L&F?
Aside: it would be helpful if the forum software didn't try and parse for tags within code blocks, else it strips out things like an array index of i because it treats it as an italics code, and turns a ; followed by a ) into a wink - makes the code more interesting though
/**
* StatusBarBugs.java
* Created on 2 November 2006, 16:40
**/
import java.awt.BorderLayout;
import java.awt.Dimension;
import java.awt.EventQueue;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.Enumeration;
import javax.swing.AbstractAction;
import javax.swing.AbstractButton;
import javax.swing.Action;
import javax.swing.BoxLayout;
import javax.swing.ButtonGroup;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JRadioButton;
import javax.swing.SwingUtilities;
import javax.swing.UIManager;
import org.jdesktop.swingx.JXStatusBar;
/** @author JohnM */
public class StatusBarBugs extends JFrame{
public StatusBarBugs() {
setTitle("Status Bar Bugs");
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setLayout(new BorderLayout());
final String MSG1 = "message";
final String MSG2 = "longer message";
final JLabel msg1 = new JLabel(MSG1);
JButton b = new JButton("Press me to change status label text");
b.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
msg1.setText(msg1.getText().equals(MSG1) ? MSG2 : MSG1);
}
});
ButtonGroup lafsGroup = new ButtonGroup();
UIManager.LookAndFeelInfo[] lafs = UIManager.getInstalledLookAndFeels();
String uiName = UIManager.getLookAndFeel().getName();
for (int j=0; j<lafs.length; j++){
if (!lafs[j].getName().startsWith("CDE")){
final UIManager.LookAndFeelInfo LAF = lafs[j];
Action anAction = new AbstractAction(LAF.getName()) {
public void actionPerformed(ActionEvent e) {
try {
String laf = LAF.getClassName();
UIManager.setLookAndFeel(laf);
SwingUtilities.updateComponentTreeUI(StatusBarBugs.this);
StatusBarBugs.this.validate();
} catch (Exception ex) {
ex.printStackTrace();
}
}
};
JRadioButton anItem = new JRadioButton(anAction);
lafsGroup.add(anItem);
anItem.setSelected(uiName.equals(LAF.getName()));
}
}
JPanel p = new JPanel();
p.setLayout(new BoxLayout(p, BoxLayout.Y_AXIS));
add(p, BorderLayout.CENTER);
p.add(b);
for (Enumeration<AbstractButton>e = lafsGroup.getElements(); e.hasMoreElements(); ){
p.add(e.nextElement());
}
JXStatusBar bar = new JXStatusBar();
bar.add(msg1);
bar.add(new JLabel("another message"));
add(bar, BorderLayout.SOUTH);
setLocation(100,100);
pack();
}
public static void main(String[] args) {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
}
catch (Exception ex) {
ex.printStackTrace();
}
final StatusBarBugs sbb = new StatusBarBugs();
EventQueue.invokeLater(new Runnable(){
public void run(){
sbb.setVisible(true);
}
});
}
}
|
|
|
|
|