Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cross-Platform GUI Toolkits?

Posted by Cliff on from the marginalizing-the-OS dept.

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
Additionally, these URLS have a lot of info on Platform Independent GUIs:

3 of 126 comments (clear)

  1. (D)HTML + XML by alienmole · · Score: 5
    This probably doesn't meet all the criteria right now - due to lack of toolkits - but DHTML (i.e. HTML + DOM + Javascript), combined with XML and XSL, makes for a very viable, powerful, cross-platform, "rich GUI front end". Not only that, but it's standards-based, which is more than you can say for almost any other cross-platform GUI solution.

    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.
  2. Cross-platform APIs from a Mac OS perspective by nanouk · · Score: 5
    Since you are primarily Macintosh-based, I'm going to describe things from that perspective, assuming that you wish to continue to support the Mac.

    The short answer is that there is currently no "complete" solution. By "complete", I mean:

    • Comprehensive APIs with UI support.
    • RAD tool.
    • Good database access.
    • Actually shipping and available right now.

    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:

    • Ensure that your app design & architecture are modular - break all the database stuff and business logic out into a "model", which has no UI and can therefore be highly portably written in Objective-C, or C, or C++, or whatever. Java, with JDBC, may be viable as a cross-platform solution here.
    • Abstract all UI and "controller" behavior into as thin a layer as possible, so that it is easier to implement it against different UI layers (Carbon, MFC, GTK, whatever). The main obstacle you face here is having to implement the UI code natively for each platform. The various abstraction layers that are commercially or freely available tend to take a least common denominator approach, and hence sacrifice quality, speed and flexibility. Unless you don't care about you UI very much, they are not all that useful.

    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

  3. OOUI by jesser · · Score: 5
    Ben Bucksch (who also works on mozilla) has started a project he calls OOUI. Basically, he hopes to create an abstraction for user interfaces that will allow a high amount of separation between applications and UIs. This will (hopefully) let application developers write programs that will work well on wingui/macgui/console without too much work, and will let users set preferences about how he/she wishes to interact with his/her programs or a specific program (window arrangement, font scaling, voice interaction).

    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.