One of Substance users has switched from version 3.3 to the 4.* line, and is now missing his favorite Streetlights skin. Indeed, it has been removed about a year ago in version 4.0. This specific skin was never marked as officially supported, and the reason was simple – the old theming layer was not powerful enough to support a skin that mixes dark and bright colors.
It is difficult to design a pleasant skin that combines dark colors for overall controls and bright colors for active controls (selected, rolled over, pressed, armed). It is more difficult to implement such a skin in a programmatic way, and even more so to properly support animations. With usual bright colors you only need to animate the background fill while the foreground color stays the same (usually black). The dark-bright switch requires animating both foreground and background colors. Also, there are many corner cases that reveal themselves only with this specific combination. For example, using the same bright colors for both inner fill and outer border of a selected button results in a very fuzzy appearance. It is much better to use dark colors for painting borders of brightly-filled buttons.
As i have already mentioned, the new version of Substance (currently under development) as much more powerful theming layer. Now it is possible to bring Streelights back to life, this time with much better and consistent visuals. Here is a thumbnail of the test application running under Streetlights (click to see full size):
You’re more than welcome to read the code behind the Streetlights skin. It is available as part of the Extras pack.
Meet David Qiao, the founder of JIDE Software, as the interview series on Swing, RIA and JavaFX that started with Amy Fowler and Mikael Grev continues.
Tell us a little bit about yourself.
My software career started after I got a bachelor degree in computer science from Nanjing University and a master degree on the same field from SUNY at Buffalo. After “wasting” several years doing MFC and .NET stuffs, I finally found what I love to do and can be proud of – founding JIDE Software back in 2003 and working on Java/Swing and UI design. Since then, I am lucky to ride the new wave of Java desktop and drive JIDE to be one of the leading Swing components and services providers.
You’re writing open-source and commercial Swing components primarily oriented at business applications. How do you think Swing fares as compared to competing toolkits, such as MFC, Delphi, GTK, Cocoa, QT and others?
Swing lacks the basic out-of-box components comparing with other toolkits. It is rare to see a GUI toolkit that doesn’t come with a date chooser component, for example. Swing doesn’t have one. Swing also suffered from relatively more bugs and sluggishness, especially when it affects the basic functionality of a user interface. It didn’t come with a decent built-in GUI designer like Visual Studio or Delphi does. Swing would have been more successful by addressing these three issues early on. Even so, Swing still stood out among all the UI toolkits mainly because of its elegant design, cross platform availability, pluggable L&F and being part of core Java. Things are certainly moving forward in recent years on all three issues. More and more companies are choosing Swing as their UI toolkits. I just hope Sun doesn’t mess up again this time.
Other UI toolkits seem to have much larger variety of professional third-party component suites. Amy Fowler attributes this to the rise of web applications, but it didn’t seem to affect the market of Delphi and .NET components. What are your thoughts?
I believe consumer applications are the driving force for .NET components. What platforms are the consumers using? Windows, period. They don’t care about Linux or Mac (at least a few years ago). .NET is good enough for them. Swing is used largely in enterprise applications inside relatively larger companies. Many companies spent their own developer hours to make custom components and use them internally only. They have larger budget and have a longer release cycle so they can afford to make their own components. I bet this kind of thing will not happen in .NET for a consumer application as the release cycle is short and they just want to buy the components and get it done faster. So I believe this is the reason for large 3rd component market in .NET. I would love to see statistics showing the number and type of applications writing in each toolkit to prove if what I said is correct.
What do you think about Sun’s new direction of client Java towards RIA space with JavaFX?
Great. Technologies are merging. Microsoft introduces Silverlight to light up the web. Adobe introduces Flex to flash up the desktop. It is certainly making sense for Sun to introduce JavaFX to enter the consumer application market. It is a new market for Sun so it really has nothing to loose. However entering new market doesn’t mean giving up existing markets. Sun should continue investing in Swing. Swing is popular among enterprise applications and should be kept that way. I doubt large complex enterprise applications will use JavaFX any time soon. It will still primarily Swing’s market, maybe with some help from SceneGraph. Not even Flex.
Are you planning to wrap your components for easier consumption in JavaFX applications?
Absolutely. It gives JIDE a chance to enter the consumer application market, why not?
Can Swing be considered a premier choice for cross-platform UI development today? Would you recommend Swing for building large long-term business applications?
Of course. As I mentioned above, Swing is already used in many large complex enterprise applications. It is a perfect fit.
Would you want to see your products folded into the core JDK distribution, and why?
I would love to see it. Some of the basic features should be included in JDK. I had a talk at this year’s JavaOne where I mentioned the support for non-contiguous cell selection in JTable. Swing JTable is totally wrong when the cell selection is enabled. JIDE fixed this in JideTable. I would love to contribute the code back to Swing, and for free of course. There are many features or bug fixes in JIDE that I would like to contribute back. Why? Those are basic features that should be included in every UI toolkit. It is already a mistake that we had to add those features ourselves.
Is there anything else you would like to add?
We mentioned on our website that “Thousands and thousands of developers’ valuable hours are wasted on building the same component which has been built elsewhere. Why don’t you focus on the most value-added part of your application and let us build those commonly used components for you?” Believe it or not, it is true. Many developers wrote their own general purpose Swing components. Raise your hand if you do! I just want to take this chance to say, please use existing components if you can find one, from JIDE, SwingX, or any other open source or commercial component vendors. It will save your money, save your time and accelerate your application development. A healthy third-party component market is very important for any UI toolkits.
A fighter pilot by day and a professional Swing developer by night. Meet Mikael Grev as the interview series on Swing, RIA and JavaFX that started with Amy Fowler continues.
Tell us a little bit about yourself.
I’m a geek and a fighter pilot. A strange and peculiar combination, I know, but it is true nevertheless. The duality was there from the beginning, playing Ice Hockey six days a week (against Peter Forsberg and Marcus Naslund no less) and coding demos on the Commodore 64/ Amiga the rest of the time.. My day job is in the Swedish Air Force, where I am an instructor on the Gripen fighter aircraft. All other time I run MiG InfoCom AB, a small consulting company. Married to an understanding wife, obviously no children. I would be surprised if your audience was interested in my military carrer, so I’ll leave that be :). When it comes to coding I have created Wing, a flight planning, coordination and evaluation system in use by the Swedish and Danish Air Force. I have also created MiG Calendar (and the site) which is the best selling Java component at the largest online reseller, ComponentSource. MiG Layout is my latest project. It is a FOSS (BSD) Layout Manager for both Swing and SWT that promises to put the fun back in hand coding GUIs… I am also quite proud of MiG Base64. Very geeky but fun for a performance freak like me.
You’re writing open-source and commercial Swing components primarily oriented at business applications. How do you think Swing fares as compared to competing toolkits, such as MFC, Delphi, GTK, Cocoa, QT and others?
In general, pretty well. I find the famous comparison to a instrument panel of a Boeing 747 particularly amusing, and accurate. If you know what you are doing it is extensible to the extreme. As a newbie, however, you can find yourself spending hours doing the simplest of customizations. The other frameworks are generally simpler and less configurable. Either what you want to do is easy or not possible at all. Much of the complexity in Swing comes from the IMO bad architectural choice to extend the AWT base classes for the Swing components and the lack of properties.
Other UI toolkits seem to have much larger variety of professional third-party component suites. Amy Fowler attributes this to the rise of web applications, but it didn’t seem to affect the market of Delphi and .NET components. What are your thoughts?
In Swing it is very easy to write simple components but very hard to write complex ones. Especially those that interact with other components during design-time. The support for having non-trivial properties is a nightmare and I have seen few other components than MiG Calendar that actually bothers with complex property editors. The reason is that the JavaBean spec is still at version 1.01 and has never been revised. There is a lot of trial-and-error when touching the outer parts of the spec since it is written in a very loose and open ended way. The problem with this flexibility is that it is interpreted in different ways by the different component container (IDE) vendors. Flexibility is often good, but here a more pragmatic approach would have been better, in retrospect. Since I have worked a lot with Swing, writing the actual components was not the hardest part, that was to make them work properly in all the IDEs. Especially the code->deploy->test-in-IDE- workflow is painful, time consuming and error prone. Without JFormDesigner I don’t think I would actually have made it.
JSR-273, where I am on the Expert Group, set out to firm up the JavaBean spec and provide for a better interface to components, especially under design-time. Unfortunately Sun was not interested in driving it to finnish. My conclusion is that Sun is not interested in a Swing component market.
In short, complex components are time consuming to create, hard to test in its target environment, and without a good channel to sell it. I also miss a good way to support licensing of the component within the IDE. VisualStudio, for instance, has direct suport for this.
What do you think about Sun’s new direction of client Java towards RIA space with JavaFX?
I have mixed emotions. Another layer? Hiding something under another layer is seldom good, unless you make that layer so darn good that you never have to see the plumbing beneath. If Sun release it prematurely, or force the developer to jump down to the Swing level all the time, it can turn ugly fast. Sun has little goodwill they can ride when it comes to desktop matters, JavaFX better be perfect when released or the complain-a-lots will blog it to death.
It is paramount that all demos coming out of Sun looks absolutely stunning. The need to be at least as good as the Silverlight and Flash/Flex/Air demos, probably even better since they are the under dog. When looking at The new JavaFX site I’m uncertain that the Sun hired designers are up to snuff. At least to me it looks, well… you know… but taste differs.
I would probably have put my money in a non-backwards compatible complete Swing overhaul (called SwingIT!) where real properties, translucency, animation, binding and all that fancy stuff was built in from scratch. On top of that I would have built the tools that the designers could use. I sometimes wonder who JavaFX Script is for? Designers won’t touch it for sure and I don’t feel like I as a Swing developer would gain anything, except maybe for prototyping or small cool effects applets (where Flash is king anyway).
What worries me the most about JavaFX is that they are still using the really, well… quality challenged… Swing layout managers. Primarily not because of the actual layout managers, but because the JavaFX architects don’t seem to understand what the the real problems are. Even now when they have the chance to start with a clean slate, they start new with old stuff that never worked that good. But… Time will tell. Maybe I’m just getting old and don’t want my Swing magic wand to loose its swinging power. :)
Are you planning to wrap your components for easier consumption in JavaFX applications?
To be honest I don’t know. Probably. Since it hasn’t been released I have too little information about the work needed to make a business decision. But if our customers want it, or JavaFX takes off like Sun think it will, I will do it for sure. I have been working a lot with GWT as of late and I actually like it, a lot. One cool, very AJAXy, interactive charting component, coming up!!
Can Swing be considered a premier choice for cross-platform UI development today? Would you recommend Swing for building large long-term business applications?
I get this question a lot and I never know what to answer. Or maybe more accurately, there is no short answer.. If you have good developers that have the time to put themselves properly in the know about Swing it is a good toolkit to use. Even more so if the app really needs to be cross platform. Most of Swing’s old problems are gone now. Performance and appearance have reached the level where they are no longer a problem. Though you can never just throw Swing at a large team of developers and let them have at it. Disaster would follow. A Swing project needs to be properly researched in advance to keep clear of the cavets. For instance, if you start using NetBeans and Matisse, which are both formidable tools in themselves, you have forever locked your team into that IDE when it comes to the GUI, and they are smarter than I am if they can alter the created GUI code by hand.. With proper research and initial study Swing can be recommended.
Would you want to see your products folded into the core JDK distribution, and why?
Yes I would. MiG Layout would help a lot of Java developers create good looking GUIs without them even thinking about it. White space and such are just handled automatically. Having MiG layout in the JDK would make it available to millions of developers compared to maybe 1% of that if it is kept outside as today. Only a fraction of the Java developers actually makes the effort to search the net for alternatives. Some don’t because they expect the best of breed to be included in the JDK and some because of the extra external dependency it would bring to the project. MiG Layout is now #14 at the TOP 25 RFE list and climbing fast. I know of no other official way to influence Sun in these matters, so why not cast a vote or two on it? (or three..)
Is there anything else you would like to add?
Pulling 9G:s I look just like my grandfather and my heart looks like a banana. ;)
