Scott Violet's Blog

Baseline Layout

A friend speculated that Perl is best suited as a write once language. That is, Perl code tends to be rather cryptic to read and hard to maintain so that you end up writing the code once and praying you never come back to it. Much of the layout code I've seen can be lumped into that category. You write it once and if you ever come back to it you have to pull out your hair trying to figure out the intricacies of the containment hierarchy and layout managers being used. Ugh! All this for a process that is inherently visual and should be done in a tool.

This process has improved some what in recent years. In particular forms layout helps for much cleaner code, and some of the recent GUI builders have been getting better. We've been working closely with the Netbeans folks as well and will have an announcement soon. It's going to be fantastic. Stay tuned!

One area that we have been actively working on in Mustang is the ability to get the baseline for various components. This doesn't help developers laying out components, rather it's meant for those writing layout managers. Aligning components along their baseline makes for more polished apps. For example, if you have a label next to a button you do not want them top aligned or bottom aligned, rather you want them aligned on the baseline of the text.

Aligning components along their baseline also makes for great demos. Look at Apple's Interface Builder, or recent versions of Visual Studio for examples of GUI builders using baseline information to help developers create visually pleasing apps.

Accomplishing baseline layout with Swing has been tough. This is for a number of reasons, but primarily because Swing doesn't offer API to determine where the baseline for a particular component is! Sure, we do have the getAlignmentY method, but that really doesn't do all you need and it was never wired up. I'm happy to report that we're nearly done with the baseline API for Swing. If you want a sneak peek at what the API is looking like head over to the javadesktop, in particular the thread on baseline. Give us your two cents!

Thanks!

Comments

• Thanks a lot. Again. Mustang will rock for desktop applications \o/

  Posted by: gfx on April 25, 2005 at 08:36 AM

• I am looking forward the new form designer in Netbeans. I hope it lives up to expectations *drool*.

  Posted by: jdolphin on April 25, 2005 at 09:19 AM

• Once you learn it, GridBag is by far the most powerfull of the lot.
  The problem is writing all of those GridBagConstraints in code. It's very message. My solution was to use an xml schema and read that into a utility class that can take named sections and give you a constraints object. For instance :

  {component name="forename.label"}
  {grid x="0" y="0" width="1" height="1" /}
  {resize fill="NONE" anchor="EAST" weightx="0.0" weighty="0.0" /}
  {insets top="2" left="2" right="2" bottom="2" /}
  {ipad x="0" y="0" /}
  {/component}

  A quick parse with JDOM and it lets you do :
  gridbag.setConstraints(forenameLabel,gbp.parse(null,"forename.label"));
  Its neatens up the code, and allows you to fiddle with GUI layout without changing the source. I'd like to see something like this built into Swing.
  

  Posted by: luggypm on April 25, 2005 at 01:00 PM

• Luggypm,

  I'm aware of a couple of folks that have XML schemas for GridBagLayout. The concept of using an XML for layout, wiring and component creation is something that keeps coming up. We plan a thorough investigation into such a topic shortly.

  -Scott
  

  Posted by: zixle on April 25, 2005 at 01:35 PM

• Scott, Swing is so close to total domination!
  We need layouts of course.

  Gridbag layout is for newbies, to be avoided on production systems. If one thinks outside of the box for a second and not get defensive.

  JGoodies form builder is power, just take a peak. Majority of GUI tools use it and most production Swing apps so why not follow the crowd.

  hth,
  .V
  (the *ONLY* reason Swing is not dominating ALL langs now is WebStart deployment issues that are 4 years old. For example, wordsmithing the scarry user msg)

  Posted by: netsql on April 25, 2005 at 04:14 PM

• 1. Gridbag rocks!
  2. Gridbag code sucks, but NetBeans makes thinkgs as smooth as possible.
  3. Interface Builder Rocks, for sure, since 1986
  4. IB is Cocoa and Mac only, but the SpingLayout is now available in Java but I NetBeans do not support it... a pitty

  Posted by: sgamel on April 26, 2005 at 04:44 AM

• Samagal, Gribag is hard to debug and maintain, so proejcts where you need complex and repeating builders WILL not get used. It's usefull only simple things taht even NetBeans can layout. Choice is good, and I have it to use jGoodies. The MAIN ossues are Swimg deployment, where we haver hard choices. I do not know how Sun decides weather to work on new features or fix bugs.
  .V

  Posted by: netsql on April 26, 2005 at 06:26 AM

• "Design Java Swing-based user interfaces with Apple's Interface Builder"

  http://www.nib4j.com/
  

  Posted by: mattocks on April 26, 2005 at 06:42 AM

• i believe tablelayout
  ( http://www.clearthought.info/software/TableLayout/ )
  is a much better design than gridbag ever was.

  [a] let's not forget tablelayout, and [b] the fact that jgoodies' forms is a descendant of tablelayout

  Posted by: eitan on April 26, 2005 at 07:44 AM

• Am I the only one using SpringLayout?

  I get by with combinations of SpringLayout, BorderLayout and FlowLayout. I never use GridBag. And for one of my UI, I had to write a custom layout because I couldn't find anything that did exactly what I wanted.

  Does anyone out there write their own classes that implement LayoutManager?

  Posted by: jzacker on April 26, 2005 at 10:15 AM

• Random comments,

  Yep, TableLayout is pretty cool too!

  And jzacker, you are by no means the only one using SpringLayout.

  -Scott
  

  Posted by: zixle on April 26, 2005 at 01:04 PM

• Writing your own layout managers are not that hard. Once you get the basic things right (visible, insets etc.), you can easily write your own layout manager for more advanced layouts. Otherwise I mostly use BorderLayout and panel composition.
  

  Posted by: mayhem on April 26, 2005 at 11:52 PM

• Using the baseline is a very good idea. In addition, I suggest taking account of the visually perceived borderlines of a component.
  e.g. if a round radio button should be left aligned below a square button, a good designer would place the radio button slightly to the left by one pixel. Only then it will be visually perceived as left aligned with the button.
  There are also a couple of other design elements which account for the clipping bounds of a component, but are not visually important for its alignment, such as cast shadows or (on Mac OS X) the glowing focus ring.
  I am implementing such a feature for Quaqua Look and Feel 3.0. I have named it "border margin". I would love to see something similar go into Java 6.0.

  Posted by: wrandelshofer on May 02, 2005 at 01:48 PM

• wrandelshofer,
  Karsten has requested such a feature as well. I looked into such API as part of this work but unfortunately neither windows nor GTK provide such information so that we can't provide it.

  -Scott
  

  Posted by: zixle on May 02, 2005 at 02:46 PM

• Dear Scott,
  Do you mean 'neither the Windows Look and Feel and the GTK Look and Feel' provide it? In this case, couldn't this information be added to the Look and Feel? Maybe this is already out of the timeline for Mustang...

  Maybe I should look at what Karsten (who?) did, and do it in the same way with my own Look and Feel. In case you mean Karsten Lentzsch and JGoodies, it might be hard to do the same thing in Quaqua L&F. I believe that JGoodies needs its own layout managers to achieve this - Quaqua is supposed to 'work out of the box'. :(

  What I have implemented so far works with the layout managers that ship with J2SE. I am basically centering the visually perceived borders inside the clip bounds of the JComponent's. So that if a layout manager lays them out, they will automatically align in the intended manner.
  I had to ensure that the baseline also fits. This issue will be resolved by the baseline layout. :)
  In addition, most of Quaqua's ComponentUI's are non-opaque, so that one could have them overlap to some degree. This is not supported by these layout managers though. Except when using negative margins with GridBagLayout. But I believe this is kind of a hack.
  

  Posted by: wrandelshofer on May 02, 2005 at 10:30 PM

• wrandelshofer,
  Sorry for not being clear. By windows and GTK I meant the native toolkits. That is, the native windows and GTK toolkits don't provide API for determining the visual bounds. As the visual bounds can vary between themes/engines we have no way of knowing what it is and therefor can't provide API like this.
  -Scott

  Posted by: zixle on May 03, 2005 at 05:58 AM

• Scott,
  Mac OS X does provide this info. At least, the Interface Builder tool of Apple knows about the visual bounds of the components. ... And how about Longhorn? Maybe it will provide such a feature as well?
  Anyway, I see where the problem is. With Baseline Layout you are maximizing what you can get out of the native API's onto which you can put your fingers on. Keep up the good work.
  I will contact Karsten Lentsch to see whether it is possible to find a common solution for JGoodies Looks and the Quaqua Look and Feel.
  In fact, there is much more about it than just the visual bounds. There are lots of visual perceived markers in JComponents that could be used to align them better. e.g. how does one vertically align the text of a JLabel below the text of a JRadioButton? I don't know of a Swing Look and Feel or of Layout Manager which could handle this. But features like these would help a lot to create visually appealing user interfaces.
  -Werner

  
  

  Posted by: wrandelshofer on May 03, 2005 at 09:36 AM

• wrandelshofer,
  I agree that Apple clearly has the ability to render this. I could not find any public API for what we need though. I suspect it's not exposed and that IB uses private APIs. I couldn't find anything in Longhorn either.

  -Scott
  

  Posted by: zixle on May 03, 2005 at 03:54 PM

• Scott,
  I couldn't figure out how InterfaceBuilder (IB) does this either. I don't believe that a private API or some hardcoded values are used. That would be an unfortunate design, because it would make it impossible for IB to properly lay out custom built controls.
  Nevertheless, I have a partial solution for the visually perceived borderlines implemented in the Quaqua Look and Feel, by using a translucent 'border margin'. If BaselineLayout would be able to take into account such a border margin (which is just an instance of Insets) provided by the UI of a component, then I had a truly complete solution.
  I am not sure, if you would wan't to implement this into the BaselineLayout for Mustang. This problem is really only an issue for Aqua components. Today, other Look and Feels (e.g. Windows, GTK) mostly avoid designs with cast shadows, rounded components and glowing focus rings. Maybe in the future, if more L&F's use something like this, it will make sense to provide a solution by the Java API.
  -Werner

  Posted by: wrandelshofer on May 03, 2005 at 10:45 PM

• On second thought, it would still be nice to have a BorderlineLayout come along with the BaselineLayout for Mustang or a later release. Even, if the native look and feels can't take fully advantage of it now.
  The BorderlineLayout being capable of laying out components with respect to the following visually perceived bounds: component borderline, text upper case borderline and text lower case borderline. For JLabels, component borderline would include the visually perceived rectangle spanning the icon and the text of the JLabel; Text upper case borderline the rectangle spanning vertically from its baseline to the ascent of an upper case character and horizontally from the first to the last character, Text lower case borderline the rectangle spanning vertically from its baseline to the ascent of a lower case character and horizontally from the first to the last character.
  BorderlineLayout could be kind of a replacement for GridBagLayout in a similar fasion like BaselineLayout is kind of a replacement for FlowLayout or BoxLayout
  Do you see any chances for this idea?
  -Werner

  Posted by: wrandelshofer on May 04, 2005 at 01:43 AM

• wrandelshofer,
  I think it's a bit tricky to exactly define what should happen here. Consider a centered JLabel. What happens if you want to do a borderlinelayout and the label is stretched? I would like to see something like this added, but I'm not quite sure what form it should take nor have I completely thought it threw. Additionally before I add it I need to resolve prefered padding between components (6237199) and possibly add in LayoutManager3.

  -Scott
  

  Posted by: zixle on May 04, 2005 at 04:15 PM

• Scott,
  This wasn't a specification, just an idea in a very early stage.At this time, I would say, that the borderline should always only encompass what one can see. So, if the label is stretched, it should still only encompass the visually perceived borderline, wherever the elements inside the label end up after stretching. Maybe that's not sufficient to achieve all desired layouts - I don't know. This definitely needs a through analysis. Also one needs to determine which borderlines are really needed for the creation of layouts. Maybe the three I have listed are already too much - or not sufficient at all.
  If that is of any help, I can instrument the UI classes of Quaqua L&F with the necessary methods, so that one could design and test a prototype of the BorderlineLayout. First I will have to give a detailed look at BaselineLayout. I think that both layout manager would work well together and thus their API should follow the same design patterns.Once (or if ever) the prototype turns out to work well, I'll contact you again.

  Posted by: wrandelshofer on May 04, 2005 at 08:41 PM

• wrandelshofer,
  Sounds good. Let me know how the prototype goes and we can take it from there.
  -Scott
  

  Posted by: zixle on May 05, 2005 at 05:44 AM

• Dear Scott,
  I have implemented a prototype. I have started a thread about a possible Borderline API instead of a Baseline API in the forum.
  -Werner
  

  Posted by: wrandelshofer on May 07, 2005 at 03:43 AM

• This is all good news.

  P.S: Since the introduction of JGoodies Forms (FormLayout), I've always thought that it would be good if it was a standard part of J2SE. For me, it doesn't matter if it resides in J2SE or not: I always build new GUIs by using it. But by adding it to the J2SE it would be mentioned in Java books and tutorials and it will be used more than ever. And it's such an elegant piece of work that makes creating elegant GUIs having clean codes behind them possible. Can we expect to see JGoodies' FormLayout in Matisse?

  Best Regards,
  Behrang S.

  Posted by: behrangsa on June 10, 2005 at 03:25 PM

• behrangsa,

  Mattise use a layout manager completely different than FormLayout. GroupLayout is tuned toward builders where as FormLayout is mostly tuned toward hand coding, although it can equally be used in a builder. Before we were to add FormLayout (or TableLayout) to core we would have to reconcile it with GridBagLayout. By that I mean GridBagLayout and FormLayout (and TableLayout) are all very similar. It may be better to extend GridBagLayout with the features of FormLayout rather than providing a completely new grid based layout manager. Another option is to build GridBagLayout on top of FormLayout. We'll see.

  Thanks for the feedback!
  -Scott

  Posted by: zixle on June 10, 2005 at 04:25 PM

• > "Layout managers are a necessary evil of cross platform layout and resolution independence in that they allow components to adjust in size and position based on external criteria."

  Wrong! Layout managers are single most important feature of Swing allowing us to create clean UI code, that can be parametrized and easily modified. Using UI tool for creating forms is "worse is better" approach. Wasn't that original Swing creators idea?

  2. where is Swing's resolution independence, if constraint's insets, borders, preffered size are all specified in pixels? Look at Windows dialog units (sadly not used in .NET) for resolution independence.

  
  and thanks for adding baseline allignment support!

  Posted by: joansmithdev on January 10, 2006 at 08:45 PM

• Hi joansmithdev,

  Layout managers are single most important feature of Swing allowing us to create clean UI code

  The majority of comments I've heard around layout are that it helps developers create completely unreadable code for something that is inherently visual. Take a look at any code that uses GridBagLayout, it's damn near impenetrable.

  The sad the core idea of LayoutManagers is crucial, the ability to abstract away the layout in various ways.

  where is Swing's resolution independence

  We're sorely aware that we're late to this party. Rest assured we are working on it. There area a number of options we have to deal with this, and most likely we'll expose some of those options to developers. Any feedback is appreciated!

     -Scott

  Posted by: zixle on January 11, 2006 at 09:55 AM

• 大阪 風俗 東京 風俗 uguisu 表札 大阪風俗情報 東京風俗情報 風俗 大阪 風俗 東京 大阪風俗店 東京風俗店 風俗店 大阪 風俗店 東京 風俗情報 大阪 風俗情報 東京 大阪 風俗店 東京 風俗店 断熱 塗料 姫路 ホームセンター 外構工事

  Posted by: goose2 on August 20, 2007 at 07:16 PM

• 我要搬屋,因為要換地方,所以要搬屋.搬屋真難呀.東西太多,還是放到迷你倉去吧.那裏有便宜的迷你倉呀!哎!迷你倉迷你倉`室內設計
  女傭|菲傭
  外傭Domestic Helper家務助理

  Posted by: teiddy on October 18, 2007 at 12:16 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: huaguoli123 on December 06, 2007 at 05:03 PM

This work is licensed under a Creative Commons License.