The Artima Developer Community
Sponsored Link

Java Community News
JIDE Software Releases Swing Desktop Application Framework

10 replies on 1 page. Most recent reply: Aug 6, 2007 10:04 AM by David Qiao

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 10 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

JIDE Software Releases Swing Desktop Application Framework Posted: Jul 24, 2007 2:21 PM
Reply to this message Reply
Summary
JIDE's new Swing component framework is designed to make building cross-platform desktop Java applications easy. In this interview with Artima, Shane Atkinson, lead developer of the framework, discusses the main challenges of creating well-behaved Swing clients for different platforms.
Advertisement

This week JIDE Software announced the release of its JIDE Desktop Application Framework. JIDE's framework is designed to make cross-platform Swing application development easy. In this interview with Artima, Shane Atkinson, lead developer of the JIDE framework, talks about the challenges developers encounter when building cross-platform Swing UIs, and how the new framework addresses those issues:

Frank Sommers What problems is your framework designed solve?

Shane Atkinson: We wanted a home for most of our components, as well as a general framework for building [Swing] applications. We started this a coupe of years ago. At that time, there were tons of Web frameworks, but nothing really for desktop applications, and JSR 296 [< a href="http://www.artima.com/lejava/articles/swingframework.html">Swing Application Framework] was not present yet either. There were Eclipse and NetBeans—huge architectures that had a lot of overhead and seemed to be very tools-oriented.

We felt that people needed a more generic application framework where they could come in and create a good MVC application. We wanted to solve [desktop] application problems that, I think, were not really solved even before things started shifting from desktop apps to Web apps in mid-1990s.

As a result, our framework is a full-featured desktop application framework, but it's abstract in the sense that it is not tied to any specific class of applications, such as editors or IDEs. If you step away from the tools mentality and get back to just normal desktop development, we wanted to address the bigger problems in developing a desktop app. Our framework can facilitate putting together more complex desktop applications with some nice benefits.

Frank Sommers: What were the biggest desktop application problems you wanted to solve with your framework?

Shane Atkinson: One of the big ones was just believability. When you work with applications on a specific platform, you are used to a certain look-and-feel for the entire application, because most applications follow the look-and-feel guidelines of the native platform.

While Java and Swing handle the component-level look and feel, there is a whole other side of the spec—what we call application look-and-feel or application experience. That deals with how a user interacts with the application: how windows interact with dialogs, or what kind of menus are available. Those are not things that any developer would take on to develop for a single program, [and] for each platform.

Our managed application UI takes the next step in look and feel, and makes a Java application look like a native app on a platform, even beyond component-level look and feel. We went back to the [platform] guidelines and created the managed application framework that allows you to just write your content, and it takes care of managing the rest.

It's similar to how, when writing a Web application, you think about the pages—you are not thinking about writing the browser, you are not handling the window management, you really are just writing the content that goes in the page, and the browser takes care of the rest.

If you take that concept over to the desktop metaphor, you can let our framework handle all the windowing details, and you can just focus on the content that sits in the window, a ContentPane, or something like that. The managed UI provides all the menuing, windowing, it has dialog facilities, there are standard icons and toolbars that are native. That's all put together by the framework, and is all pre-wired to work well together.

Frank Sommers: What do you consider to be the biggest challenge in Swing development that take developers by surprise?

Shane Atkinson: Part of the Swing battle is managing windows. That's somewhat trivial with a single-frame app, but as soon as you step into multiple documents, things get really hairy, really fast. Few people do that well across platforms. There are big differences in the platforms, and Swing doesn't help manage those differences.

Take JFileChooser, for instance. Most people would think that's all you need to allow the user to select a file. But we identified at least 19 file conditions that a robust application would have to handle, such as "file replaced," or "modified externally," or a document may already be open in your environment—how do you handle that? You are not going to get consistent behavior even by using the platform's native component, because those components offer different features from platform to platform.

What we recommend, instead, is that you focus on your value-added feature set for the application, and for each platform our framework will handle those sorts of differences and create a consistent user experience. Even things like menus will re-arrange and re-organize to appear as close to the platform as possible.

Frank Sommers: How does your application framework relate to JSR 296, Swing Application Framework?

Shane Atkinson: There is some overlap: we both have resource handling facilities, we both have the idea of an application, we both have lifecycle features. We were well along development when JSR 296 came about and became visible. We tried to accommodate the work of the JSR 296 expert group at this point with a wrapper API. It basically delegates JSR 296 API calls to our API, and it works fairly well. As the JSR 296 API matures, we will make sure that our application framework stays compatible.


Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Jul 25, 2007 6:43 AM
Reply to this message Reply
It's great if your application does the things the framework does, but I don't see how it is generally suitable for all kinds of applications.

Personally I use JGoodies to give my Java apps native look & feel. It does not do everything this framework does, but I do not think it's necessary.

Shane Atkinson

Posts: 1
Nickname: satkinson
Registered: Jul, 2007

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Jul 26, 2007 7:12 AM
Reply to this message Reply
> It's great if your application does the things the
> framework does, but I don't see how it is generally
> suitable for all kinds of applications.

Simple swing applications are just that; simple. But even moderately sized cross-platform GUI applications remain a significant challenge. JDAF provides a clean MVC architecture and OS-guidelines driven application behavior. And you get this for free just by using the framework (little programming).

>
> Personally I use JGoodies to give my Java apps native look
> & feel. It does not do everything this framework does, but
> I do not think it's necessary.

You may be confusing topics/features. If you are developing cross-platform applications you should care about OS-guidelines that concern how your application is experienced on different platforms.

The prevailing problem that JDAF solves is that a normal Swing app is not going to "behave" like a native app, but just present a "facade" of one. In fact, most java apps "behave" (and often look) the same on all platforms, homogenous. We hold that this is not a truely cross-platform application, but simply an application that runs on multiple-platforms.

Let me give an example: If you are a Windows developer, you will put an "Exit" command in the File menu and think you're good to go. This is the classic blunder. On Mac OS X and Linux that command is recognized as "Quit", and on OS X it is not even in the File menu, but in the Apple menu, which requires special coding techniques to get it there.

We have a long list of such differences, and in fact, there are enough of these for just basic UI management that if the average java app where to be graded on its cross-platform integration and believablity, it would miserably fail from the perspective of the native user. (All except the user on the same platfrom as the developer who may share a similar experience.)

Let me give two shining examples; Eclipse and NetBeans. Because we are developers we don't care that these apps look the same on all platforms. For us, that consistancy is a feature (which JDAF supports, BTW). But instead of being a special case, this is the norm for java apps. If I where to create a generic (non-tools oriented) app using these platforms (or JGoodies), the produced homogeny would surely disappoint the native user. In some cases embarrassingly so. It will look out of place, unintuative, wrong, and like an alien landed on their desktop, unless you pay attention to the guidelines of the OS. This is frankly is a huge undertaking which may be why noone does it. But this is one of the reasons we created JDAF; to improve Java apps.

JGoodies and Swing provide native Swing Look and Feel (appearence), not native application experience (structure + behavior). Worlds apart. And before JDAF, nothing did.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Jul 26, 2007 2:48 PM
Reply to this message Reply
I appreciate that it is bloody difficult to get a truly cross-platform GUI working 100%. Anybody trying to solve that problem is brave and I suspect inevitably doomed to fall short of perfection, but we're all better off for their efforts never the less.

It would be great if somebody could codify the differences so that products could be rated against some ultimate Platonic ideal. For example, the JDAF demo fails to fully implement some particular nuances of Windows. To wit: click to open the File menu, then leaving it open single-click on the window's title bar. In a "real" Windows app, the click causes the File menu to go away. That doesn't happen with any Swing app I've ever come across.

I'm not a bigot any which way but I'll note that SWT apparently gets that (one of a zillion things, so this isn't saying much) right - at least my local installation of Eclipse does.

At any rate, if I had to do something supposedly cross-platform with Swing, I bet I'd be very happy that JDAF exists at all.

David Qiao

Posts: 6
Nickname: jidesoft
Registered: Oct, 2004

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Jul 26, 2007 3:27 PM
Reply to this message Reply
I don't know for sure which configuration contributes to it - I tried webstart demo at http://www.jidesoft.com/products/1.4/jide_demo.jnlp using JDK 6 on Windows XP with XP style on. To my surprise, it works. I mean the opened file menu hides automatically when I clicks on the title bar.

Thanks,

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Jul 26, 2007 4:37 PM
Reply to this message Reply
Hmm, interesting! What I did was download the demo and run it locally on WinXP SP2 with Java 1.5.something_or_other.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Jul 26, 2007 4:51 PM
Reply to this message Reply
Oh boy, what is really creepy is that with the locally-running demo, if I mess around with the look-and-feel buttons (by just clicking on the ones in the toolbar rather than using the menu) I can have the same look and feel end up drawing differently! In particular, ("Vsnet" vs. "Windows XP") vs. Office2003 causes some differences in layout; things shift up and down but only sometimes. Weird, whacky stuff. [Software, and GUIs in particular, and cross-platform GUIs especially, is hard.]

David Qiao

Posts: 6
Nickname: jidesoft
Registered: Oct, 2004

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Jul 27, 2007 10:39 AM
Reply to this message Reply
It's probably JDK6 that fixed the bug you mentioned. It's good - at least it shows Sun cares about this minor detail.

The shif-up and down thing is fixed. You can try the webstart (or download the zip) again.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Jul 27, 2007 5:06 PM
Reply to this message Reply
As an aside, I take issue with calling it a "minor detail." I really think only people who don't appreciate the whole point of usability at all could describe things that way. Well, OK, if it were the only such bug then maybe it could be so-called, but the usual situation is that there are many such bugs and they end up making my life hell in aggregate.

But really I'm just a neo-luddite, so don't listen to me. :-P

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Aug 2, 2007 3:31 AM
Reply to this message Reply
> > It's great if your application does the things the
> > framework does, but I don't see how it is generally
> > suitable for all kinds of applications.
>
> Simple swing applications are just that; simple. But even
> moderately sized cross-platform GUI applications remain a
> significant challenge. JDAF provides a clean MVC
> architecture and OS-guidelines driven application
> behavior. And you get this for free just by using the
> framework (little programming).
>
> >
> > Personally I use JGoodies to give my Java apps native
> look
> > & feel. It does not do everything this framework does,
> but
> > I do not think it's necessary.
>
> You may be confusing topics/features. If you are
> developing cross-platform applications you should care
> about OS-guidelines that concern how your application is
> experienced on different platforms.
>
> The prevailing problem that JDAF solves is that a normal
> Swing app is not going to "behave" like a native app, but
> just present a "facade" of one. In fact, most java apps
> "behave" (and often look) the same on all platforms,
> homogenous. We hold that this is not a truely
> cross-platform application, but simply an application that
> runs on multiple-platforms.
>
> Let me give an example: If you are a Windows developer,
> you will put an "Exit" command in the File menu and think
> you're good to go. This is the classic blunder. On Mac OS
> X and Linux that command is recognized as "Quit", and on
> OS X it is not even in the File menu, but in the Apple
> menu, which requires special coding techniques to get it
> there.
>
> We have a long list of such differences, and in fact,
> there are enough of these for just basic UI management
> that if the average java app where to be graded on its
> cross-platform integration and believablity, it would
> miserably fail from the perspective of the native user.
> (All except the user on the same platfrom as the developer
> who may share a similar experience.)
>
> Let me give two shining examples; Eclipse and NetBeans.
> Because we are developers we don't care that these apps
> look the same on all platforms. For us, that consistancy
> is a feature (which JDAF supports, BTW). But instead of
> being a special case, this is the norm for java apps. If I
> where to create a generic (non-tools oriented) app using
> these platforms (or JGoodies), the produced homogeny would
> surely disappoint the native user. In some cases
> embarrassingly so. It will look out of place,
> , unintuative, wrong, and like an alien landed on their
> desktop, unless you pay attention to the guidelines of the
> OS. This is frankly is a huge undertaking which may be why
> noone does it. But this is one of the reasons we created
> JDAF; to improve Java apps.
>
> JGoodies and Swing provide native Swing Look and Feel
> (appearence), not native application experience (structure
> + behavior). Worlds apart. And before JDAF, nothing did.

But why should my app behave differently depending on the platform it runs?

First of all, most computer users do not use a single operating system. We all use Windows at some point, even if we have a Mac or Linux system at home. So I do not think it is of great importance to have 'quit' instead of 'exit', for example.

Secondly, nowadays people expect applications to behave the same across all platforms, thanks to the web.

Thirdly, it's only the Macintosh platform that is different enough to make people think JDAF is necessary. Although in our company we cater for Mac users, our Java apps only go so far as to have a native look & feel. None of our users have complained so far.

So my thesis is that JDAV is good to have, but not that important in the grand scheme of things.

David Qiao

Posts: 6
Nickname: jidesoft
Registered: Oct, 2004

Re: JIDE Software Releases Swing Desktop Application Framework Posted: Aug 6, 2007 10:04 AM
Reply to this message Reply
Hi Achilleas,

People always have different opinions about if a Java application should behave natively or behave the same on different platform. You can always speak English in different countries as most people nowadays can understand English. But if you could speak their native language, it is certainly better. Would you agree? That's why we think an Java application should behave natively on different platforms.

Please also keep in mind OS-guidlines is just one of the many features provided by JDAF.

Thanks,

-David

Flat View: This topic has 10 replies on 1 page
Topic: Natural-Language Processing with Java Previous Topic   Next Topic Topic: BEA Releases AquaLogic BPM 6.0

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use