Skip to main content

SpringLayout and GUI builders

96 replies [Last post]
jtr
Offline
Joined: 2003-06-10

Back at JavaOne 2000, there was a demo of the SpringLayout manager. The demo looked _quite_ good because it used a GUI forms designer. My understanding is that the API for SpringLayout is in fact optimized for GUI forms designers.

But I haven't seen an IDE with a forms designer that handles SpringLayout. Does such an IDE exist?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kleopatra
Offline
Joined: 2003-06-11

> > In detail I assume two things that are
> > valid for the MS and Aqua style guides as well as
> for
> > all l&fs I'm aware of - except the UIC l&f: 1) the
> > style guide height is in the interval [min, max]
>
> That will give bad results with users that set a
> minimum size to a widget they want to be a specific
> size.
> Take for example a button where the title can change.
> (the month button in a calendar) setting the minimum
> size will have no effect in your case. The user has
> to set both the minimum and the preferred size.

Yes - the pref size will have to be adjusted as well. But not necessarily by the user: you can shield her by doing it transparently somewhere in the transformation(s) of the output of the qt-designer to java code.

> I'm also getting a bit tired of your constant judging
> my work with 'stabs' like these; you found a mistake,
> fine. Then lets fix it and STOP sabotaging the
> discussion like this.

keep calm ... nobody is sabotaging anything you do.

> When you ask for an example what is going wrong with
> FormLayout, and I give it to you; don't respond with
> finding mistakes in UICompiler.
> I don't want to discuss like this.

You never came up with an example that proved FormLayout to be wrong - only with examples that proved the widget's reporting of default sizes to be at least questionable if not plain wrong (at the moment I count a 3:1 one vote for "wrong sizes" if pref < min :-).

Greetings
Jeanette

karsten
Offline
Joined: 2003-06-11

> I'm afraid that a JButton's getMaximumSize will not
> return infinite, how did you come to that conclusion?

Check methods #getMaximumSize in classes Component, Container and JComponent. As with every JComponent, the JButton answers an infinite maximum size unless the developer sets or the UI delegate answers a custom maximum size. In addition, a layout manager that implements LayoutManager2 could respond a small size to #maximumLayoutSize, which would change the behavior in Container.getMaximumSize()

And yes, as far as I can see, BasicButtonUI.getMaximumSize honors the view - but only in HTML mode. Anyway, I think we agree that this is a questionable implementation.

I haven't checked the following L&f's whether they actually report a custom maximum size to the JButton instance: Alloy, Aqua, BEA l&f, IDEA L&f, Oracle Win L&f, SAP Platin L&f, Skin l&f, Synth, TinyLAF and the Together L&f. And I doubt anyone else has ;)

Anyway, I'd like to focus our discussions on the more severe problems. And I've never seen a developer who had a problem with a button maximum size. But the majority of Swing UIs one can see in the public doesn't align buttons well; often three buttons have three widths; and only rarely button bars are consistent over panels, applications and teams; not to say that only very few button bars honor the Mac Aqua and MS layout Style Guides.

mthornton
Offline
Joined: 2003-06-10

> > The funny thing is that most Swing widgets just
> > return the same min and pref sizes, and many even
> > return the same size for the maximum.
>
> Where it matters they don't.

How about JButton? The maximum size returned by this for an OK button is rather less than most style guides would recommend.

I have been playing around with some code to help me create SpringLayout's which do everything properly. It seems I need a few special Spring classes to override behaviour such as JButton.

karsten
Offline
Joined: 2003-06-11

> How about JButton? The maximum size returned by this for an
> OK button is rather less than most style guides would recommend.

A JButton's maximum size is infinite unless the l&f overrides that. I'd say the l&f should not limit the size. The BasicButtonUI answers the preferred size as maximum size, which is no good choice.

zander
Offline
Joined: 2003-06-13

> > How about JButton? The maximum size returned by
> this for an
> > OK button is rather less than most style guides
> would recommend.
>
> A JButton's maximum size is infinite unless the l&f
> overrides that. I'd say the l&f should not limit the
> size. The BasicButtonUI answers the preferred size as
> maximum size, which is no good choice.

I'm afraid that a JButton's getMaximumSize will not return infinite, how did you come to that conclusion?

The situation is that a JButton has a maximumSize equal to its preferred size, just like all widgets in Swing that don't have a getMaximumSize() method.
Saying that the BasicButtonUI answers the preferred size is also not the full truth; it does specify a larger width then the preferred size based on the view.

I think I agree with Karsten that the maximum size of a button should be infinite; at least in horizontal direction. Not entirely sure here...

mthornton
Offline
Joined: 2003-06-10

I think Karsten meant that a JButton could return max=Infinite for some (theoretical) L&F, it just that for the L&F that I have tried it returns the preferred size.

kleopatra
Offline
Joined: 2003-06-11

> >
> > A minimum value is <= all other values in the
> related
> > space; the maximum value is >= all other values in
> > this space; and so it follows that min <= pref <=
> > max.
>
> You make the classic mistake of mixing up speaker
> positions.

> If the space of person A is restricted by B the
> definition is that A can not move outside of that
> space.
> It is not that B can't ask A to leave that space.

please don't switch your context arbitraryly: we are talking about widgets not persons. From the perspective of the widget (being a well-behaved OO class) there's only A = component: it bounds it's own default space to be between min and max. Being a well behaved OO class it will adjust all internal state (that's the prefsize) to stay within those bounds. The actual size is decided by B = layoutManager: it may or may not honor the reported defaults from the widgets but it can assume that the widget is well-behaved. So it's _not_ the manager#s responsibility to check for "illegal" prefs...

> According to the same method it would be illegal for
> me to ask a JSlider to be set to 100 when its model
> allows a maximum of 80.

the model has to take care (and does so) of consistent ordering and guarantees min <= value <= max. So where do you see any analogy?

>
> Besides; Sun has rejected a bugreport based on the
> same question to me; where is it written in the API,
> which I could naturally not answer.

Just curious: are there any Swing Comps (and if so which?) that do report their pref size outside the range of min/max by default?

>
> This is not documented and in my software the layout
> manager honours these sizes.

then your LayoutManager arbitrarily decides to switch strategies (from trying to respect pref to respect min).

Greetings
Jeanette

zander
Offline
Joined: 2003-06-13

Just to clear up some fog.

> > If the space of person A is restricted by B the
> > definition is that A can not move outside of that
> > space.
> > It is not that B can't ask A to leave that space.
> please don't switch your context arbitraryly: we are
> talking about widgets not persons.

That is the idea of an analogy.

> > Take for example a button where the title can change.
> > (the month button in a calendar) setting the minimum
> > size will have no effect in your case. The user has
> > to set both the minimum and the preferred size.

> Yes - the pref size will have to be adjusted as well.

That is not acceptable; the pref size changes with a change of content. Setting a preferred size on a Component is forever. It is not changed anymore based on content, ever.

Take a JComboBox. Imagine a combo that has entries based on other widgets settings. So it will sometimes be empty and other times have 10 entries and other times 20 other entries.
The combobox (the Metal default one) has a minimum size that is very small, and a very small combobox does not really look like a combobox to the user. (Its a couple of pixels wider then its icon)
So the designer decides to set a minimum size. He can't set the preferredSize since his widget will never correctly size anymore if he does.
Inserting a long string will cut that string, and making it really wide even when there is no content is also ugly.

> I view it as a violation of the widget's contract

Unfortunately for all of us, Swing does follow the contract you want it to.
When I set the minimum size on a widget and that same widget reports a preferredSize smaller then the minimum size. This is coded like that in Component and all you say here about how it should be is irrelevant since Swing has been doing it different since day 1.

kleopatra
Offline
Joined: 2003-06-11

Hi Thomas,

> Just to clear up some fog.

sorry to hear that you have a fog problem around your place - here in Berlin everything is clear and sunny :-)

>
> > > If the space of person A is restricted by B the
> > > definition is that A can not move outside of
> that
> > > space.
> > > It is not that B can't ask A to leave that
> space.
> > please don't switch your context arbitraryly: we
> are
> > talking about widgets not persons.
>
> That is the idea of an analogy.

The idea of an analogy is to make things easier to understand. A prerequisitive to be helpful is a) that the analog situation is commonly experienced by all participants of a discussion and b) the person who introduces the analogy explains the parallels of the actors. In this concreate analogy neither a) nor b) are fulfilled: a) I have never been to a prison in any of those roles (the most common place where some person restricts the space of another) and b) you forgot to explain who A and B are.

>
> > Yes - the pref size will have to be adjusted as
> well.
>
> That is not acceptable; the pref size changes with a
> change of content. Setting a preferred size on a
> Component is forever. It is not changed anymore based
> on content, ever.

Read carefully: I said "adjusted", not "set" ... Your argument against setting holds for min/max sizes as well. BTW: where in your system do you check if min <= max after setting the min?

>
> Take a JComboBox. Imagine a combo that has entries
> based on other widgets settings. So it will sometimes
> be empty and other times have 10 entries and other
> times 20 other entries.
> The combobox (the Metal default one) has a minimum
> size that is very small, and a very small combobox
> does not really look like a combobox to the user.
> (Its a couple of pixels wider then its icon)
> So the designer decides to set a minimum size. He
> can't set the preferredSize since his widget will
> never correctly size anymore if he does.
> Inserting a long string will cut that string, and
> making it really wide even when there is no content
> is also ugly.
>

You seem to have an impedance mismatch between the semantics of your designer (I assume that's a human using qt-designer) and java code. Setting a min of a component in the first need not be mapped into a jcomp.setMinimumnSize(..) in java. In fact jcomp.setMin/Max/PrefSize() should be banned from general usage because it leads to quite a bunch of problems as you see. _You_ provide the transformation and can easily find a better mapping.

> > I view it as a violation of the widget's contract
>
> Unfortunately for all of us, Swing does follow the
> contract you want it to.

ehhh, if it follows the contract I'm happy :-) Does it?

> When I set the minimum size on a widget and that same
> widget reports a preferredSize smaller then the
> minimum size.

then don't set the min/max/pref - exposing these methods to public access is a design accident anyway. Or lobby to have the implementation of the widgets changed so that the contract _is_ respected.

> This is coded like that in Component
> and all you say here about how it should be is
> irrelevant since Swing has been doing it different
> since day 1.

Be careful what you call "irrelevant" ...

Greetings
Jeanette

zander
Offline
Joined: 2003-06-13

> Hi Thomas,
> > Just to clear up some fog.
> sorry to hear that you have a fog problem around your place - here in Berlin everything is clear and sunny
Hi Jeanette, can I come over? :-)

> In fact
> jcomp.setMin/Max/PrefSize() should be banned from
> general usage because it leads to quite a bunch of
> problems as you see.

I really like you thinking along with me on this; until now I am not convinced that I have to do the sizing of widgets using a different system then min/max/pref sizes.

The funny thing is that most Swing widgets just return the same min and pref sizes, and many even return the same size for the maximum.
In effect, the sizes are not used in any layout manager, except for NaturalLayout. (Karsten said the FormLayout also does not use them). I like that since I can change the min/max sizes and create easier to create UIs when you use NaturalLayout, without breaking existing UIs using a different layout manager.

I very strongly believe in locality of intel. No matter how hard a system seems to the eye; when you put the right information in the correct place, it all falls into place.

Up until now I just fixed widgets that seemed wrong to me, with my experience with other layouting systems. I'll try to write a whitepaper on what min/max/pref sizes of the various widgets should be. Learning from widget sets like Motif, Qt, Amiga GraphicsLibrary and others.

Today I had a dialog opening to be 7000 pixels of height, since the TextArea having a minimumSize equal to the preferredSize and both set to 7000 pixels for a moderate amount of text. Looking at others; the minimum size should be based the whole widget being visible, not on all CONTENT being visible!, that is just unrealistic.

karsten
Offline
Joined: 2003-06-11

> The funny thing is that most Swing widgets just
> return the same min and pref sizes, and many even
> return the same size for the maximum.

Where it matters they don't.

> In effect, the sizes are not used in any layout
> manager, except for NaturalLayout. (Karsten said the
> FormLayout also does not use them).

Just to clarify this: I use the min and pref size and provide an additional mix of them if space is scarce - my [i]default[/i] size. I don't use the maximum size, just because I can ensure valid bounds implicitly.

> Up until now I just fixed widgets that seemed wrong to me,
> with my experience with other layouting systems.
> I'll try to write a whitepaper on what min/max/pref sizes
> of the various widgets should be.

Great.

One issue I had overseen before checking your sources: your approach of modifying the min/pref/max sizes seems to work only with a single l&f - your UIC l&f. Does this mean that the UIC won't work with the Aqua l&f, or Sun's Windows emulation, or the Synth l&f?

If you feel a need to override or change the context-free default sizes answered by the components, you may consider applying your changes to all l&fs. And it seems to me that this leads to an extracted sizing system. Again, I recommend that you let a UIC user annotate components so that she can tell a component how it should be sized - regardless of the l&f. If you as provider put in your default sizes, I'd say everyone will welcome that.

Last but not least: do you plan to support the MS style guide? If so, I'd like to learn about your roadmap how to do so - even if it is a raw estimate. I'm in the process of thinking about the next major version of the Forms and would like to unite findings - if possible.

zander
Offline
Joined: 2003-06-13

> your approach of modifying the min/pref/max
> sizes seems to work only with a single l&f - your UIC
> l&f. Does this mean that the UIC won't work with the
> Aqua l&f, or Sun's Windows emulation, or the Synth
> l&f?

That is right, due to the experience I had with widgetsets like Qt I was surprised by the lack of good min/max/pref sizes as I found was needed.
This I called bugs.
When I reported (other) issues to Sun as being bugs I learned that bugreports to Sun had no use, due to various reasons. (the most important being that discussing design has to be done personally, electronically is just not an option)

We made changes in the L&F for a very simple reason. Because that is the only place where it is possible.

I personally can't be bothered with look and feels that are not portable, Swing is meant to be platform independent and writing for a Windows look and feel seems silly at best, I develop on Linux and since 1.4 don't really have to try my GUIs on Windows, they simply work the same.
While this is very personal, my software will not take into account L&Fs that I can't even test.
Don't get me wrong here! I am not opposed at all to users setting Windows L&F or even if really silly people set their L&F to the GTK one, all the power to them! I just wont go out of my way to accomodate them.

> If you feel a need to override or change the
> context-free default sizes answered by the
> components, you may consider applying your changes to
> all l&fs. And it seems to me that this leads to an
> extracted sizing system. Again, I recommend that you
> let a UIC user annotate components so that she can
> tell a component how it should be sized - regardless
> of the l&f.

Nice idea, and one that Jeanette also mentioned. There is a reason Sun put the sizing into the L&F, its because different L&Fs have difference sizes, I can't change that, nor do I want to.
Besides; how many good L&Fs are there in use, really, if the work on sizing proves to be advantages it is my hope that more L&F providers will implement it. Maybe the Metal (or Basic) L&F will even change. Ok, thats over the top, but the point is that we need to break some eggs here, no point in putting yet another layout on top of this allready huge design framework.

> Last but not least: do you plan to support the MS
> style guide? If so, I'd like to learn about your
> roadmap how to do so - even if it is a raw estimate.
> I'm in the process of thinking about the next major
> version of the Forms and would like to unite findings
> - if possible.

Hmm, hard one roadmap (limited to LMs)
1) alter NaturalLayout to allow sizing policy of widgets.
2) Write WhitePaper to define min/max/pref sizes of widgets in one universal manner.
3) fix any inconsistencies in UICTheme
4) Make an inventory of what kind of 'widgets' there are in the style guides (command etc)
5) Make up a system to tell the layout manager about these things. I think I will have to talk to you (Karsten) for that :)
6) Implement it in the layout manager
7) alter the UIC to provide these values when possible.
8) If not already done; alter the NaturalLayout to layout multiple containers and be able to keep the column/row sizes equal accross these different containers.

You probably want to know about time, and that is even harder to answer since my friends in the UICompiler project are not really 'planned', and neither am I : )
Too many things to do, still working on my patch for the universe to give us 48 hours a day...
Anyway; I think I can start with point 4 in oct/nov.

zander
Offline
Joined: 2003-06-13

> In detail I assume two things that are
> valid for the MS and Aqua style guides as well as for
> all l&fs I'm aware of - except the UIC l&f: 1) the
> style guide height is in the interval [min, max]

That will give bad results with users that set a minimum size to a widget they want to be a specific size.
Take for example a button where the title can change. (the month button in a calendar) setting the minimum size will have no effect in your case. The user has to set both the minimum and the preferred size.
I'm also getting a bit tired of your constant judging my work with 'stabs' like these; you found a mistake, fine. Then lets fix it and STOP sabotaging the discussion like this.
When you ask for an example what is going wrong with FormLayout, and I give it to you; don't respond with finding mistakes in UICompiler.
I don't want to discuss like this.

> and
> 2) only components that have an infinite maximum
> width (like a text field, list or table) are allowed
> to fill a growing column horizontally. The first
> assumption is valid, just because the style guides
> have been reasonably defined. And in the past decade
> I've never seen a component that restricted its
> maximum size _and_ was asked to grow beyond that
> upper bound.

Funny; your FormLayout (and related files) has no call to any getMaximumSize at all...

I have tried similar approaches and I failed getting a good GUI like this. The code always needs manual tweaking to get it to look reasonable.

It seems that the most basic of things (to me at least) is something that we can't agree on, we never even got to the more interesting concepts.
I think I'll just forget about a cooperation for now.

karsten
Offline
Joined: 2003-06-11

> That will give bad results with users that set a
> minimum size to a widget they want to be a specific size.

I was just talking about the 90% default case. Sure FormLayout can honor a widget's minimum size.

> I'm also getting a bit tired of your constant judging
> my work with 'stabs' like these; you found a mistake,
> fine. Then lets fix it and STOP sabotaging the
> discussion like this.

Sorry if this is a misunderstanding; that's why I suggested to talk on the phone where it is much easier to clarify things, moods and motivations. I hesitate to value other people's work and I'm only interested in bringing good design to Java and in assisting others. But there's one situation where I speak up: if someone has a statement that is misleading or wrong. You've claimed again and again that you've found and fixed bugs where I'm just saying: your findings are questionable - be careful to call them bugs.

> When you ask for an example what is going wrong with FormLayout,
> and I give it to you; don't respond with finding mistakes in UICompiler.

Sure I wasn't eager to find bugs in the UIC l&f. It's just that I had to look into the code to understand what your [i]good[/i] default sizes are - you didn't provide that. I wanted to discuss, but it turned out that I couldn't really; the sizes break Swing constraints.

> > 2) only components that have an infinite maximum
> > width (like a text field, list or table) are allowed
> > to fill a growing column horizontally. The first
> > assumption is valid, just because the style guides
> > have been reasonably defined. And in the past
> decade
> > I've never seen a component that restricted its
> > maximum size _and_ was asked to grow beyond that
> > upper bound.
>
> Funny; your FormLayout (and related files) has no
> call to any getMaximumSize at all...

I've explained it in the section you quoted: it is just unnecessary to ask for the maximum size if you only let components grow that have no size limit.

Again, let's talk on the phone. I'm sure we can talk friendly about these issues.

karsten
Offline
Joined: 2003-06-11

> > If a component's sizes don't satisfy min<=pref<=max,
> > then I think a layout manager can do anything it
> > likes. [...]
>
> Where in the API does it say so? [...]

See the docs for Component.getMinimumSize(). It assumes a natural language understanding of what is 'minimum', 'size' and how to compare these sizes (how the semi-lattice for the <= relation is defined).

A minimum value is <= all other values in the related space; the maximum value is >= all other values in this space; and so it follows that min <= pref <= max.

> If a component (no matter if its wrong) reports a certain size
> should the layout manager honor that?

In my view a good layout manager shall be able to honor or override that size; personally speaking, I always honor it. In all my panels about 90% of the FormLayout component constraints use the following defaults: the width honors the component min and pref sizes in a grid column and applies the maximum of all pref widths to all components and shrinks them to the min size if space is scarce. The row height is overridden to follow a style guide, nevertheless, the individual component heights honor the preferred height.

I ensure the following constraint: the min <= actual size <= max. In detail I assume two things that are valid for the MS and Aqua style guides as well as for all l&fs I'm aware of - except the UIC l&f: 1) the style guide height is in the interval [min, max] and 2) only components that have an infinite maximum width (like a text field, list or table) are allowed to fill a growing column horizontally. The first assumption is valid, just because the style guides have been reasonably defined. And in the past decade I've never seen a component that restricted its maximum size _and_ was asked to grow beyond that upper bound.

zander
Offline
Joined: 2003-06-13

> > > If a component's sizes don't satisfy
> min<=pref<=max,
> > > then I think a layout manager can do anything it
> > > likes. [...]
> >
> > Where in the API does it say so? [...]
>
> See the docs for Component.getMinimumSize(). It
> assumes a natural language understanding of what is
> 'minimum', 'size' and how to compare these sizes (how
> the semi-lattice for the <= relation is defined).
>
> A minimum value is <= all other values in the related
> space; the maximum value is >= all other values in
> this space; and so it follows that min <= pref <=
> max.

You make the classic mistake of mixing up speaker positions.
If the space of person A is restricted by B the definition is that A can not move outside of that space.
It is not that B can't ask A to leave that space.
According to the same method it would be illegal for me to ask a JSlider to be set to 100 when its model allows a maximum of 80.

Besides; Sun has rejected a bugreport based on the same question to me; where is it written in the API, which I could naturally not answer.

This is not documented and in my software the layout manager honours these sizes.

karsten
Offline
Joined: 2003-06-11

Thomas, I give up. If we can't agree on what a minimum is, we likely can't discuss productively.

Are you saying that in a partially ordered set there are elements that can be smaller than the minimum?

I prefer to follow Richard Dedekind's definitions that he worked out back in the 19th century. And I don't agree that I'm making a classical mistake here.

zander
Offline
Joined: 2003-06-13

> > Thomas wrote: You keep saying that placing good defaults
> > in the widgets is not a perfect solution, am I correct
> > in concluding that this means (to you) that this
> > approuch is a waste of time to begin with?
>
> No. As said before, I tried to provide good default
> sizes for the JGoodies l&fs too. I'm just saying that
> this is a poor fallback for a small portion of widget
> types.

Ah, thats good :)

It is my believe that honoring these sizes [b]by default[/b] is an absolute must for a good Layout Manager. If a wiget requests a maximum size of 25 pixels height; the Layout Manager will not disobay that.

Again; that is by default; the designer is very well able to specify different policies and min/max sizes.

I was trying to get your opinion on that.

mthornton
Offline
Joined: 2003-06-10

If a component's sizes don't satisfy min<=pref<=max, then I think a layout manager can do anything it likes. Preferably applying a large boot to the component author!

zander
Offline
Joined: 2003-06-13

> If a component's sizes don't satisfy min<=pref<=max,
> then I think a layout manager can do anything it
> likes. Preferably applying a large boot to the
> component author!

Where in the API does it say so? Or is that your personal opinion?

mthornton
Offline
Joined: 2003-06-10

> Where in the API does it say so? Or is that your
> personal opinion?

Can we agree that min<=max? In my personal opinion it is reasonable to expect that the preferred size will lie within this range. Anything else would surprise many developers.

kleopatra
Offline
Joined: 2003-06-11

> > Hmm, moving in circles, Thomas: the essence of
> what
> > you keep saying (at least as I understand you) is
> > that there _is_ such a beast as a context-free
> > minimum size for every component. And now you seem
> to
>
> I think the minimum size is often well defined ---
> the smallest dimensions possible without clipping the
> content.

I don't disagree - and don't really care about minimum sizes. Just mentioned it because Thomas got so upset about layoutManagers not respecting min sizes :-)

> However this wouldn't work for components
> able/permitted to scale their content (or select from
> a range of image sizes). Also the minimum size is
> usually not what we want (except in extremis).
> Preferred size on the other hand is a matter of style
> and usually context dependent.

Full ack. And that's where FormLayout jumps in and does a good job, at least it's the first manager that produces predictable results quite easily.

Greetings
Jeanette

zander
Offline
Joined: 2003-06-13

> > > Let's make it more concrete. JButton is used to
> > > implement at least six different types of MS style
> > > guide buttons (..) So (..) what is your default for
> > a JButton's minimum and
> > > preferred size? 50x20 Pixel?
> >
> > That could be, I'd like to hear from you what this
> > size means to the finished GUI.
> >
>
> Hmm, moving in circles.
I got that feeling as well, and I keep explaining that the minimum / maximum / preferred size can be ignored by the layout manager, if the user says it should be. However this does not mean that that those values are irrelevant since for many widgets they will be used most of the time.

> Thomas: the essence of what
> you keep saying (at least as I understand you) is
> that there _is_ such a beast as a context-free
> minimum size for every component.

True (at last someone who understands me! ); every widget should have a visually pleasing minimum size, and the layout manager should honor this.

The idea here is that not only GUI experts want to be able to create a nice looking UI. Someone that just puts widgets on screen should also get a visually pleasing GUI.
Next to that; the defaults happen to be good enough for most widgets. Exceptions are limited to things like a widget with changing content or a widget that is suppost to follow style-guide sizing.

I did get that far, and most widgets look good without tweaking.

> And now you seem to
> need the context (in the finished GUI)... So again:
> what does your "fixed" JButton report as minimum
> size? How does it cope with the different
> size-requirements in the different usage context as
> outlined by Karsten? How does your button know which
> of the different minimum sizes to report?

That is the difference in approuch that I seem to be very bad in explaining; for something like a button that has to be style guide complient, the minimum size is probably ignored (or at most used in a Math.max()). The information that a button is a Toolbar button or different lies in the LayoutManager.
For a TextField and many other widgets this kind of meta information is simply not needed and can be taken from the widgets itself. As long as those widgets are telling the truth (based on font sizes etc) these will be correct.

> > You keep saying that placing good defaults in the
> > widgets is not a perfect solution, am I correct in
> > concluding that this means (to you) that this
> > approuch is a waste of time to begin with?
>
> Not sure what Karsten thinks - but my answer is a
> clear: Yes, twiddling too much in fine-tuning default
> sizes is very near to a waste of time. I agree with
> you that the reported values should be as good as the
> comp can manage - but only _without_ knowledge about
> context. Maybe that Swing widgets do have a
> shortcoming here, then it should be fixed.
Don't see how.

> But IMO
> they should _not_ report default values dependent on
> context

I agree.

kleopatra
Offline
Joined: 2003-06-11

> >
> > Hmm, moving in circles.

> I got that feeling as well, and I keep explaining
> that the minimum / maximum / preferred size
> can be ignored by the layout manager, if the
> user says it should be.

okay, but I think that was consent quite from the start (we all aren't exactly beginners in using LayoutManagers :-)

> However this does not mean
> that that those values are irrelevant since for many
> widgets they will be used most of the time.

Let's say their relevance depends on context which is in the responsibility sphere of the manager - being so I would not put too much effort into difficult or even impossible decisions (f.i. as the example of an empty label) in the layer of the component. Let the overruling layer handle it.

>
> > Thomas: the essence of what
> > you keep saying (at least as I understand you) is
> > that there _is_ such a beast as a context-free
> > minimum size for every component.
>
> True (at last someone who understands me! ); every
> widget should have a visually pleasing minimum size,
> and the layout manager should honor this.

okay - then back to the very simple question Karsten asked earlier today: what _is_ the minimum size your JButton reports?

>
> The idea here is that not only GUI experts want to be
> able to create a nice looking UI. Someone that just
> puts widgets on screen should also get a visually
> pleasing GUI.

agreed.

> Next to that; the defaults happen to be good enough
> for most widgets. Exceptions are limited to things
> like a widget with changing content or a widget that
> is suppost to follow style-guide sizing.

okay, then let's try to discuss the exceptions, how exactly they don't behave well and what can be done about it ...

>
> I did get that far, and most widgets look good
> without tweaking.

... you are the expert here, so lead the way :-)

>
> That is the difference in approuch that I seem to be
> very bad in explaining; for something like a button
> that has to be style guide complient, the minimum
> size is probably ignored (or at most used in a
> Math.max()). The information that a button is a
> Toolbar button or different lies in the
> LayoutManager.

hmm, I'm slightly confused: are you saying that a button does not have to provide some "meaningful" XXSize?

> For a TextField and many other widgets this kind of
> meta information is simply not needed and can be
> taken from the widgets itself. As long as those
> widgets are telling the truth (based on font sizes
> etc) these will be correct.

what is the "truth" for an empty textfield (coming back to your example in critizing FormLayout)?

> >
> > Not sure what Karsten thinks - but my answer is a
> > clear: Yes, twiddling too much in fine-tuning
> default
> > sizes is very near to a waste of time. I agree
> with
> > you that the reported values should be as good as
> the
> > comp can manage - but only _without_ knowledge
> about
> > context. Maybe that Swing widgets do have a
> > shortcoming here, then it should be fixed.

> Don't see how.

Sorry I don't understand that: what don't you see? Fixing? If so than discussing the concrete issues to fix here hopefully will draw some attention in the Swing Team (huhu...!!)

Greetings
Jeanette

zander
Offline
Joined: 2003-06-13

> > > Thomas: the essence of what
> > > you keep saying (at least as I understand you) is
> > > that there _is_ such a beast as a context-free
> > > minimum size for every component.
> >
> > True (at last someone who understands me! ); every
> > widget should have a visually pleasing minimum size,
> > and the layout manager should honor this.
>
> okay - then back to the very simple question Karsten
> asked earlier today: what _is_ the minimum size your
> JButton reports?

It is the width of the text (based on set font) and/or the size of the icon plus the size of the margins.
I.e. the minimum size all content visible, and nothing more.

> > Next to that; the defaults happen to be good enough
> > for most widgets. Exceptions are limited to things
> > like a widget with changing content or a widget that
> > is suppost to follow style-guide sizing.
>
> okay, then let's try to discuss the exceptions, how
> exactly they don't behave well and what can be done
> about it ...

This is about widgets that tell their size, but we don't really want that to be their size. This is about a button press filling a list, and the next time a label is set; the GUI jumps due to the new preferred size of that table.

> > That is the difference in approuch that I seem to be
> > very bad in explaining; for something like a button
> > that has to be style guide complient, the minimum
> > size is probably ignored (or at most used in a
> > Math.max()). The information that a button is a
> > Toolbar button or different lies in the
> > LayoutManager.
>
> hmm, I'm slightly confused: are you saying that a
> button does not have to provide some "meaningful"
> XXSize?
Only a button [b]that has to be[/b] style guide complient. Other buttons-sizes will still be used. Since their only difference is how the designer uses them, the button itself always has to provide good sizes.

> > For a TextField and many other widgets this kind of
> > meta information is simply not needed and can be
> > taken from the widgets itself. As long as those
> > widgets are telling the truth (based on font sizes
> > etc) these will be correct.
>
> what is the "truth" for an empty textfield (coming
> back to your example in critizing FormLayout)?

In the example the preferred size is (default Swing) 0 width, since there is no content.
The minimum size of the widget was set to the width of 10 X-es. So the size is visually appealing, even if the designer did not set a specific size to the textfield.
My complaint was that my minimum size was not honored.

> > > context. Maybe that Swing widgets do have a
> > > shortcoming here, then it should be fixed.
>
> > Don't see how.
>
> Sorry I don't understand that: what don't you see?

I don't see how the Swing widgets can get extra information to fix problems with regards to context. I dont see how Swing can be changed to have something like a 'scaling policy' or a 'min width is 12 units' setting.

> Fixing? If so than discussing the concrete issues to
> fix here hopefully will draw some attention in the
> Swing Team (huhu...!!)

I'm confident that this is something we will have to solve without Swing being adjusted.

kleopatra
Offline
Joined: 2003-06-11

>
> In the example the preferred size is (default Swing)
> 0 width, since there is no content.
> The minimum size of the widget was set to the width
> of 10 X-es. So the size is visually appealing, even
> if the designer did not set a specific size to the
> textfield.
> My complaint was that my minimum size was not
> honored.

I view it as a violation of the widget's contract (yeah I know java does not formally support contracting and yeah the docs dont write it out explicitely) to return "reasonable" values for default sizes if it reports a pref < min. That's conflicting information and the LayoutManager has to choose. The decision which one to honor (either pref or min) is arbitrary, so there's nothing to complain about whichever it does.

Good luck anyway.
Jeanette

karsten
Offline
Joined: 2003-06-11

> I view it as a violation of the widget's contract

+1

In FormLayout I assume that the preferred size is >= the minimum size. So all three Forms component sizes (min, default, pref) ensure that the size is >= the minimum size. The same is valid for the maximum size.

karsten
Offline
Joined: 2003-06-11

> Thomas wrote: You keep saying that placing good defaults
> in the widgets is not a perfect solution, am I correct
> in concluding that this means (to you) that this
> approuch is a waste of time to begin with?

No. As said before, I tried to provide good default sizes for the JGoodies l&fs too. I'm just saying that this is a poor fallback for a small portion of widget types.

Thomas, to shed some light into our discussion, could you please provide a table of minimum and preferred sizes for the following widget types: button, check box, radio button, combo, label, list, progress bar, scroll bar, scroll pane, separator, slider, spinner, split pane, tabbed pane, table, tree?

Also, obviously we here don't agree on the appropriate minimum size of a JLabel without content - I'd say 0x0 is fine. I therefore suggest that you don't call this situation a [i]bug[/i], but say that [i]you[/i] find it [i]questionable[/i].

To Mark:
I like your idea of cascading style sheets. In Forms I've choosen to separate the layout defaults out of the components and out of the layout manager; I have put them in a third place: the LayoutStyle. The concrete layout style is provided by a style-guide specific implementation, for example for the Windows style guide.

The current implementation already allows to mix l&fs, layout and layout style. But the layout style values won't change if you switch the l&f at runtime. As said in the LayoutStyle class comment, I will likely provide a new [i]logical[/i] or [i]styled[/i] sizing type in a future release. For example, currently I can use the [code]LayoutStyle.getCurrent().getRelatedComponentsPadX()[/code]. And for example the ButtonBarBuilder uses this value to separate related buttons. But if I change the l&f, the gap won't reflect the change. Also, there's currently no means to specify these logical sizes in the FormLayout layout string representations.

zander
Offline
Joined: 2003-06-13

> Thomas, to shed some light into our discussion, could
> you please provide a table of minimum and preferred
> sizes for the following widget types: button, check
> box, radio button, combo, label, list, progress bar,
> scroll bar, scroll pane, separator, slider, spinner,
> split pane, tabbed pane, table, tree?

You forgot the MaximumSize
Please read the sources; they are better at explaining then text will.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/uic/uicompiler/uic/themes...
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/uic/uicompiler/uic/themes...

etc.

karsten
Offline
Joined: 2003-06-11

Thomas,

I've checked the sources and I'd say that you've introduced a couple of bugs, things that break general Swing constraints: 1) the minimum size can be smaller than the visible content, 2) the minimum size can be larger than the preferred size, 3) the minimum size can be inappropriately large.

A layout manager that honors minimum sizes to layout a compact container may hide portions of your widgets. On the other hand, some widgets report abritrary large minimum widths that cannot be shrinked even if the content is narrow.

1) Non-empty lists and tables can report a minimum height that is smaller than required to display the whole list/table. 2) A text field with two columns has a preferred width smaller than the minimum width, which can lead to bizarre effects. Also, 3) it won't shrink to an appropriate narrow width. If I have a bunch of textfields to enter a MAC address, your fields consume and waste a lot of space. 3) A JList of small icons has a minimum width of 100pixel, which can be much too wide.

From my perspective, your changes make things worse than before. I understand that you are looking for good minimum sizes. In my opinion a minimum width of 100 pixel or 10 characters is arbitrary, no good default and in some cases just inappropriate.

As said before, I ask you to be more careful when calling an issue a bug. You have a quite high visibility and your statements may confuse others.

Also, the UIC buttons report the same sizes as a Metal button and so won't comply with either the Mac Aqua or MS style guides - as is the case with the textfields, combo boxes, radio buttons.

Break. (To turn this into a productive discussion.)

In my opinion the discussion about component sizes confuses readers and may distract readers from the interesting approach of your UIC project. There are only a few mature visual editors out for Java and you have a means to quickly build Java UIs - that's great. I recommend to complain less about the min/pref/max sizes answered by the Sun implementations but focus on your strenghts.

Regarding good defaults for the component minimum and preferred sizes, I suggest to annotate components in the visual editor with context and style guide information - if that's possible. Such an annotation can indicate to either the component, or the layout manager, or a third party like a style guide manager, that a widget is let's say a button in a button bar. Although the button label is a narrow 'OK' you can then take the style guide into account and ensure a minimum size of 75 pixels or so.

My FormLayout is as dumb as your editor output is. Both need extra information about the context and style. In Forms the context annotations are located in the builder layer, where you could mark widgets or widget subsets in your editor to add this information. My style guide information has been factored out into a separate object and I have found that this a good way to go. So if you annotate components in your editor, I won't set a button width to 75 pixel but just say 'button in button bar' and map that to an appropriate value later. For example using a flat map or mapping object like me, or even better in a cascaded means as Mark has suggested before.

Also, it may save a lot of time of we talk on the phone. You can contact me at +49 431 one eight seven six one. Best regards, Karsten.

zander
Offline
Joined: 2003-06-13

> In my opinion the discussion about component sizes
> confuses readers and may distract readers from the
> interesting approach of your UIC project.

Hmm? Your questions led us here. I am only (still) trying to get an answer to a very simple question. If a component (no matter if its wrong) reports a certain size should the layout manager honor that?

This is a question I asked after you said you wanted us to join forces; and for a simple reason; we need to decide where, what information is stored. But we did not seem to get beyond the definition of our basepoints. :(

> Also, it may save a lot of time of we talk on the
> phone. You can contact me at ...

I just might do that :)

kleopatra
Offline
Joined: 2003-06-11

> > Let's make it more concrete. JButton is used to
> > implement at least six different types of MS style
> > guide buttons (..) So (..) what is your default for
> a JButton's minimum and
> > preferred size? 50x20 Pixel?
>
> That could be, I'd like to hear from you what this
> size means to the finished GUI.
>

Hmm, moving in circles, Thomas: the essence of what you keep saying (at least as I understand you) is that there _is_ such a beast as a context-free minimum size for every component. And now you seem to need the context (in the finished GUI)... So again: what does your "fixed" JButton report as minimum size? How does it cope with the different size-requirements in the different usage context as outlined by Karsten? How does your button know which of the different minimum sizes to report?

>
> You keep saying that placing good defaults in the
> widgets is not a perfect solution, am I correct in
> concluding that this means (to you) that this
> approuch is a waste of time to begin with?

Not sure what Karsten thinks - but my answer is a clear: Yes, twiddling too much in fine-tuning default sizes is very near to a waste of time. I agree with you that the reported values should be as good as the comp can manage - but only _without_ knowledge about context. Maybe that Swing widgets do have a shortcoming here, then it should be fixed. But IMO they should _not_ report default values dependent on context - if they do so they are nosing into some other class' domain. Again: context (style guides, manager... ) is the major responsible for sizing/alignment, so it needs to be able to handle ill-behaved comps as well as well-behaved ones.

Greetings
Jeanette

mthornton
Offline
Joined: 2003-06-10

> Hmm, moving in circles, Thomas: the essence of what
> you keep saying (at least as I understand you) is
> that there _is_ such a beast as a context-free
> minimum size for every component. And now you seem to

I think the minimum size is often well defined --- the smallest dimensions possible without clipping the content. However this wouldn't work for components able/permitted to scale their content (or select from a range of image sizes). Also the minimum size is usually not what we want (except in extremis). Preferred size on the other hand is a matter of style and usually context dependent.

zander
Offline
Joined: 2003-06-13

> > Hmm, moving in circles, Thomas: the essence of
> what
> > you keep saying (at least as I understand you) is
> > that there _is_ such a beast as a context-free
> > minimum size for every component. And now you seem
> to
>
> I think the minimum size is often well defined ---
> the smallest dimensions possible without clipping the
> content.

True; but Swing has bugs like that a JLabel without any text is 0x0 pixels. As soon as you put some text in there the layout 'jumps'. This kind of fixes are the ones I am referring to.

kleopatra
Offline
Joined: 2003-06-11

>
> True; but Swing has bugs like that a JLabel without
> any text is 0x0 pixels. As soon as you put some text
> in there the layout 'jumps'. This kind of fixes are
> the ones I am referring to.

the "jumping" depends on the LayoutManager used :-) That's why FormLayout supports row/columngroups and boundedSizes (on the layer of the manager)

But on the whole we are making progress in defining our problem(s) as we perceive them - I alway prefer a concrete discussion: If you think a label without content is wrong in reporting its pref size as (0, 0) - what would be the correct value (context-free)? If there's nothing in it it does not need space...

Greetings
Jeanette

mthornton
Offline
Joined: 2003-06-10

>
> But on the whole we are making progress in defining
> our problem(s) as we perceive them - I alway prefer a
> concrete discussion: If you think a label without
> content is wrong in reporting its pref size as (0, 0)
> - what would be the correct value (context-free)? If
> there's nothing in it it does not need space...
>

Possibly (0, lineHeight+margins)
assuming left/right text direction (as opposed to vertical). But this assumes that its later content will be text (and not an image). Given that labels can be used for either text or images (or both) it is more difficult to specify a size for the empty case. You have to know the intended future use.

kleopatra
Offline
Joined: 2003-06-11

> >
> > But on the whole we are making progress in
> defining
> > our problem(s) as we perceive them - I alway prefer
> a
> > concrete discussion: If you think a label without
> > content is wrong in reporting its pref size as (0,
> 0)
> > - what would be the correct value (context-free)?
> If
> > there's nothing in it it does not need space...
> >
>
> Possibly (0, lineHeight+margins)
> assuming left/right text direction (as opposed to
> vertical). But this assumes that its later content
> will be text (and not an image). Given that labels
> can be used for either text or images (or both) it is
> more difficult to specify a size for the empty case.
> You have to know the intended future use.

Too many assumes and fortune-telling for my liking: The label simply _cannot_ make any educated guess about it's future size requirements.

As the outcome would be more or less arbitrary I would opt to not even try and let a layoutManager handle it - the label usually does not come in isolation but somehow adjacent/grouped with other components so a reasonably good manager can decide based on that environment.

Greetings
Jeanette

mthornton
Offline
Joined: 2003-06-10

>
> Too many assumes and fortune-telling for my liking:
> The label simply _cannot_ make any educated guess
> about it's future size requirements.

Indeed. The current (0,0) value is the best that can be done without context. Some might argue that a read only JTextField should be used for non static content, in which case the empty JLabel case wouldn't arise (assume some other solution for the image case).

Mark

zander
Offline
Joined: 2003-06-13

> Thomas,
> I've put a significant effort in fine-tuning the
> components sizes of my JGoodies Windows l&f and the
> Plastic l&fs. That's a good first step and it's nice
> to have defaults that are not poor.

If I put a JTextField in a FormLayout using only the default constructors and the widget ends up being 1 pixels wide, I don't call that very good defaults. But I am repeating myself.

kleopatra
Offline
Joined: 2003-06-11

>
> If I put a JTextField in a FormLayout using only the
> default constructors and the widget ends up being 1
> pixels wide, I don't call that very good defaults.
> But I am repeating myself.

You have been mentioning that JTextField example a couple of times now... so I just checked what actually happens (I don't believe in speculations and rarely trust any quoted but invisible example code :-). Speaking of formLayout:

1) a JTextField created with the parameterless constructor comes up with some very minimal width, let's call it one-pixel - did not measure and don't care.

2) if I give it a somewhat more sensible minimum size (by subclassing or by setting the min explicitly) it still comes up with that one-pixel.

3) BUT: if I ensure that the textfield never reports a preferred size smaller than the minimum (which JTextfield does not care about) it does come up with that minimum.

So IMO the layoutManager does work correctly - it's the textfield that does not behave. And that's clearly a bug of the textfield: it can easily undertake the effort to report default sizes that are consistently ordered (that is min <= pref <= max) _without_ resorting to context. Fixing these inconsistencies definitely would not fall into the waste-of-time category :-)

Greetings
Jeanette

zander
Offline
Joined: 2003-06-13

> Let's make it more concrete. JButton is used to
> implement at least six different types of MS style
> guide buttons (..) So (..) what is your default for a JButton's minimum and
> preferred size? 50x20 Pixel?

That could be, I'd like to hear from you what this size means to the finished GUI.

> To summarize: components can only answer good
> defaults if you put all features into the components
> that others reach using a combination of layout
> manager + style guide + individual design decisions.

I quote from my earlier post:
> > The next step is to allow the programmer to put the widget in the layouter and at the same time
> > include extra information to let the layouter do styleguide complient design. I already said that
> > this has not been done in NaturalLayout just yet.

What is wrong with this approuch?

You keep saying that placing good defaults in the widgets is not a perfect solution, am I correct in concluding that this means (to you) that this approuch is a waste of time to begin with?

mthornton
Offline
Joined: 2003-06-10

>
> You keep saying that placing good defaults in the
> widgets is not a perfect solution, am I correct in
> concluding that this means (to you) that this
> approuch is a waste of time to begin with?

If I may be permitted to butt in. The problem of context means that such widget based defaults might only be appropriate occasionally (unless you provided separate widgets for each context). In which case why not leave the defaults as they are and solve the problem elsewhere. Equally though there are problems with specifying it in a Layout class --- duplication of effort either between layouts or Layout classes. So perhaps the right answer is some third place.

JButton.dialog {minWidth=12dlu; minHeight=20px}
JButton.toolbar ...

Note that I am only suggesting the concept, not the particular syntax or implementation.

zander
Offline
Joined: 2003-06-13

> > You keep saying that placing good defaults in the
> > widgets is not a perfect solution, am I correct in
> > concluding that this means (to you) that this
> > approuch is a waste of time to begin with?
>
> If I may be permitted to butt in. The problem of
> context means that such widget based defaults might
> only be appropriate occasionally (unless you provided
> separate widgets for each context).

In practice that is not really true. A JLabel does not size according to style guides, only based on content and font sizes. This is true for 90% of the widgets; Buttons are the best example where it is a little harder.

mthornton
Offline
Joined: 2003-06-10

Labels with images do size (at least the size of the image can be context dependent)

zander
Offline
Joined: 2003-06-13

> > If I put a widget in the FormLayout that has a
> minimum size of 100x100
> > and it shows up to be 0 pixels wide, something is
> going wrong.
>
> You are the one and only who has ever reported a
> usability problem with the FormLayout.

I have been told before I am quite a unique person :)

But seriously; creating a GUI with nothing but default values should always be correct, I asked this question before and you told me that I did it wrong. There are 3 responsed to an answer like that; 1) dummy mode; you're te expert 2) walk away 3) disagree from experience and try to convince you what it is that I think can be fixed.

I tend to choose the 3th.

> Regarding the sizing responsibilities: component vs.
> designer vs. layout manager, I'd say that the
> component provided sizes are often irrelevant for
> style guide compliant design: the minimum component
> size can be an extreme value that should not stiffle
> the designer's creativity. The component preferred
> size lacks the content and can often not provide the
> information required for good screen design - just
> because good design takes many different values into
> account: style defaults, contexts, component and
> container sizes.

I'm wondering if you read my story above; to create good design that takes as little time as possible you need to first have good defaults, and having the components tell correct sizing is one of them.
Just assuming they wont is not a solution, its sticking your head in the sand.
I have worked to make the components report correct sizes, I have worked on a Layout Manager that uses those values and thus shows a good-enough gui with little to no work.

The next step is to allow the programmer to put the widget in the layouter and at the same time include extra information to let the layouter do styleguide complient design. I already said that this has not been done in NaturalLayout just yet.

You have done the opposite; you have a layout manager that can do everything, but is very hard to use without intimate knowledge of what you want to do (which you solved by having factories). This is the same design mistake GridBag made.

The story I posted above said that in this plan of steps you skipped the first and I just finished the first. This knowledge is something we can combine (I'd like that) but I hope we can agree on concepts and stop talking about the best layouter here.

So; assuming we will get to allowing styleguide complient layouting later; do you agree on the basis that the intelligence of widget sizes should be in the widgets, and not in the designers head? And I am talking about how to get to a good solution, so assuming the widgets are wrong in my mind means we should first fix the widgets.
In other words; can we agree on concepts?
I need to alter things in the NaturalLayout anyway; so I volenteer to code the solution we come up with (I found the FormLayout soruces on the net which I'll read the before that)

Cheers!

karsten
Offline
Joined: 2003-06-11

Thomas,
I've put a significant effort in fine-tuning the components sizes of my JGoodies Windows l&f and the Plastic l&fs. That's a good first step and it's nice to have defaults that are not poor.

Anyway, from my perspecitve that's far away from being enough and doesn't help much with good design or with style guide compliant design. As said before, the same component type can be used in different contexts which require different sizes. And secondly, the same widgetry can be used with different style guides. Consequently, the components can hardly provide the right sizes - unless you put all required information into the individual components: style guide, context, design issues like scarce space.

Let's make it more concrete. JButton is used to implement at least six different types of MS style guide buttons: small toolbar button with icon/icon+text, large toolbar button with icon/icon+text, form embedded button, command button in button bar. So even with a single style guide, what is your default for a JButton's minimum and preferred size? 50x20 Pixel?

Next example: the Java l&f shall be used to design 1) a MS style guide compliant UI, 2) a UI that follows the Lufthansa corporate screen design style. The Lufthansa style guide specifies the height of command buttons and textfields as 12 dlu, where Microsoft specifies these heights as 14 dlu. What is your default value for a command button and textfield size? If you would answer the Microsoft default values, you would prevent others from getting the smaller Lufthansa values. And even in the Lufthansa style, a designer should be able to layout smaller buttons - if necessary for a special context.

Also, what is a good default size for a JList, JTree or JTable? I'd say that good design just follows a meta design: a style guide for the layout elements and a systematic structure using a system of consistent but flexible grids. All professional print-media designers I'm aware of follow such an approach; see for example the grid systems of Josef M�ller-Brockmann, Ruedi R�egg and Jan Tschichold.

To summarize: components can only answer good defaults if you put all features into the components that others reach using a combination of layout manager + style guide + individual design decisions.

mthornton
Offline
Joined: 2003-06-10

> Next example: the Java l&f shall be used to design 1)
> a MS style guide compliant UI, 2) a UI that follows

Anyone for cascading style sheets?

mthornton
Offline
Joined: 2003-06-10

> Why? First off, the JDK layout managers (except
> SpringLayout) [b]cannot[/b] implement even basic
> layout features: equally sized columns and rows,
> stable multi-panel layout, aligned font-baselines.

Is it possible to get aligned base lines with a SpringLayout? (Assuming different sized fonts on a line of course). I get the feeling that almost anything is possible with the SpringLayout but working out how from the rather spartan documentation is hard.

Mark

zander
Offline
Joined: 2003-06-13

> it seems http://java.sun.com/products/javabeans/beanbuilder/
> much better, there is no additional layer between xml and view.

You wanted a product that can save you time, the bean builder is only a little tool to get a little gui on your screen with little to no custom code options. No way near a long-term timesaver as what I would call 'worth it'. But I am repeating myself.

It seems to me that you have yet to actually try any of these, so why don't you run with each for a couple of days, or even for just the tutorials provided and then say what you feel out of actual experience.

And please read my message above again since it seems you missed the part where I asked you to send an email.

gussev
Offline
Joined: 2003-06-15

>>It seems to me that you have yet to actually try any of these, so why don't
>>you run with each for a couple of days

Yes, I did not try it yet.