The Source for Java Technology Collaboration
User: Password:



Romain Guy

Romain Guy's Blog

Synth Week, Components Orientation Support

Posted by gfx on September 23, 2005 at 12:32 AM | Comments (7)

Many Swing components can be oriented according to your needs. Scrollbars are among the most common oriented components. Despite some support in Synth for oriented components, it is far from being exhaustive in Tiger. While some left aside components can be easily forgotten, for instance the window of a floatable toolbar being dragged, Synth lacked support for important oriented components, like scrollbars. Scrollbars are a great example because many users ran into the problem of skinning both horizontal and vertical scrollbars with a different picture. The following snippet shows how to style scrollbars' track:

<style id="scrollbarTrackStyle">
    <state>
        <imagePainter method="scrollBarTrackBackground"
        path="images/scrollBar-track.png" sourceInsets="0 7 0 7" />
    </state>
</style>
<bind style="scrollbarTrackStyle" type="REGION" key="ScrollBarTrack" /> 

This code works fine when you use a picture which can be stretched horizontally or vertically. Unfortunately, most modern look and feels require the use of gradients to show good looking scrollbars and this is where the problem arise. Take a look at the following screenshot and compare the two scrollbars:


Fig. 1. Ouch, scrollbars look... weird.

The result is not really surprising since we use only one picture for both scrollbars. This picture is a gradient meant to be stretched on the vertical axis, thus the glitch in the horizontal scrollbar. By taking a closer look at Synth documentation we discover a special attribute for painters, called "direction". On the screenshot, you can notice the four arrow buttons (two for each scrollbar) are rendered perfectly, thanks to the direction attribute:

<style id="scrollBarArrowStyle">
    <state>
        <imagePainter method="arrowButtonForeground"
         path="images/scrollBar-up.png" center="true" direction="north" />
        <imagePainter method="arrowButtonForeground"
         path="images/scrollBar-down.png" center="true" direction="south" />
        <imagePainter method="arrowButtonForeground"
         path="images/scrollBar-left.png" center="true" direction="west" />
        <imagePainter method="arrowButtonForeground"
         path="images/scrollBar-right.png" center="true" direction="east" />
    </state>
</style>
<bind style="scrollBarArrowStyle" type="REGION" key="ArrowButton" /> 

It would be logical to do the same for the track but you can't because Synth doesn't support direction for scrollbars tracks. And for many other components and methods for that matter. Filed as bug #5033822, this issue is fixed in Mustang b53. Instead of fixing scrollbars only, we took a look at all Swing components and added orientation support wherever we could. This means you can now skin oriented tabbed panes (and their sub-regions), toolbars, etc. The following snippet addresses the issue for our scrollbars:

<style id="scrollbarTrackStyle">
    <state>
        <imagePainter method="scrollBarTrackBackground"
         path="images/scrollBar-track-horizontal.png"
         direction="horizontal" sourceInsets="0 7 0 7" />
        <imagePainter method="scrollBarTrackBackground"
         path="images/scrollBar-track-vertical.png"
         direction="vertical" sourceInsets="7 0 7 0" />
    </state> 
</style>
<bind style="scrollbarTrackStyle" type="REGION" key="ScrollBarTrack" /> 

Synth can now render the scrollbars properly, as in the following screenshot:


Fig. 2. Thanks to Mustang, scrollbars (and other components) look great.

Adding extensive oriented components support in Synth required a lot of changes in SynthPainter. Therefore, some methods might have been forgotten. In such a case, just send me an email and I'll add the missing method as soon as possible.


Bookmark blog post: del.icio.us del.icio.us Digg Digg DZone DZone Furl Furl Reddit Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment

  • I enjoy very much reading Synth related stuff. Thank you for your effort.

    I am not a Synth user yet and I have the impression that Synth is getting more mature every day. However I am wondering: how many Synth glitches remains to be fixed before someone can someone can work on a Synth project without finding some impossible-to-do-thing?

    Posted by: urddd on September 23, 2005 at 08:33 PM

  • As of today I count two or three opened bugs in our database (I'm not talking about RFE). Remaining glitches are not as important as the ones we fixed in Mustang and you can definitely achieve a project with Synth today. Look at Synthetica, a GPL/Commercial Synth look and feel, that works with Tiger. Its author fixed the same bugs as we did, only in a more limited way (since he cannot hack the JDK itself it makes sense). Anyway, this project is an excellent proof of what you can achieve with Synth. You should take a look ;)

    Posted by: gfx on September 24, 2005 at 01:10 AM

  • A common refrain in your blogs is "Synth complexities are because it basically mirrors Swing underneath, and that's the way (this feature in) Swing is". I recognize this, but is this link absolutely necessary? Can not Synth present a unified, simpler (emphasis on simpler) design while hiding the complexities of Swing below? I know this is an issue more for Synth-development tool writers, but this is the 3rd iteration of Synth, no need to just make it work.

    Posted by: sumitkishore on September 26, 2005 at 10:36 AM

  • It's the 2nd iteration of Synth and we're fixing it according to developers feedback. I wish Synth was simpler but we must make it work first. Besides, visual editors are required and they would address the complexity issue if writtent properly.

    Posted by: gfx on September 26, 2005 at 02:08 PM

  • As a product, 2nd. Because Synth was used in 1.4 for the XP and Linux L&Fs, I'm counting this as the 3rd iteration.

    Would it not be too late by the time you make it fully work to redesign?

    Posted by: sumitkishore on September 26, 2005 at 04:22 PM

  • Following this article I found these problem:

    1. Does this example presume mustang? I'm using java 1.5.0_06

    2. The above example is missing sourceInsets for scrollBarArrowStyle without them I get a missing sourceInsets exception.

    3. The above example does not discuss the settings for ScrollBar

    4. I find that I can control the ScrollBar border and background but not the ScrollBarTrack.

    Posted by: jonathanjohnson on May 18, 2006 at 01:18 PM

  • jonathan: 1. Mustang is required indeed. 2. This is because you don't run Mustang. 3. No setting of ScrollBar is required to style a scroll bar. 4. What do you mean exactly?

    Posted by: gfx on May 20, 2006 at 08:38 PM





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds