The Source for Java Technology Collaboration
User: Password:



Romain Guy's Blog

August 2005 Archives


Kickin', rockin', jammin' FX for Swing

Posted by gfx on August 25, 2005 at 04:42 PM | Permalink | Comments (11)

Special Effects?

SwingX, one of the SwingLabs projects, offers a very interesting set of components sitting on top of Swing. Just before JavaOne, Richard Bair and I came up with a new Swing border you can use to cast shadows around your components. Creating this simple graphical effect gave us a lot of weird ideas and we decided it would be great to have a separate incubator dedicated to that kind of special effects.

Enter FX, a new SwingX module you can check out today in the incubator. If you have a java.net login, you can follow the instructions to get the source code from the CVS. You'll find the FX module in the directory src/fx/. Don't forget to edit the file build.properties to be able to build and generate the documentation with Ant.


FX Components

FX aims to become a playground for developer to try out new graphical effects for Swing user interfaces. To start this new project we picked a few things I did for previous demos, cleaned them and, best of all, documented them. As of today, FX offers the following components:

  • CheckboardPanel: A panel with a checkboard pattern in the background. You can see this kind of panel in photo editing applications like Photoshop or The GIMP. This panel is useful to debug transparency issues or drop shadows.
  • DropShadowPanel: A panel which cast a drop shadow for all its children. If you want to add nice shadow borders to your UI, just slam your components in this panel and forget about custom painting code or special borders.
  • StackLayout: This layout manager can be used to stack up components, as you would do with the layers stack of your favorite photo editing application. This manager avoid to put containers into other containers when you want to create complicated drawings and keep elements separated.
  • ShadowFactory: This utility class generates a shadow from a specified picture. The drop shadow panel uses this class to cast its children shadows.
While those components are not very fancy themselves, they help you create fancier UI. For instance, I used the stack layout at JavaOne to create the following login screen:


Here is a detailled view showing how the stack layout is used to build this UI:


FX Demo (run it)

But enough about the past, what can we build today with FX? The CVS repository contains a demo called DropShadowDemo showing how to use all the available components to produce the following UI:


You can also run this demo right now.

In this demo, a stack layout contains a checkboard panel and a drop shadow panel which contains all the Swing widgets. You can change the shadows appearance by using the controls on the right. You can even change the displayed picture. The two buttons at the bottom do not work, they are just here to desmontrate how well this panel works with Swing components.

Despite the complex visual result, building this UI is very easy:

JPanel panel = new JPanel(new StackLayout());

ImageIcon icon = new ImageIcon(getClass().getResource("images/subject.png"));
picture = new JLabel(icon); 

dropShadowPanel = new DropShadowPanel(new BorderLayout());
dropShadowPanel.setDistance(10);
dropShadowPanel.add(picture);

JPanel buttons = new JPanel();
buttons.setOpaque(false);
buttons.add(new JButton("About"));
buttons.add(new JButton("Exit"));
dropShadowPanel.add(buttons, BorderLayout.SOUTH);

JPanel debugPane = buildDebugPane();
debugPane.setOpaque(false);
dropShadowPanel.add(debugPane, BorderLayout.EAST);

panel.add(new CheckboardPanel(), StackLayout.BOTTOM);
panel.add(dropShadowPanel, StackLayout.TOP);

If you ignore the clutter and concentrate on the FX API, you'll see you need one line to create a stacked panel, one line to create a drop shadow panel and one line to create the checkboard panel. Please refer to DropShadowPanel and ShadowFactory javadocs to see how you can tweak the shadows appearance. Here is how, for instance, to change the shadow's angle and color:

dropShadowPanel.setAngle(90);
dropShadowPanel.getShadowFactory().setColor(Color.GREEN);

This is just the beginning and we have a lot of ideas for FX as well as (almost) ready to roll code. Don't be shy and come join us :)



Is an Open Source effort transferable?

Posted by gfx on August 12, 2005 at 02:34 PM | Permalink | Comments (3)

In my previous entry I talked about Wicket, a cool Java web framework (I can't stress that enough it seems :). As I was writing my praises I was almost certain someone would raise the old and annoying subject of duplicate effort. It turns out that the very first post fulfilled my expectations.

In the case of Wicket, the point made by a some readers here was that Wicket's guys would better work on an existing framework like Tapestry instead of "reinventing the wheel".

First, creating a new and similar to another Open Source project is not reinventing the wheel. No matter how close two projects can be they'll never be exactly the same and they won't match the same requirements and goals from a user's perspective and from developers point of view. Don't think of wheels, but of tires. There are a lot of different sorts of car tires nowaday because they all suit a particular need. Every winter in France we change the tires on my dad's car to put snow tires. Why don't we complain about that and demand good tires for both steep and snowy roads as well as dry and hot freeways? Because that's not what you really want, you want a set of tires very good at one thing instead of clumsy at many purpose.

And I know what I'm talking about since I spent 5 years working on Jext, a free software source code editor. How sick is that, creating yet another source code editor? The same people who complain about Wicket being YAW (Yet Another Whatever) could tell me that I should have contributed to an existing project instead, like jEdit or vi or emacs. After all why would we need another editor? I did not, for instance, worked as a contributor (even though I did write quite a few plugins) on jEdit because I didn't like the UI and I still don't like it. That's silly but that's the only readon I wrote my own. It turns out that despite jEdit's numerous qualities (it's a wonderful editor, much more powerful and advanced than mine) many people chose Jext because they preferred my way of doing a source code editor. It can be all about details but in the end it is really about choice.

What would the OSS/FS landscape be if every contributor would be so narrow-minded that it would take the easy way and just subtmit some clunky patches to the only one or two existing applications in one particular domain? How would you feel if you couldn't choose your favorite Linux distribution (I go with Mandriva) or your favorite desktop and/or window manager (hmmm Gnooome)? Well, you would complain, whine and stampe your feet in anger until a bold mind would fork the stuff. We all want to have the choice because we're all different: we don't have the same habits, agendas, preferences, etc. To be truly honest I feel dumb to explain that because, eh, we all know that already...

Then OSS/FS efforts and competences are not transferable. Having a guy working on a given project for one month doesn't mean he could dedicate the same amount of time (if any) on another project, even a similar one. People contribute to Open Source and free software because they are thrilled and motivated or because they have a need to fulfill. Thus, they wouldn't do the same with another project. I remember writing a few patches for SpamBayes a bayesian spam filter written in Python. I would never have contributed to any other spam filter because SpamBayes was the one I liked and the one I wanted to dedicate time to. At this time we were seeing new spam filters blossoming all over the web. Would SpamBayes guys have contributed to SpamAssassin instead? I truly doubt so because both weren't exactly the same. Would I have contributed to another spam filter instead? No, never, because I wanted to code in Python, in wanted to implement those particular features and because SpamBayes was the only spam filter which attracted me.

Developers time is not interchangeable and never will... unless threatened by a weapon, a huge check or free sex - a fourth alternative is the Hollywood one, that is a combination of the first three.

I really think it's time we move forward and kill one of the most long-lived and dumbest myth ever. Learn this: duplicate efforts are natural, useful and sane.

There's much more to say on the topic but I'll let you continue this discussion now :)

Get to love web development

Posted by gfx on August 10, 2005 at 09:49 PM | Permalink | Comments (18)

I like rich applications. I love to develop rich applications. I foster rich applications development. And guess what? I find web development boring and damn annoying. Asides from being a student and an intern at Sun, I'm also a journalist from a french computing magazine. I spent the last 5 years learning, discovering and teaching dozens of technologies, and there were a lot web oriented ones among them. Even if I'm perfectly aware of the appeal those technologies can have for companies, I find them boring and overly complicated. I even feel too dumb to use them sometimes.

Last week I wrote an article about Wicket and I spent some time discovering and taming it. And I have to confess this: I love it. First Wicket benefits from a great web sites with nice examples and a good documentation, even if some examples do not work with the latest 1.1 betas. Wicket is a light, easy to use framework. Heck, I don't even want to call it a "framework", let's leave that to other mind boggling beasts. Let's call it a candy bar. Yeah, that's right, Wicket is not a framework, it's a candy bar. And everybody loves candy bars (and if you don't, just pretend you do :).

So, not only did the authors tried to bring us a powerful and easy to use web library, they indeed reached their goal. Can you picture a Java web framework candy bar with no XML configuration file? Well, apart from the necessary web.xml that is. Can you picture a web library with a Swing-alike API? Can you imagine a web library fostering the separation between logic and presentation in a clean way? That's what Wicket is!

Oh and Wicket is easy to install and available under the Apache license. But let's take a look at an actual Wicket application. The name application is not innocent since you do create a WebApplication class. You declare your applications in the web.xml:
<web-app>
  <display-name>Hello World Wicket</display-name>
  <servlet>
    <servlet-name>HelloWorldApplication</servlet-name>
    <servlet-class>wicket.protocol.http.WicketServlet</servlet-class>
    <init-param>
      <param-name>applicationClassName</param-name>
      <param-value>HelloWorldApplication</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>HelloWorldApplication</servlet-name>
    <url-pattern>/helloworld/*</url-pattern>
  </servlet-mapping>

As you can see this is very straightforward, especially if you are accustomed to JSP/J2EE development. Your next step is to implement the application itself:
import wicket.protocol.http.WebApplication;

public class HelloWorldApplication extends WebApplication {
  public HelloWorldApplication() {
    getPages().setHomePage(HelloWorldPage.class);
  }
}

This application is very simple but you can interact with many settings. In this case, we simply set the home page. As for the application, a page is just a regular Java class, in this case extending WebPage. This is were Wicket becomes really interesting, for a page is not only a Java class but also an HTML file. The HTML page will contain the presentation layer and the Java class the (business) logic layer. Here is for instance HelloWorldPage.html:
<html>
  <head>
    <title>Hello World Wicket</title>
  </head>
  <body>
    <span wicket:id="message">Message placeholder</span>
  </body>
</html>

On the contrary to other solutions, Wicket's presentation layer does not contain any logic. No code. Just plain, old XHTML. Or to please Java EE guys with a new acronym, POX. The idea here is to identify the elements your code will interact with by giving them a wicket:id attribute. The beauty of this is you can edit the pages in any weird WYSIWYG without breaking the code! Designers can do their job, programmers can do their job and they don't need to stomp on each other for that. Finally, here is the logic:
import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;

public class HelloWorldPage extends WebPage {
  public HelloWorldPage() {
    add(new Label("message", "Hello World !"));
  }
}

Very easy, isn't it? You just create a new label, mapped to the <span /> element called message, giving it the value Hello World !. You're done, you just need to open http://localhost:8080/helloworld and it works!

This example is really simple but it should give you a good idea of how Wicket works on the lower level. Wicket provides a lot of other features. For instance, it manages components state on the server side and makes it really easy to handle forms. As you can bind POJOs to components as their model, it is very easy to handle users input. The chat, or "shout box", example from Wicket examples is an impressive example of clarity.

I really urge you to go to Wicket official web site to read the various tutorials and introductions. You won't regret it.



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