Slashdot Mirror
Cross-Platform GUI Toolkits?
rrwood asks: "The company at which I work is about to overhaul an existing application. Strangely enough, we're primarily Macintosh-based, but are casting an eye towards cross-platform development (i.e. Windows, though I'm hopeful that an X/Linux-based version is also a possibility). Given that the app is to be a fairly rich GUI front end that talks to a database backend, I'd be interested in hearing any recommendations or advice anyone out there has to offer." Read on for more information on the toolkits currently under consideration (feel free to offer more suggestions), but we are talking toolkits here. The topic of cross-platform languages got a rather thourough treatment in a previous article.
"It's pretty much a necessity for the solution technology to include a RAD tool.
With respect to using a portable C++ core and platform-specific GUI layer (or even portable GUI layer-- keep reading), there are a few toolkits around that seem promising:
- GLUI, an OpenGL-based GUI
- Whisper, a Mac/Windows application framework
- WxWindows, a framework which supports Windows 3.1/95/98/NT, and Unix with GTK/Motif/Lesstif, and MacOS
- YAAF, Yet Another Application Framework, offering suport for Macintosh OS, Windows 95 and Windows NT, and X Windows
- CPLAT, a framework for developing MacOS and Windows (Linux soon) applications
- Ardi's Carbonless Copies technology, which is a portable rewrite of much of the MacOS API
Why is this question posted to Slashdot about once a month? The answer is never different, just always a flamefest between wxWindows and Java, with some random suggestions from other people thrown in :-)
--
This page has a pretty detailed overview about whats available and what platforms each toolkit works on.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
Use Mozilla. Its already got all of the cross-clatforms (Mac,Win,X,Be...), and all the gui is written in xml. Its nice and simple, easy to modify, and importantly, looks the same on all platforms!
Sure.. its isnt finished yet, but if this product wont be realsed for a while, it might be a reall good idea to investigate
/* Lobster Stick To Magnet!*/
The "Cocoa" frameworks allow you to do this, and they're a rich set of frameworks. Unfortunately the licensing prohibits wide distribution, and as of September, all the licensing options are gone completely.
The technology is there now. It has been used by Apple/NeXT for years now for development, and is used now in WebObjects for the development tools.
Other companies have developed the both general use apps (like drawing programs, db programs, etc..) and some truely amazing vertical market stuff.
Scott Anguish
http://www.stepwise.com/
In places where browsers don't provide sophisticated enough widgets, e.g. combo/select boxes, you can use Java alternatives. For example, on the intranet systems I'm currently working on, we use a home-grown, XML-bound Java combo box which works just like the combos provided by typical GUI development tools.
DHTML-based apps can easily be made much more interactive than typical web apps, by using script to obtain (XML) data from the server and updating portions of pages rather than the standard browser model of reloading an entire page.
The following isn't very well organized, written on the fly, but benefits of a DHTML approach include:
- Natural client/server model enforced by browsers supports and encourages development of a well-separated layered model. Can be used to implement simple two-tier systems which talk directly to a database, or more sophisticated, flexible three+ tier systems with an object-based middle layer (developed in Java for portability.)
- The latest HTML, stylesheet (CSS) and XML/XSL standards support clear separation between "document" structure, presentation, and content. Reuse in software development is all about separating out functionality as much as possible - a blob that does 10 different things can't be reused as well as a focused entity which does one thing. CSS stylesheets allow you to reuse presentation definitions in different contexts, XML allows you to reuse data and queries, XSL (which applies a template to XML data) allows you to reuse "structure", i.e. implement the same layout for data in different contexts.
- Although HTML is often thought of as inferior to traditional programmed GUI solutions, when it comes to DHTML and the associated technologies, this is a misperception. In some respects, such as the widgets mentioned above, it is lacking, but as mentioned, this can be addressed using judiciously applied Java objects. In other respects, such as its handling of multimedia content (images, sound, movies), its hypertext capabilities, and its free-format layout, it is far superior. Applications can be developed which allow a user to navigate freely between entities far more easily than they ever could with traditional GUI database applications.
- Declarative rather than procedural model used by all these technologies (HTML, CSS, XML, XSL), lends itself to automation via toolkits.
- Prediction about the future: this technology is moving fast, and is likely to catch and outstrip existing GUI application development models quite quickly, at least when it comes to traditional database-oriented applications. Developing a system like this now is a bet on the future direction of such systems, and will avoid you having to retool and relearn in a few years time when the limitations of your non-browser-based cross-platform application become problematic.
The problems I see with this approach at the moment are:- Do-everything toolkits for this kind of application are not yet available. Although there are toolkits which work for particular layers of such an application (especially a middle object-based layer), there's nothing I know of that's oriented towards creating cross-platform "rich GUI" systems in a browser. The user-interface aspects of web application development toolkits tend to be oriented towards the simple, "list products, order product" type of application required by business-to-consumer web sites. On the positive side, you can still use products for web page design and so on, you just have to live with working quite a bit in a non-visual code mode to add your custom widgets, Javascript, etc.
- You'll be something of a pioneer developing an application like this now. All the old sayings like "pioneers are the ones with arrows in their backs" exist for good reasons. No one ever got fired for churning out another application with the same old reliable-but-limited existing technology.
Bottom line, you should at least consider a browser-based application in a case like this.The short answer is that there is currently no "complete" solution. By "complete", I mean:
Before the knees of Java-heads start jerking, let us examine how the obvious candidate falls short:
100% Pure Java
Though Java written only to Sun's API is in theory useable for a cross-platform app, there are a few pragmatic issues -- the APIs are very poor and complex, the UI layer (Swing, née AWT) sucks ass, VM idiosyncracies are rampant, and performance may be a problem (though improvements are constantly being made). On the up side, there are several RAD environments for Java, your development and deployment platforms can be (more or less) different, and database access is reasonably solid (JDBC).
More or less everything else out there is incomplete in terms of the three main criteria you have stated (UI APIs, RAD tool, DB access).
Apple's Cocoa/Yellow Box/OpenStep Frameworks
For just the Mac, the Cocoa frameworks that are a part of Mac OS X are by far the best solution. They are vastly more sophisticated, complete and robust that anything else on any platform (with the possible exception of some SmallTalk environments). Cocoa has top notch UI support (the AppKit), an eminently usable RAD environment (ProjectBuilder, InterfaceBuilder et al.) and DB access that is about 2 generations ahead of anything else (Enterprise Objects Framework). Cocoa is also completely cross-platform technically, and has been so for several years (at one point running on Mach (m68k, i386, hp-pa, sparc) & Windows (i386). So what's the problem? Apple does not currently license Cocoa for anything other than the Mac, and has indicated no plans to do so. This prevents people for whom cross-platform development is essential from using what is without a doubt the most advanced application development environment in existence. Yes, it sucks. Harrass leadership@apple.com about it.
So what are other people in the same predicament doing? Though there isn't currently a perfect, off-the-shelf answer, there are many things one can do to get close:
Other random notes: If GNUStep ever gets close to complete, your Cocoa code should trivially port to anything supported by GNUStep. Currently, the non-UI layer (Foundation) is production quality. Also, if your database schema is complex/demanding, you really, really should take a look at EOF, which is now a part of Apple's WebObjects product.
Handy-dandy URLs
Mac OS X Developer Documentation
GNUStep, a free implementation of the OPENSTEP spec.
Java 2 Documentation
- True Object-Orientation: Smalltalk-80 was developed at Xerox PARC under the leadership of Alan Kay, who coined the term "Object-Oriented". In Smalltalk, everything is an object -- there are no primitive types. Simpler is better.
- Elegant Syntax: it's not like C, C++, or Java -- and why would you want it to be? OO is a new paradigm, and we can all use some help thinking in new ways
- Bit-compatible across platforms: All that's needed to switch platforms is a new virtual machine. Think Java+Swing on steroids (after 20 years of smoothing wrinkles out). VisualWorks runs on Linux, Windows, Mac, Solaris, HP-UX, and more -- and it's done these things for years.
- Fast Object Engine (Virtual Machine)
- Refactoring Browser: effortlessly refactor your code with this powerful tool
Needless to say, I'm sold -- and I'm never going back to a C-style OO language.--
Signal Ground: Linux Hardware news and reviews
From his overview of the project goals (formatting changed for slashdot):
Legitimation for the existance
The idea behind OOUIs is to leave as much of the UI creation as possible to kits on the server side and so to reduce the static information (shipped with the application) to the minimum.
This gives the largest flexibilty to adapt to the user's environment (e.g. computing platform) and preferences.
Abstraction
To make as less assumptions about the UI implementation as possible, the description of the UI should be very abstract (from the application's point of view). The description should be mostly semantical, because this provides the necessary level of abstraction. Many ideas from object-orientation are used.
This level of abstraction gives the possibility to create very different, unforseeable UIs from the description.
Modularity
Choices
Moving nearly all of the UI out of the application (modularity) gives the user freedom.
E.g. if a user likes the way, the GIMP arranges its windows, he can make all applications behave that way; if he prefers console programs, he just has to switch kits; if he has a true 3D environment, he again just has to get new kits; if he has only his cell phone available, he can still use the same application. Now, that's "portable"
Consistency
Because the concrete UIs for all applications are created by the same entity, the OOUI kit, a high level of consistency is reached.
Faster application development
Once the programmer knows how to create OOUIs, the use of them should shorten application development time, even if only one platform is targetted, because there is no need to care about UI implementation details. However, this is just a positive side-effect, not a goal.
A comfortable filemanager similar to Microsoft Windows Explorer could be created in one day. An example diagram (which represents the most important part of the OOUI description) has been developed in 2 hours. When the simple backend code using OS commands is written and some icons and texts are defined, the filemanager is finished.
(end modified quoting from Ben's OOUI overview)
--
The shareholder is always right.
I finally came to believe in the use of Mozilla for XP development when my net connection went down on my box and I was forced to use chatzilla to access irc from a windows box. when I finally got access again from my Linux box, I fired up chatzilla (just to check and see, since I had never used it on Linux) and it was identical. Every single motion, action, etc. was exactly the same across the two platforms. I guess I expect this from my browser (which is why it never struck me before with Mozilla) but other programs are supposed to be weird and unpredictable and different across platforms (even Java, at the least, has different L&F.) But with Mozilla, there is none of that. You write it once and it just works.
So, my point- go get the latest nightly builds from ftp.mozilla.org and play with them, and I think you may see the future of XP design. Or maybe not- but it is definitely worth looking into.
~luge
P.S. Oh yeah... forget Linux, Windows, and Apple. Think: "every platform in existence" and then you'll get a clue as to where Mozilla (as a XP UI development tool) is headed.
IAAL,BIANLY
What we are now working on is a cross-platform library that will have an XML representation of an interface, and will bind to the native widget sets on whatever platform it is run on.
For example, under Linux/GNOME it will use GTK, and under Windows it will make the native Win32 calls. We feel this is almost always better than the normal method of porting a widget set across platforms, which projects such as Mozilla are doing. Advantages:
- Very fast since the native widget sets are almost always highly optimised
- High integrated since the users already have their widget sets customised to what they want
- More stable if properly done, since you dont have to deal with debugging your own widget sets (assuming there is a decent native implementation of course)
- More future proof if the native widget sets have a clean API, and if the OS is upgraded (ie windows 95->98) then you have a higher chance of your widgets surviving unscathed
The major con is that you have to deal with the lowest common denominator of common widgets, although an option we are investigating is simply implementing the extra widgets natively (eg a dll under win32), which isnt a lot of trouble.We have set a release date of around the end of august of this to be released, but the plan is for the UI code to be a completely separate library, so if anyone is interested, drop me a mail and Ill put you in touch with the head developer dude (Dominic Ludlam) for that aspect of the project.
Cross platform toolkits sound like a good idea. You can support more platforms with minimal effort. Good thing, right?
Well, the *goal* is a good thing. The methodology is a VERY VERY bad thing. I've only seen one toolkit with the potential to avoid the problems I'm about to describe, and it's not being used to do so.
Every GUI established conventions. These range from the trivial (CTRL-INS is copy, SHIFT-INS is paste) to the non-trivial (buttons on confirmation/warning/etc dialogs are right-aligned) to the very high-level. (actions that can be performed should be described using the present progressive tense)
Simple toolkits can only manage the simplest of these conventions (such as keystroke bindings) and even then can do so only partially... Anything where you have to explicitly state the, say, keyboard binding is beyond the control of the toolkit.
More abstract toolkits such as JFC, and Qt (probably GTK also, although I don't have any real experience with it so I can't be sure...) -- ones that use geometry managers -- can handle some of the higher-level stuff such as button alignments.
A very rich toolkit can provide even higher level stuff -- such as file open/save dialogs -- in a sufficiently generic manner.
But things such as linguistic conventions, i18n support, and broader conventions of UI layout are beyond the control of any toolkit to provide.
The end result is that an application you port winds up not feeling or acting like a native application. This throws users off and makes things harder for them. Unless they happen to be very sohpisticated users familiar with multiple GUIs of course.
The only toolkit I know of which has the *potential* for getting around this is Mozilla's XPToolkit -- and it isn't *just* the toolkit that's needed. Basically, the entire UI is written as a bunch of XML and JavaScript.
You could have platform-specific XML/JavaScript front-ends with the exact same back-end code.
But that's a hybrid solution (it has drawbacks such as having to support a fair amount of platform-specific code), requires careful design of the appliction, and is generally not feasible.
The Mozilla group certainly isn't taking advantage of it -- they just have their AOL/Netscape UI on all platforms and it is up to the user to create/find a platform-specific UI.
-JF
MrJoy.com -- Because coding is FUN!
Making a program look identical on different platforms is a popular form of user abuse. It makes life easier for the programmer, but it's guaranteed to frustrate most users. Apple's Quicktime player is a good example of this... as horrible it is on the Mac, it's even worse on Windows. You know how the Mac puts the menu bar at the top of the screen, whereas Windows attaches it to a window? Apparently the folks who ported Quicktime couldn't even handle this slight difference, so they just stick the menu at some arbitrary place on the screen, in its own little window.
I digress... The point is, interface consistency is good. But how often are people going to use the same application in more than one environment? On the other hand, how often are they going to use different applications in the same environment? That's the consistency that matters, no matter what programmers find asthetically pleasing.
MSK