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

Additionally, these URLS have a lot of info on Platform Independent GUIs:

• GUI Toolkit/Framework Page
• PIGUI FAQ Page
• C++ User's Journal PIGUI Page"

Comments

Again?

[Dr. Sp0ng]

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 :-)
--

Re:Again?

[jpowers]

just always a flamefest between wxWindows and Java

As irritating as java can be, I have seen some good, portable clients made with it. I think as long as you're not trying anything hardcore with the client display, java should do just fine, plus it's pretty close to c, so your current programmers can probably pick it up in no time.

-jpowers

Re:Again?

[Anonymous Coward]

On the contrary, I think that this is a very good reason for posting such questions regularly.

why not try QT2.1 and KDE

[penguin_nipple]

I have been investigating the use QT2.1 and KDevelop for a while now. And I must say, its quite impressive.

In addition to which you could also start by using KDevelop and Klyix (the new RAD tool) from Inprise shouldn't be too far away...than you could have a group of programmers who are used to the QT specific issues who need to incorporate a new RAD (no big deal in my opinion).

Give it a shot...it has been working for me =)

Re:why not try QT2.1 and KDE

[Anonymous Coward]

Qt doesn't support MacOS.

Motif

[VaporX]

I would recommend Motif or a Motif based framework. While programming in Motif isn't the most pleasant experience, it is extremely portable. Nearly every major OS has a Motif implementation.

Re:Motif

[rc-flyer]

Is Motif available for Windows?

Re:Motif

[CabanaBoy]

Yes. Hummingbird Exceed includes mwm. The Exceed XDK (X Development Kit) includes all the X, Xm, and Xt development libraries you'd need to compile a Motif app for Windows. I use the XDK and MS VC++ to compile the Windows NT version of our flagship product, which also ships for Solaris+CDE.

The downside is that your clients also need to buy Exceed (or Exceed 3D, if you're using OpenGL... The XDK includes the OGL libs as well) and have it running... Can't open a pure X-Windows GUI without X-Windows, now can we?

I don't think there's a port of LessTif for Windows, so I'm not sure this is the way for an opensource/freesoftware programmer to go.

But damn, it *does* work well.

Re:Motif

[The Mayor]

Having been a Motif programmer since the v1.0 days, I can wholeheartedly recommend against using a Motif-based framework. I've had experience with about a half dozen other GUIs, from MFC to InterViews to XForms, with a few others thrown in just for fun. Motif is absolutely the worst of the lot.

My favorite would have to be Swing (Java). However, I've seen many people run into serious problems with performance if they're not careful with their memory allocation (and, thus, garbage collection). It works reasonably well on all platforms, and is very easy to work with. This isn't the answer for everyone.

Another approach I've used a lot lately is building HTML front ends to JSP-based back ends. Again, this only works in certain situations, but it allows the client to be much smaller than with a Java solution.

I've also had the pleasure of building a few XML-based GUIs (XML files laid out the widgets, which were created from a Java program). Seems to me that this could be plugged in to several different GUI schemes (build a GTK or an MFC layer, separate your GUI from your core code, and voila!). That said, I'm not going to do it. And I would think it would be cheaper to use someone else's solution (read: buy it, or use an open source solution).

But, please, don't use Motif.

GTK ?

[HomerJ]

If you're a MacOS oriented house, I'd assume you are going to support OS X. With the unix nature of OS X, I'd assume a GTK would be fairly easy to port, if not already done.

There is also GTK for Windows. I'm not sure how well the port is done, but if it's good enough for Mozilla......

The cross-platform nature of GTK is why Mozilla had the exact same look and feel across platforms. I'm not sure how well it would work for you, but it's something to look into.

Re:GTK ?

[mattbee]

There is also GTK for Windows. I'm not sure how well the port is done, but if it's good enough for Mozilla......

I don't think Mozilla uses GTK any more-- however, the GTK port I've used is the same one that powers Win32 GIMP, which works like a charm (though ISTR the file selection boxes were a bit ropey).

Re:GTK ?

[Misagon]

The cross-platform nature of GTK is why Mozilla had the exact same look and feel across platforms.

Nope. You can hardly ever find any native (or GTK) widgets in Mozilla these days. The look (and some of the feel) of all Mozilla widgets are now defined with cascaded style sheets - in the same way that style sheets can be used to theme web pages. You can find the files in the chrome subdirectory There is a single exception though: the Mac version uses the native menu bar, so you can't theme that one.

Re:GTK ?

[profi]

There is a GTK+ for MacOS project on sourceforge.net, but like many other projects it appears to be stuck in the "wishful thinking" phase.

Re:GTK ?

[mvw]

There is also GTK for Windows. I'm not sure how well the port is done, but if it's good enough for Mozilla......

It was ported by Tor Lillqvist in order to port the GIMP to Win32.
Being able to use the GIMP at home under FreeBSD and at work under Win32 helped me a lot this year with some serious documentation tasks where I used it for the illustrations together with Gnuplot (which I got to run under Win32 as well).

So much to the folks who cried traitor when it became public that Tor ported this fromidable program.

I just left a company that used the old StarView library to build Win32 and OS/2 application. Yes, some folks (here German banks) still insist on OS/2.

So that gave some real world lessons with a huge application built on a cross plattform GUI kit.

OK, we developers cursed StarView a lot, but this was mainly not because the class library was BS, but because we were left with the ~1994 source code of a further unsupported product. (Star Division continued with a new version that is the base for todays StarOffice, but this lib was never made public as the old one was).

While the source was available to us, that just enabled us to do changes at all. We did the 16bit to 32bit migration of the NT code base, the Borland to MS Devstudio migration, a lot of bugfixes and some enhancements to both NT and OS/2 versions we needed. Everytime it was a non trivial time consuming job to get it running. I would have prefered to have some commercial support.

Think of something very complicated that works most of the time, but if it is broken then it creates a lot of trouble because no one usually likes to touch it and is untrained with it.

Another point was, but was far less important than the functionality, that the applications turned out to look very old fashioned. You immediatley see that a lot of things happened to tthe Win32 and even the OS/2 native GUI in the last years. If our clients were not banks, were some mainframe stuff is still in use, we had certainly to work that aspect.

If I had gotten the task to convert our applications to a modern GUI like MFC or GTK or QT, heck, I probably would have had written a modern-gui to old-StarView interface layer, because of the sheer giant heaps of present code that use the old interface. So better have a good look at the structure of your intended X-plattform GUI before you start a large task with it. You might never have the chance to get rid of it, without starting to rewrite the app.

And similiar to the experience I had with Java, it was only seldom the case that I could just stick to developping under one operating system, eg Win32, and expect the version for the other platform, say OS/2 to need no fine tuning. There were issues with the fonts and other system specific glitches.

Please forget that it is not only the different GUI you have to face when working X-plattform. No it is different tools too.

A Microsoft Compiler under NT does not speak the same C++ as a Borland Compiler or Visual Age under OS/2 does. So if you want to use modern features like exceptions or even templates you are in for a lot extra fun.

My personal favourite for least headaches is using gcc together with GTK whereever possible.

Yes I still prefer C and C++. While Java seems to have matured a lot, I still consider it a joke for everything larger than an applet. Emacs does better as a X-plattfrom VM. :)

Re:GTK ?

[gargle]

There is also GTK for Windows. /i

Horribly slow. At least GIMP is.

Re:Have you looked at RealBasic?

[jpowers]

Basic? I think they're trying to sell this...

-jpowers

Good Detailed Overview

[N8F8]

This page has a pretty detailed overview about whats available and what platforms each toolkit works on.

Re:Just make sure you stay away from Qt/KDE

[penguin_nipple]

Since the question being asked is for a corporate entity, purchasing a QT license package is a minor investment

The QPL is sufficient for OSS and QT is a very solid framework from which to code.

I do it on a daily basis.

Granted a Mac consideration is not there.

So, revising my earlier post, maybe wxWindows would be advisable, however, worrying about GPL in the scope of closed application development is irrelevant.

Mozilla

[BobLenon]

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 ;)

Re:Mozilla

[EverCode]

Yes. Personally, I am getting deep into XUL, and there is a lot you can do with it, including making your own widgets using XBL, and having dynamic GUI data using RDF.

Apparently Mozilla is going to release a separate, cleaned up, developers toolkit for creating applications using Mozilla technology. I think once that is released, you are going to see a lot of applications being built using XUL.

Right now, all this is pretty buggy, but in a few months, I think it will be ready to go prime time.


"...we are moving toward a Web-centric stage and our dear PC will be one of

gfx development

[Godfree^]

While vaguely related, this isn't really for GUI, more for graphics in general...

If you're doing multimedia development, I'd recommend SDL (Simple DirectMedia Layer), a wrapper for X, DGA, OPenGL, DirectX and various other lower level APIs. It's available somewhere on www.devolution.com.

If you doing 3D stuff, try GLUT. This one acts as a simple windowing toolkit for various operating systems, including Windoze, X, Mac OS et al.

Application UIs are dead as door nails

[The Future Sound of]

Use the browser as your front end. That's the only way to go.

Nobody uses GUI toolkits anymore. Your front end should be HTML.

Re:Application UIs are dead as door nails

[webster]

Nobody uses GUI toolkits anymore. Your front end should be HTML

This is not even almost true. While HTML is the right choice for a great many applications there are still a whole lot of times where you need a richer, more flexible set of User Interface elements. Applications that are heavily oriented to data entry, that need quick response of an indicator to human input, that load up data into controls in a fairly complex manner, or that have to cram a lot of controls into a small sppace are good candidates for a traditional GUI. Use the right tool for the right job.


Always and inevitably everyone underestimates the number of stupid individuals in circulation

Re:Application UIs are dead as door nails

[rc-flyer]

Don't make these statements without knowing the problem. There are a lot of people who use GUI toolkit, Just because you don't like them, doesn't mean that they are dead.

GUI toolkits have many advantages over a browser-based front end. As a simple example, there can be some fairly complex validation and verification functions which may be doable in the front end, and reduce the need to load up the server with the validation and verification.

Re:Application UIs are dead as door nails

[Happy Monkey]

Then use emacs as your front end!
___

Re:Application UIs are dead as door nails

[MikeFM]

IMO DHTML is still to messy for real world use. To make it work across browsers you have to do all that work making different versions and then somebody always seems to find the one version of whatever browser that is incompatible. On the other hand I'd agree that most db-oriented apps could probably use the browser as their client. PHP makes it rather easy to program powerful apps w/ db backends. I wouldn't use anything but a browser front-end unless it was something that really needed a special function that HTML can't offer.. then I might look at the Mozilla API's to see if I could use it as my front-end.. if not then I'd probably listen to one of these smart C/C++ coders here who do that sort of work often. :)

Re:Application UIs are dead as door nails

[antijava]

Application UI's aren't dead until something with the GUI richness of PhotoShop can be
done entirely in a browser. I don't see that any time soon.

Re:Application UIs are dead as door nails

[mvw]

Then use emacs as your front end!

I would love to do. But given the fact, that developers are small minority among users, and Emacs users are a small minority among developers, I would not dare. :-)

About that HTML idea. HTML has simply not been intended for controlling layout, so there are many cases when it does not bring the necessary looks. Some folks use Flash as an alternative. And to be honest, theses sites look not bad at all. Have these two examples:

The site of Talla2XLC, arguably one of the best german DJs. His site looks cute and are even able to choose one of several background Techno music stomps. :)

The Siemens corporation site.

Of course we have the problem that this flash module is not available for every platform. I used it from within the Linux Navigator under FreeBSD's excellent Linux emulation. I would have prefered a FreeBSD flash module but there was none (working) the last time I checked.

I also do not know if there are open source authoring tools or even generating tools available for that format.

Re:Application UIs are dead as door nails

[DrSkwid]

Talla

poor UI

buttons that don't indicated their use before you mouse over them! This means you don't know which elements are buttons and which are graphics. Very poor design.

Try using it without a mouse.

html for design, yeah right.

It's such an unbelievable BAD choice for UI.

The overhead for creating the simplest UI elements far outweighs the slight benefit of having a document holder already built for you.

Cascading menus for instance, or print previews or file dialogs, colour pickers, sliders, spin controls etc. etc. etc.
.oO0Oo.

Re:Application UIs are dead as door nails

[DrSkwid]

Anything you can do with a GUI toolkit you can do with DHTML

Can you show me a DHTML page with a slider on it please.

I'm not sure but can DHTML do DDE?

Have you got a url for a DHTML ftp client?


.oO0Oo.

Tcl/TK and Perl/TK

[Anonymous Coward]

Both Tcl/Tk and Perl/Tk are easy-to-use, general-purpose language interfaces to the TK library. There are more RAD tools available for Tcl/Tk, but Perl is imo somewhat more attractive because there are more high-functionality library modules available for Perl, and I already know Perl (and being able to use a language that your programmers already know is an important issue, having an impact on development time, code reliability (fewer mistakes in a familiar language), and maintainability (easier to find programmers with Perl experience than with Tcl experience)).

Both Tcl/Tk and Perl/Tk are well-supported under MacOS, Windows (2k/98/95/NT), and various Unixes (Linux, FreeBSD, Solaris, etc). It is, perhaps, a little more work to make your Perl code portable across Windows and MacOS, but IMO easier than making your C++ portable.

If you don't like the performance of Perl, you can do what I do and write just the GUI part in Perl/Tk, and let it talk through pipes to your "real" application (written in C, or whatever).

-- Guges --

Try Forte

[webster]

I don't want to add to the Java vs (Windows || C++) holy wars, but if you do decide to try Java, then you should also give Forte a try. Sun has recently released the basic IDE as open source under the Mozilla license. I haven't yet used it on a large project but after just playing around with it for awhile it seems to be as good as any other IDE I've used. It's written in Java, and will therefore run on any platform that supports a JRE.


Always and inevitably everyone underestimates the number of stupid individuals in circulation

Re:Try Forte

[jacoplane]

I think Forte for Java, Community Edition is a good option, but people might also want to take a look at the JBuilder Foundation, Community Edition.

Re:Try Forte

[crivens]

The same goes for me - it made my P3-700 with 25Mb look like a P100.

Database frontends belong in a web browser.

[bandix]

I would assume that every platform you would conceivably want to access the database frontend from has a web browser available to the user. The correct way to create a portable database frontend is to make it web-based. You can place the frontend on a unix server stowed away somewhere convenient and users from any platform can point their web browser to the correct address and manipulate the database from there. The benefits are multifold. For starters, you can upgrade the code to a newer version without reinstalling the client on multiple machines. Any sysadmin appreciates the import of that feature. Your users are also not tied to a particular machine or location. You can allow access to your application from properly authenticated external sources and when users go on the road they can easily access the database. With the ease of use and rapid development qualities of Perl DBI or PHP as advanced as they are, there is little reason to ever write another database frontend application framework.
--

Re:Database frontends belong in a web browser.

[rc-flyer]

There is no "correct" way to create a program. Each application needs to be evaluated on it's own needs and merits.

The application in question states that it is a fairly rich GUI front end. This may be too complex for a browser-based app.
Yes, browser-based apps do have their advantages, but they also have disadvantages.

Re:Database frontends belong in a web browser.

[alienmole]

The application in question states that it is a fairly rich GUI front end. This may be too complex for a browser-based app.

See my post entitled "(D)HTML + XML" somewhere in this topic. If you think rich GUIs aren't viable with a browser-based app, you've either been misled by the lowest-common-demoninator apps you see on public web sites, or you're unfamiliar with the current state of browser technology and related standards, or both.

Re:Database frontends belong in a web browser.

[Bob Uhl]

Don't forget that there are more than a few people who browse with JavaScript and other DHTML stuff always off. It is more than a little annoying to have to sqitch it on for any app.

IMHO the switch to browser interfaces was due to laziness and `acceptable level of mediocrity'-style thinking. Far far better in terms of UI, ease-of-use, attractiveness and speed IMHO is the binary client. I understand from others (never done it myself, so I will not preach it as true) that it is not too difficult to abstract away platform-specific GUI code and leave the internal logic of the app intact. I admit that I am a bit sceptical, as some platforms (e.g. Mac OS) are inherently different even in re. very high-level concepts of control flow.

But please, in the name of all that is holy, please do not use a JavaScript/Java browser monstrosity. Blecchh.

Re:Database frontends belong in a web browser.

[alienmole]

I wouldn't try to use this kind of application on a public web site today. The applications I'm talking about, described in the "(D)HTML+XML" thread elsewhere in this topic, are for business-to-business use in the financial services sector. Requiring that Javascript be enabled is not a problem in this environment.

"IMHO the switch to browser interfaces was due to laziness and `acceptable level of mediocrity'-style thinking."

The interfaces I'm referring to have evolved from binary GUI systems running across wide-area networks between companies, and the browser solution was chosen to solve problems with this approach. I can tell you from direct experience that the binary GUI approach is not superior, from a development standpoint. And user response to the browser-based applications has been very positive, because we've been able to do much more with the same development resources than we could when developing binary GUIs.

You put your finger on one of the problems with traditional GUIs when you said "some platforms (e.g. Mac OS) are inherently different even in re. very high-level concepts of control flow." You're quite correct. In addition, in the case of both X and Windows (I can't speak to Mac), those high-level concepts are outdated and flawed, and this tends to show through in most GUI frameworks.

By contrast, the Document Object Model is an open standard, which as I mentioned in my original post, is more than you can say for any GUI framework. The DOM provides one of the most high-level, well-abstracted object-oriented user interface models I have come across in more than 10 years of working with GUI frameworks and tools, in a variety of languages.

"But please, in the name of all that is holy, please do not use a JavaScript/Java browser monstrosity. Blecchh."

Our use of Java on the client side is limited to a few strategic components such as the XML combo box and server comms capability. There's no ongoing development in client-side Java. Use of Javascript is similarly encapsulated as much as possible, using a set of generic Javascript view classes. Here's an example of the actual code for our generic view initialization routine:

function loadViews()
{
with ( this ) {
for ( var i in aViews )
aViews[ i ].load( action );
}
}

The rest of the view management code is not much more complex than this. It supports pages consisting of multiple independent (sub-)views, such as a typical master/detail display. Many views require no custom Javascript, just the instantiation of the View class with a reference to the corresponding HTML form. In cases where custom behavior is required, the View class can be inherited and extended.

Things like field validation are not coded directly, but rather are driven by XML metadata from the server and processed by a standard set of client-side Javascript routines.

Finally, all this just relates to the user interface. Application logic all resides on the server. There's no significant logic in the UI, and certainly no application logic.

I suspect a lot of negative attitudes about browser interfaces come from people who have watched them evolve from something much more limited, and used for a purpose other than application development. However, if a company had released a product like this targeted at the GUI framework market, it would have quite an impressive list of marketing bullet points, some of which I covered in my original post.

All such choices involve project-specific constraints and a large amount of subjectivity. Don't condemn something out of hand just because it happens to be abused on public web sites by webmasters who delight in inflicting scrolling headlines and animated images on unsuspecting surfers!

CodeWarrior might Work

[ClubStew]

At the company I work for now, we used CodeWarrior for Windows and Macintosh development. Of course, we did have a few problems and didn't really need to target the Macintosh platform anyway, so we dropped it.

So, yes, the IDE (with toolkits) did have a few problems but mostly in the way of TCP and UDP (which our application needed). The toolkits seemed to work fine.

Hope that helps.

Cocoa Cross Platform Frameworks

[sanguish]

The real pity here is that Apple HAS the cross-platform tools now to create applications that run on both Windows and Mac OS X Server.

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/

V gui

[LinuxGeek]

I have been playing with V gui since it was mentioned in Dr. Dobbs in '95 or so. It is quite nice these days and works well between WinXX, X windows and OS/2 for those that still have need to support it.

V is freeware and has many good tutorials to help get you started quickly. They even have some pretty good language guides if you need help in that area. Overall, not as polished as some commercial cross-platform toolkits I have seen, but quite extensive for a free package.

FLTK

[sunya]

fltk (Fast Light ToolKit) at http://www.fltk.org/ works for me, for Windows and Linux.

Java? HTML?

[RobertGraham]

We've already started re-writing our Windows app into Java for Linux, Solaris, Windows, and MacOS X. Java is definately NOT "write-one-run-anywhere", but it should be close enough.

(Actually, it is made easier by the fact that we've been writing our code in a style ammenable to Java, so we can actually PORT much of the code rather than rewrite. A hint for those porting C/C++ to Java: don't do pointer arithmetic.).

Another alternative is HTML. A lot of database-based applications would be beta off done with HTML frontends. For example, our bug tracking database is simply an HTML frontend thrown onto a database backend.

Re:Java? HTML?

[Kingpin]

What's the fuss about Java not being portable? I need an example. I've actively developed in Java for 2 years now, I have not once had portability problems.

As for HTML front, I also believe that's the way to go. Or even better, make an XML layer and make a HTML/XML proxy. This way, your fat clients can also connect to the servers, and render the XML based on your DTD. The future is not the fat client, but lets not forget the users who want that 'oh so neat' Wintendo interface. Don't make a fat client, it's not worth the trouble. If your system bugs, you'll only need to lof onto the server, fix the bug and restart. Not redistribute N fat clients.

V is portable

[rc-flyer]

I've looked into this too. The toolkit I am leaning towards is V, located at http://www.objectcentral.com. Well supported, and is under continous development.

Web Based

[wharfrat]

I know this has allready been posted but... Make the front end web based. It has two very important attributes.
1. Cross platform.
2. Easy on network. What happens when the CFO decides he wants to access the application remotely (dial-up, extranet, telecomute...ETC)? With a Web based application it is easy.
Back end can be cross platform as well. PHP is supported on all/many systems, as well as Coldfusion, as well as ASP(Yukkie).

Get A Caffeine Boost From Java

[ekrout]

I would strongly recommend using Java if you'd like to write code that is truly portable and can be run on anything from a Palm Pilot, to your toaster, to Windows or Mac's new X OS. Another good reason to use Java is that with the introduction and "rave reviews" given to XML, it's a great way to combine code (Java) and data (XML) portability since both of these languages are seemingly made for one another and work quite nicely together. Good luck!

What about X-platform project management tools?

[SIGFPE]

I work in movie visual effects and this is traditionally a Unix based culture. But with SGI completely letting the industry down we have to turn to Windows. Even before getting onto building GUIs we need to manage our basic projects. I use CVS with Makefiles under Unix. But that doesn't really sit well with Visual C/C++ which stores projects in mysterious (at least to me) binary files. What is a good cross platform revision control system that would allow me to use the Visual C++ IDE as well as Unix command line tools? I'm dreading getting onto the GUI stuff. What happens when you want OpenGL in your GUI? What happens when you want to blit hi-def images to the screen in a GUI multi-platform at 60 fps? All tough questions I think.
--

Re:What about X-platform project management tools?

[mvw]

Projects (.dsp, .dsw) are stored in a kind of makefiles under Visual C++ as well. It is also possible to manipulate them to a certain extent.

However there is nothing in the MS Developers Studio IDE that forces you to use it if you don't want, possibly with the exception of the debugger - and you need working debugging sooner or later.

I used the NT version of Emacs 20.x happily as text editor all the time, while starting compilation from within the Dev Studio. No problem.

Also having used rmail was not a bad idea too, considering that stupid Outlook worm. :-)

If I had had more time, I maybe had tried to use the existing Visual C++ bindings for Emacs that float around the Emacs repositories.

While I am still an Emacs fan, I had to admit to our Win32 zealots, that Dev Studio has aquired many features that I knew from mighty Emacs only previously. But I am sure the Emacs crowd will catch up - that stuff is open source and sooner or later every itch gets addressed.

Using CVS under Win32 is possible too, I had only problems with CR characters showing up at places where I did not want them. Otherwise it worked fine, even with ssh to remote code repositories over the internet.

Like I said above, it is possible to use the command line version of the MS C/C++ compiler from usual Makefiles and thus from within Emacs, but I don't think the debugger is available as a command line tool. That would make it harder to integrate it with Emacs. On the other hand the Developer Studio is highly customizable with Visual Basic and COM modules. So maybe some hacker with time get it done sooner or later.

Re:What about X-platform project management tools?

[functor0]

At a place I used to work at, we had a pretty good system for XP on WinNT, Solaris, and Linux. For source control, we used Perforce. On Windows NT, we used Cygnus' Cygwin tools (http://sourceware.cygnus.com/cygwin) for bash and other unix tools. For editing we used vim (and gvim) on all platforms. For building projects, we used the XP make replacement jam (http://www.perforce.com/jam/jam.html). All of these are great tools and worthwhile to use.

Don't do it

[bataras]

I've been through the cross platform C++ GUI library thing twice before. It never works. Its never clean. You never quite get the results you want. The same number of people working on your current product won't be able to magically do the cross platform one no matter how good the GUI abstraction library is. Do it right and perfect. Use the native APIs.

Re:Don't do it

[Giro d'Italia]

Thanks for bringing up the obvious solution. Design the application properly, and you can easily hook it into one gui library or another. Hell, use ncurses if your clients demand a text based version. A few conditional #defines and #includes, and you're on your way.

Far too often, some idiots always add business logic to the gui because it's easier. It's not in the long run.

These questions about cross platform coding (not just limited to gui toolkits) wouldn't be so urgent and confounding if people would just use object oriented programming.

Re:Don't do it

[swdunlop]

I agree, I have never gotten the same results on multiple host environments from WxWindows, GTK+, or FLTK. My application required a signifigant amount of fine control over the widgets, and their placement, and invariably, one or two of the host environments would need special tweaks.

I would really suggest that you use a seperated front-end, back-end model of development. Write the common application logic in one tree, and have the platform-dependent UI communicate the user's requests and the application's response.

As for using Java for all of this.. I'll use Java once it's mature. All these different runtime environments and the rather hefty configuration requirements on the user to install the runtime that we would require, makes it a real headache for professional developers. We get more support calls on our one Java-2 dependent app than the five other more complex apps in the suite, and most of them are JRE problems.

Re:Don't do it

[martin-k]

Either the moderator doesn't understand what he's doing or he's on drugs or he's using a wheelmouse. (option 3 is what happened to me when moderating ...)

This is a valid comment, especially wrt Mac users.

-Martin

Tcl/Tk is a solid, cross-platform free GUI toolkit

[johnhebert]

It is available for most operating systems (Mac, Win32, Unix, etc.) and has been in use for a few years, so there is a large developer community and lots of documentation out there.

http://dev.scriptics.com/

GLUI still active?

[ChadN]

I sent e-mail to Paul Rademacher months ago with a patch to the GLUI 2.0 beta (which looks VERY nice and promising). The patch allowed it to compile under GCC 2.95.2 (basically fixed some casts and such). Never heard back from him. The beta has been up for quite a while (> 8 months). Does anyone know if he is still supporting/working on it, or if he is still around?

People working on 3D apps should take a look at GLUI, it is a NICE complement to the more traditional GUIs.

Re:GLUI still active?

[baxissimo]

I sent e-mail to Paul Rademacher months ago with a patch to the GLUI 2.0 beta (which looks VERY nice and promising). The patch allowed it to compile under GCC 2.95.2 (basically fixed some casts and such).

Yeh, I think I sent him some similar mods. I also sent him a patch that added a better command line widget with history and some other improvements to the basic text item widget (for instance as it currently ships, typing a CTRL-A actually puts an invisible CTRL-A character in the text buffer!)

Does anyone know if he is still supporting/working on it, or if he is still around?

I think I heard that he is out of grad school now and working somewhere. So I suspect it is no longer actively being developed. I was toying with the idea of asking Paul to release it to community control. Right now it is not under GPL or anything -- just says that he owns exclusive copyright.

GLUI is very nice for small projects. I've used it for a number of little apps, but I would definitely not recommend it for anything major. First, the design, while written in C++, is not very object oriented, mainly because it doesn't stray too far from the GLUT ideology, which itself is not very object oriented. Second, as another poster points out, the window management is rather lacking. It doesn't seem to have been designed with the idea of opening and closing different windows over the life of the app. Extensibility is also a problem. The 'GLUI' class in the API has a separate API for instantiating and adding every different kind of widget to the UI. For instance rather than creating a button and calling something like glui->addWidget(button), you call glui->add_button(...list of button parameters...). That means that if you want to build your own widgets you can't put them on equal footing with the native ones. You would need to modify or subclass the 'glui' object for that.

On top those drawbacks, unless the poster is developing a 3D opengl app (which he didn't say), I would stay away from toolkits like GLUI which were designed as a cross-platform solution specifically for GL apps.

If you are interested specifically in GL windowing toolkits, I recommend you check out the GLOW toolkit by Daniel Azuma. I've tried it on linux and WinNT 4.0. He's put a lot of work into making it a fully functional gui toolkit. The look and feel is kind of like motif on a bad day, but the underlying library looks solid. So who is interested in making GLOW skinnable?

Re:GLUI still active?

[zero_offset]

Actually according to his web site, it does say it's under GPL.

(D)HTML + XML

[alienmole]

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.

Re:(D)HTML + XML

[EverCode]

Sounds like you need Mozilla to base this on. Read my comment up above.


"...we are moving toward a Web-centric stage and our dear PC will be one of

Re:(D)HTML + XML

[alienmole]

I agree Mozilla is very promising, but we have live apps running now, and Mozilla isn't quite ready for prime time.

Also, the idea of requiring a particular browser negates one of the benefits of this approach. For us, a big factor in the decision to go in this direction was the underlying standards. In many cases, there's a significant benefit in being able to say "our app will run on any browser that supports the relevant W3C standards", rather than requiring that users install a browser which may be different than the one they're already using.

Re:(D)HTML + XML

[EverCode]

Mozilla is 100% standards compliant. It is everything else that isn't, including IE, and super especially Netscape 4 on down.

Hopefully IE will be nearly as compliant as Mozilla already is, and then we don't have to worry about it anymore.

Plus, it all depends on what you are doing. Like Webmin, it is all run my server-side scripts, so it really don't matter what the HTML or whatever else you want.

If you want to do something like a word processor or spreadsheet, Dynamic HTML/XML is not going to do. You would have to use something like XUL on Mozilla, if you are going to going to do something that rich.

What it comes down to is that you want to build for the future. In that respect, I think Mozilla is the only route to go. You can't argue against W3C standards...

"...we are moving toward a Web-centric stage and our dear PC will be one of

Re:(D)HTML + XML

[alienmole]

What it comes down to is that you want to build for the future. In that respect, I think Mozilla is the only route to go. You can't argue against W3C standards...

We're in complete agreement about the usefulness of W3C standards, but what I'm saying is that one of the benefits those standards provide is to allow developers to reduce their dependency on any single browser product. Unless and until Mozilla becomes the most popular browser, there'll be a benefit, in many cases, to not requiring it, or any other specific browser, for an application to work. Of course, as you say, it all depends on what you are doing.

Re:(D)HTML + XML

[mvw]

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".

HTML is crossplatform.

Javascript might be, if you stick to Netscape. (I would drop it for Perl anytime - and something like this gets into Mozilla :-)

But what about DOM? Is that really crossplatform? I thought it was not, but maybe I am wrong.

Re:(D)HTML + XML

[alienmole]

Yes, DOM is cross-platform. At present, its implementations do vary somewhat between the major browsers, but unless you're trying to do some very fancy tricks, this is quite manageable.

For more info, see the W3C Document Object Model page. As it says, "The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents."

Also, Javascript is very portable across all the major and not-so-major browsers, including Netscape, Mozilla, IE, and Opera. The point is not Javascript vs. PERL, but rather the availability of client-side scripting in a standard browser. For that, Javascript is literally the only choice right now.

Re:(D)HTML + XML

[alienmole]

Wow, sounds like this AC got bitten by a browser as a child. I'm only replying to this to correct misinformation.

Almost any cross-platform solution is vulnerable to bugs and variations from one platform to another, especially when you have to support both Windows and Unix (and Mac, as in the original question). The problems with DHTML may be different, but aren't worse than those that exist in other cross-platform environments. As I mentioned, the only significant drawback we've found is the lack of comprehensive RAD tools tailored to this sort of application, but for our purposes, the benefits of this approach outweigh that.

Browser differences can be quite well managed using things like browser-specific stylesheet selection on the server side, and Javascript objects which are parameterized for the browser they're running under. We're doing this now, in systems that have been in operation for some time. If a particular browser version doesn't support a specific feature, too bad, but we haven't found this to be a big problem.

As for the suggestion re Perl under Unix on the server side, the whole point of my original post was to describe what can be done to increase interactivity and "richness" of the browser interface on the client side, in cases where you don't get to choose the browser or OS.

I'm talking about database-oriented apps that require more sophistication than typical public web apps, to support complex and/or dense data presentation requirements, high-speed data entry, etc.

Client-side file I/O is not an issue in this kind of application. What is needed is communication behind the scenes between the browser and the server, controlled by scripting in the browser. Otherwise, almost any user action results in a delay while the user waits for a server roundtrip and a page to load.

As a simple example of what I'm talking about, think of adding rows to a table that's being displayed. Using DHTML and script, when the user asks to save a row, the data that's just been entered is immediately added to the table at the client side, and an asynchronous request is sent to the server to add the record. The user can immediately carry on and add another record. If the asynchronous add fails, then a message will be displayed and the table will be updated accordingly. Without DHTML, the user has to wait for an entire page load between each record, which isn't acceptable in the kind of scenarios I'm talking about.

Taking this kind of approach throughout an application results in a system that's qualitatively quite different from an "ordinary" web app, and in many ways is richer and more usable than a traditional GUI database app with its rigid grid controls and inflexible formatting.

Omnis Studio v2.4

[paled]

You've seen the banner ads with the Penguin being shot out of a cannon (Slashot) and others on UserFriendly. Click thru one of them and check out the product at http://www.omnis.net/products/studio/index.html
I am an Omnis user (against Oracle) although I'm not using Studio yet.
Native SQL drives for Oracle, Informix, DB2, etc. on Win32, MacOS and Linux.MySQL you have to hit through ODBC.
They also have a web client, so code that you use in the GUI can also be used on a web-based app server.
Lots of links listed here:
http://www.interactive-systems.com/omnis.html

Re:Omnis Studio v2.4

[donpellegrino]

Technically Omnis is a fantastic piece of software. But remember that it is proprietary and Omnis Software Inc. charges a fee for run-time licenses. You would be much better off going with an open-source solution such as GTK+.

MDI support

[maligor]

I've also been looking for a suitable portable GUI toolkit, but the main problem lies with that I want to have MDI support also and haven't found a one with it (as I don't really want to use QPL, I find GPL more suitable for my ideals). Also I've been looking for a mdi extension for gtk, I know gnome-libs had mdi support, but most users won't be willing to install gnome-libs to run a program(as it uses a ton of other libs) I know I probably should do it myself, but hell, I don't have any experience in lowlevel gui programming :-)

Good resource!

[Cybersonic]

Thanks for the link :)

Cross-platform APIs from a Mac OS perspective

[nanouk]

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

Re:Cross-platform APIs from a Mac OS perspective

[czei]

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).

Compared to what? I've written Motif, MFC, and MacOS applications, and the Java APIs are truly well designed and a pleasure to use compared to those.

As for VM idiosyncracies, I've written fairly complex server and GUI applications, and only had very minor porting problems. (See http:www.webperfcenter.com for one example.)

As for performance, I've not had a problem either. It is possible to write programs that are too slow in Java, but you can say the same thing about any language. The examples of slow programs I've see in Java have almost always been poor design. Any language would be slow if you tried to stuff 10,000 rows in a table every update, used slow algorithms, or used it where it wasn't an appropriate solution. (example: realtime signal processing.)

The only reason Java development hasn't been stronger on the Macintosh is the dismal job Apple has done on their JVM. Its never worked right, as far as I know. In fact, its the reason I traded my MacII for a washer/dryer set when Java came out, and my first attempts at Java programming on the Mac failed because of too many JVM bugs.

Re:Just make sure you stay away from Qt/KDE

[jcavanaugh]

I would suggest you contact someone at TrollTech (www.trolltech.com) and inquire about the status of the Macintosh port.

From what I remember a few months ago they were looking to hire some experienced Macintosh developers. Gee, I guess that means they are working on a port....

--John Cavanaugh

VisualWorks

[Ken Treis]

You'd be hard pressed to find a much more portable GUI building toolkit than VisualWorks Smalltalk from Cincom. At my company, we have developed an extremely rich touchscreen GUI for machine control (in the food processing industry), and we have beed very satisfied with VisualWorks. A non-commercial version is available for download (and you're free to use it for development up until you deploy). Features include:

• 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

Re:VisualWorks

[timcuth]

I totally agree that VisualWorks is an awesome cross-platform development tool. I used to work with it at BellSouth. You could develop/compile an app on WinNT and copy the resulting binary to HP-UX. It would run there with no changes, no problems, and exactly the same GUI interface.

Also, we could develop on WinNT with a Windows, a Mac or an X-Windows interface.

And all of this was in 1995, when it was a Parc Place product. I assume it has improved in the past five years.

OOUI

[jesser]

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)

--

Re:OOUI

[mvw]

I really wonder what kind of abstract UI model gets developed there.

After all a UI is not only some widgets/graphical controls with some input, and output facilities.
A typical GUI program encodes a lot of the control flow in the way the widgets interact. They might spawn or have interesting life spans.

The abstract description has to be able to cover this complicated control flow/life time behaviour.

Returning to the thought of using XML to describe a widget. It will not be only about some graphical/layout XML (HTML like XML) that should encode the abstract description of the real widget, there also needs to be some control flow description embedded as well.

Re:OOUI

[drinkypoo]

I was thinking about this some time ago, and I guess some work has been done on some of the major toolkits in this direction, and I guess OOUI is what's coming of it -- A single library that's tied to OS-provided (except in the case of unix, where everything runs in the user space) API calls.

The OOUI blurb pasted above also mentions the ability (in theory) to tie into a 3d interface. I wonder, is the author adding in Z-space now so that it can be used in the future without expanding the specification?

Seriously!

[luge]

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.

Re:Seriously!

[EverCode]

If you are going to use Mozilla to play around, you will probably want to use a couple of different builds. For example, use M15 and a nightly build. If something don't work in one, it might in the other.

There are progressions and regressions, so watch out!


"...we are moving toward a Web-centric stage and our dear PC will be one of

Re:Seriously!

[jesser]

... 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.

I don't think it's going to be like this for very long... people are going to start writing skins for various platforms.

--

Re:Seriously!

[basic]

You are right saying that it will not be like this for very long, but it will not be because of skins as each skin will be able to run on every platform. Things will look different because of the CSS system attributes.

Tk woth C works well, too

[kdgarris]

People often forget that Tk is a C library, which can be accessed from other languages besides Tcl. I use Tk with C to produce stand-alone apps for Linux and Windows.

But MDI is considered harmful!

[Improv]

Why do you want MDI?
Actually having seperate windows is (almost)
always what you really want -- multiple
workspace windowmanagers are almost everywhere
in X, making MDI a big loss. Additionally,
the subwindows are almost certain to be managed
differently than the window manager (or native
GUI) does it, creating irritating inconsistencies.
There's a reason MDI isn't well supported. It's
mostly dead.

Re:But MDI is considered harmful!

[maligor]

I just happen to like MDI in a irc client. There are two of them out there(possibly more?), both use QT, I haven't yet checked the other, but at least the other has a weird way of managing irc, happyfaces and such and no general background selection.

I suppose I'm just that much into MDI irc clients and can't find a suitable one (and don't want to program QT) I like being able to keep the irc windows in one place and even with many desktops I tend to open different programs in my irc desktop, so it gets all messy (or they open there by accident, like starting to load a program in a different desktop only to change to another just before it starts).

Seek beta testers for cross-platform framework

[goingware]

I am leading the beta test of a C++ cross-platform framework that was written by my friend Andy Green.

It supports XWindows/Posix, MacOS, Windows, and BeOS. When it is released, it is planned to be released as open source under the revised BSD license (or something equivalent; Andy is still evaluating licenses).

Among the features offered by this framework are:

• It is multithreaded; not many cross-platform frameworks are
• platform-independent threads and mutexes, condition variables, reader/writer locks, etc.
• thread-safe reference-counted smart pointers
• GUI with a uniquely flexible layout system
• Platform-appropriate widget renderers, so an application looks Mac-native when running on the MacOS and Windows-native when running on Windows. There is even a runtime-switchable renderer for demonstration and testing.
• Platform-indedependent TCP networking
• Database file format appropriate for large data or small (integers or multimedia movies). The databases are single files so they can be used as end-user documents.
• Wide support for debugging (assertions in the reference counted smart pointers, deadlock detection, debugging heap manager). If you leave debugging turned on most of the time during development, you'll have very few pointer bugs when you deliver builds to testers.
• platform-independent offscreen graphics buffers so you can draw into memory and blit to the screen in a portable way.

There's lots more. It's not more than a few weeks away from its 1.0 release so if you're considering a cross-platform API for a new project please consider this too.

While it is about to be released as a new open source product, it is a mature platform, having been in commercial use for about five years.

A particular client-server program built on this typically has thousands of client programs running a GUI and accessing the server via the portable networking where it's using the portable database library, with the server running either on Mac or Windows depending on the user's preference, so I think it's pretty robust.

While you can break out of the cross-platform code with conditional compilation, there is only occasional need to. It is fully possible to develop an application with two machines on your desk and move back and forth between them every few minutes to compile and test on different platforms.

On thing I need to say though, before you get too excited, is that the XWindows implementation needs a bit of work, at this point mainly to implement a window menu bar in XWindows, as this is apparently not provided by the default XWindows API as it is on other platforms. Also it does not yet have support for international text, although this is planned (very likely after the 1.0 release).

(Java && Swing) || (Java && AWT)

[nerdwarrior]

Java, which is inherently cross-platform, boasts two very commonly used and powerful GUI toolkits, the AWT and Swing. Being built on the MVC paradigm, they're an excellent choice for OOA/D/P.

Re:(Java && Swing) || (Java && AWT)

[crivens]

Except from what Ive seen, Swing runs so slow, I find it unusable.

Xlib

[Mathieu Lu]

I know some people might think I'm crazy. I've been playing around alot with a couple of APIs (Xlib, GTK+, wxWindows, OpenGL/GLUT, MFC), and, well, I see all the very cool projects other people are working on, for example, I didn't know of GLUI (mentionned above), and it really sounds interesting.

I also see projects about adding a new UI layer, but somehow, this worries me, there are already alot of layers for most X applications. Know, back to Xlib, how very impossible would it be to transform it into a cross-platform library? Well, not exactly cross-platform, but maybe write a wrapper for it in MacOS or Windows. It would maybe create more problems, but it would solve the "let's keep rewriting more APIs so that people will just stick with Motif".

I'm just throwing this off the top of my head, I know I'm probably wrong. But hey, if we're gonna keep talking over and over again about this (which I think isn't a bad thing to do), let's make it more spicy. :)

Bindings to the native widget sets

[stab]

I'm currently working on porting a large, formerly commercial 3D application suite to be cross-platform (and GPLing it in the process). When it was initially written, it was a Win32 only program, and had a very good, stable interface in that platform.

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.

Re:Bindings to the native widget sets, wxwindows

[nuggz]

Why not just use wxwindows since that is pretty much what it does.

Fox

[Jinxx]

FOX looks promising. It's not quite at v1.0 but it's getting there. It runs on many UNIX platforms as well as windows. Unfortunatly it doesn't run on Macs but it is designed to be very portable, so with a little work...

Here is the URL: http://www.cfdrc.com/FOX/fox.html

Exerpt from the Forward:

• Ease of Development. Developing Graphical User Interfaces is a fairly complicated process. FOX reduces the burden on the developer significantly:

• Orthogonality. A few powerfull concepts that can be recombined in many intuitive ways is preferable to a hodge-podge of ad-hoc solutions. In a well designed orthogonal toolkit, the developer will be able to transfer knowledge gained from one scenario to another.

• Consistency. Consistent naming of member functions, consistent ordering of arguments and default parameters, as well as consistent behaviour of each Widget makes the system much more easy to learn.

• Conciseness. Every line of code not written is a correct one. So minimizing the number of lines of code to accomplish the job is a Good Thing. FOX helps with this by being able to create and initialize most Widgets with a single line of code. The C++ capability for default parameters to arguments is heavily used, and a lot of glue code to cement Widgets to each other is eliminated completely by the ability of FOX Widgets to send messages to each other.

. . .

• Platform Independence. Applications using FOX are not dependent directly on X-Windows. As all platform-dependencies are completely hidden from view by the FOX System (applications don't even include X-Windows header files!!), such applications will be easily ported to other platforms, simply by recompiling.

Java

[gcw22]

One word JAVA, that is what you are looking for and you can use JDBC to talk to your databases. I think it would be a waste of time to mess around with any other platform or combination of platforms that are not truely hardware independent.

Because QT doesn't support Mac

[Ur@eus]

If you read the original post, he said that their app was for the Mac. I don't think they would want to leave their current customers behind.

Re:Bindings to the native widget sets, wxwindows

[stab]

Two fairly minor things - it's written in C++, and the rest of our suite is in C, so integration is a bit of a pain, and also since ours is a 3D application, our set has more of an emphasis on graphics handles.

That, and the fact that it's kinda cool to give it a shot ourselves :-)

Hmm, although looking at the website, it looks remarkably good ... thanks for the pointer, I hadnt really looked at it seriously before, but it looks very interesting.

Java is a platform, not platform independent

[goingware]

Java is not platform independent, rather it is a platform in itself, which happens to run on many machines.

Just try taking advantage of platform-specific features from a Java program, or making a Java program work in a way that is expected by the users of native programs on each machine you might try to run it on.

Bjarne Stroustrup, inventor of C++, has much the same opinion in his statement about Java in his FAQ

.

Shameless plug

[Fluffy]

I just can't pass up the opportunity to plug my very own toolkit, ftTK. ftTK was my senior thesis, a library with intended support for Xlib, Win32, and Mac OS, as well as anything else I feel like adding later. Unfortunately, ftTK is currently pretty much useless, since it doesn't yet handle user input in any sort of consistent way, and many, many other things are still non-existant. Someday....

wheelm... er crossplatform

[tsikora]

As long as Windohs is not one of them! Damn this wheelmouse xx!!xx00.

use native apis

[edwarddes]

making the i cross platforn is evil! it then makes it hard for users of all oses to use. you should learn the native apis or hire someone who knows them and follow the human interface guidelines(if there ate any for windoze).

Re:Tcl/Tk is a solid, cross-platform free GUI tool

[Anonymous Coward]

I have to agree with this poster. I have used Tcl/Tk on cross platform projects in the past and it really does work. Lots of people can throw things like "you could try running gtk on Windows", but lets face it that is not the way to port a real applicaiton. Tcl/Tk works today, no porting needed to run your code on Linux, Windows, and the Mac. In fact, no compiling is needed as Tcl/Tk is a scripting language + a GUI. It is much easier than writing a GUI with a compiled language.

javangelism

[sohp]

Rich GUI front end. Java. Database backend. Java (in spades -- it's very good for this). RAD. Java, Pick any of a half dozen. Platform independence. Java. Your rfp didn't mention any other requirements, why look at any other options?

Re:javangelism

[sohp]

I learned so much about the current state and future of the Java language and platform at JavaOne I can now spot those who speak from ignorance in 7 words or less.

Why cross-platform toolkits are inherently evil.

[jfrisby]

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

Is that what "cross-platform" means?

[kaphka]

Every single motion, action, etc. was exactly the same across the two platforms.

IMHO, that's exactly what you want to avoid when you're designing a "cross-platform" app. The point isn't to make the app look identical on many different machines... the point is to make it look native on many different machines. It should use the native widgets, common dialogs, and interface metaphors, even if that means that the shortcut keys or window layout are totally different on different machines.

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.

Re:Is that what "cross-platform" means?

[BobLenon]

Ahh... true, to a point. But why does everyone say that linux wont make it? Inconsitancies in user interafaces, barring ye ole shell. Yes its important to seem native, yet at the same time this can be costly.

Look at Java, awt and swing. They're the most platform-indepent toolkits right now. Yet look at all the problems there were with AWT, i could create a FooWizBangBar widget in Windows, but couldn't under MacOS because MacOS didn't nativley support it. That would mean i'd need to take this platform independt code, and make it extermly OS typed. Swing however attempts to address this problem. Such is the case with Mozilla.

Widgets are based at the abstract layer, so i can create FooWizBangBar in any OS, wether or not it nativley supports it. And if I'm really concerned with the L&F, then I can use skins for each OS, that makes the App look native.

Besides all basic functions are the same in any OS... buttons, text fields ect. And you never know when someone might need to use a differnet OS for work ... if the apps they need to use are identical on both platforms, there is no new learning curve.

Re:Is that what "cross-platform" means?

[0xdeadbeef]

So rather take responsibility for the interface of your programs, you delegate it to the designer of the windowing system? What if you believe they are abusing the users? (It vaz not my vault, I vaz zuzt vollowing orderz... )

It probably harder to maintain complete consistency in the interface across platforms. I can hardly imagine the pain it must have been to implement those fancy button bars in netscape under X so that they work like they do in windows. I miss those big blocky Motif buttons, but you know, it is actually nice having the same interface in both platforms. If only the key-combinations were the same!

I really don't give a hoot about the conventions of the operating system, what I want are coventions in the applications I use in different environments. What is more important, the application or the OS? Are you really on the user's side, or the OS vendor's?

The ideal should be a form of global theming (for lack of a better word), where the set of default behaviors of a system is customizable, where customizations apply across the board, so in effect, I can have all my programs work the same no matter what the underlying architecture is. The users can pick what metaphors suit them without being constrained by the ideological bent of the GUI designer. Something along the lines of OOUI mentioned in a previous thread.

Re:Is that what "cross-platform" means?

[mr3038]

Making a program look identical on different platforms is a popular form of user abuse.

I don't agree. Making program look identical and feel different is user abuse. Think about netscape - how many times you have tried to press ctrl-d/alt-k to bookmark page or pressed middle button to open link in new window? If program looks identical it should work that way also. If program doesn't follow general guidelines of OS it doesn't matter that much - again think about MSIE3 or MSIE4 when it came out. It was quite different from anything else in that time. Think about ICQ or 3DSMax. Taking QuickTime as an example is like taking some poor shareware program as an example. If UI sucks in any platform copying it to another as identical won't make it great neither. On the other hand if UI is really slick on one platform it will be that also in some another platform - even if all the other programs in that another platform sucked. If no program ever differs from UI convention of any given platform GUI never advances.

But in some cases it does matter if program follows GUI guidelines (for example when browser is integrated as file manager) and therefore I would like to see more programs like mozilla where not only looks change with themes but also feel. For example if I could change that floating QuickTime menubar under windows to bright green (or change that brushed steel look to plain one color) with some theme wouldn't help much. On the other hand if some theme could attach that menubar to main window would help a lot no matter how ugly it would the looks make.

I would love to see each copy Mozilla with default themes of *n*x, Win and Mac and you could select any one no matter which platform you currently were using. That way user could select use mozilla with convetional UI or UI (s)he is used to.
_________________________

One word...

[oopsatwork]

PowerBuilder Unix, Windows, Macintosh...use as a front end...or the whole damn application.

Cross Platform GUI Toolkits

[Koder]

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. Dude, fergit it. Your app needs a doofus very thin client front end. Let it talk to the the DB in the backend most indirectly. Eschew databound fields at all costs. The less that you put in the UI, the easier it is to cross platforms. Don't believe - check out stuff that promised this in the past, like Rogue Wave's Zap. 'Member LCD = Lowest Common Denomiator? that's what you're trying to reach when you make a cross platform UI. FWIW, Koder

fast light toolkit

[timmyd]

http://www.fltk.org/.

here is a description from the FAQ:

What is FLTK?

FLTK (pronounced "fulltick") is a LGPL'd C++ graphical user interface toolkit for X (UNIX®), OpenGL, and WIN32 (Microsoft® Windows® NT 4.0, 95, or 98). It is currently maintained by a small group of developers across the world with a central repository in the US.

How is FLTK Licensed?

FLTK comes with complete free source code. FLTK is available under the terms of the GNU Library General Public License. Contrary to popular belief, it can be used in commercial software! (Even Bill Gates could use it.)

Re:GLUI performance

[ChadN]

Well, it sounds like it suffers from a maturity problem, but surely it is a nice idea, and could probably benefit from some active use and testing.

However, like I said, the author seems to be out of touch at the moment. I'm personally interested in pursuing additional development on the base code, if the original author is no longer able to.

Stay away from Tk

[redbird]

Whatever one does, stay away from Tk on the Mac. Even though the implimentation is getting better, it is still pretty bad and has all sorts of weird stuff in it. Trust me, don't go anywhere near it.

Take a look at WebObjects and Java Client

[plsuh]

Apple's WebObjects with Java Client technology may be exactly what you are looking for. WebObjects has a cross-platform server, (Mac OS X Server, WinNT, Solaris, HP-UX -- pure Java including Linux in the next version) plus a technology called Java Client, which allows you to instantiate a thick-client Java applet or application that can run on any Java 1.1.x platform, including MacOS/MRJ, Windows (various flavors), Solaris, Linux, or anything else which has the Swing 1.1.1 package available.

To expand a bit on this, WebObjects incorporates a technology called Enterprise Objects Framework (EOF). This is an object model-based way of interacting with your database. Rows in the database become translated into Java or Objective-C objects, which you can then message. Joins between rows in different tables in the database become pointer references between different objects. As a programmer, you never have to write a single line of SQL code; all SQL interaction with the database is generated on the fly for you by EOF as you work with your object model. I can personally attest that this can be a huge win for maintainability.

The Java Client part of this comes into play by extending the reach of EOF into a Java application running on the client machine. The Java Client app can request Enterprise Objects from the WebObjects server, and work with them transparently. You can code business logic into the EO's either on the server or on the client, depending on your requirements for security and interactivity.

Just to make it clear, I am a Consulting Engineer for Apple iServices, and an employee of Apple. This technology is my livelihood, and I know it well. That being said, I have also done Web development in Microsoft Active Server Pages and Perl cgi's, and I firmly believe that the WebObjects is a vastly more capable development environment than either of the two.

Also, don't forget that Apple has just slashed the price of WebObjects from $50,000 to $699; it's now also quite affordable.


--Paul

FLTK is cross platform.

[Anonymous Coward]

You can find it here:
http://www.fltk.org/
It's about as cross platform as they get.

Trying to answer the original question...

[Zraknylar]

As usual, this thread has wandered pretty far from the original topic, which is a shame considering that this is a fairly important issue for a lot of people. I do actually have a little experience in this area, so here's what I know that might help:

wxWindows: If you're going to stick to a C++ cross-platform application framework, I honestly believe this is the best option. Most people don't seem to pay much attention to it, and many of those who have were burned by bugs in earlier versions, but it's really starting to come together in terms of both stability and functionality. I ported early code for a pretty complex program from MFC to wxWindows within 2 months, which impressed me considering that I wasn't familiar with either toolkit and that was my first real use of C++. I'm now doing a bit of work with wxPython, which is also going pretty well. The Mac port development tends to lag a bit behind the others, but it has been (and is being) used to deliver several commercial products, so it seems to be in usable condition; I haven't had a chance to test it myself yet. By all means, please carefully consider this option; it seems to be the most capable framework of it's type currently out there, has a respectable number of users and developers, and will get even better with more support.

CPLAT: Afraid I can't say anything as positive about this one; the MFC project I mentioned above was itself a port from CPLAT. After 2 months of development with CPLAT (ending January 2000), the developers unanimously agreed that the framework was so buggy that it would be faster to write separate versions of the program for MFC and PowerPlant. I believe there is only one developer on the project; that simply isn't enough resources to properly handle a framework of this magnitude.

Whisper: We looked at this one also, but it didn't have enough of the features we were looking for to be worth trying. It also looked to be, like CPLAT, a one-man effort.

YAAF: Another one we passed over after a brief glance. The web site didn't have much information, and I don't see any indication that it's being used much. I may have short-changed it, but I just don't see enough activity around it to indicate a really good product.

GLUI: I haven't used this or looked too closely at it yet. The lack of native widgets bothers me, though...

Carbonless Copies: Hadn't heard of this before. The web site given above hasn't been updated in a while, I haven't heard of many people using it, and it's a proprietary program; I'd be inclined to avoid it.

Regarding some of the other options people have suggested:

Java: While useful for some purposes, cross-platform GUIs arguably isn't one of them. It's relatively easy to get a Java GUI program to work cross-platform, but practically impossible to get it to work well. AWT lacks major functionality. Swing is buggy and a *massive* memory hog; don't even think about running Swing apps on computers with 32 MB of RAM, and they're not terribly happy even with 64 MB. And Java in general is lagging far behind on the Mac. Finally, it is a proprietary platform complete with all of the problems that entails. I used to really like Java, but not much progress has been made at solving some of it's critical deficiencies. I'm now hoping Python can take it's place...

Mozilla: Mozilla is useful, but it's deficiencies have been noted above; lack of native widgets, slow response time to user input, etc. I look forward to using this for some projects, but it isn't going to replace the need for a cross-platform C++ application framework.

GTK+: Doesn't work on the Mac, and won't for some time to come. Doesn't use native widgets on Windows, either (to my admittedly limited knowledge.) I agree with the wxWindows approach; use GTK+ on Windows, use the Windows API on Windows, and use the MacOS API on the Mac.

Qt: Again, doesn't work on the Mac and doesn't use native widgets on Windows.

Tk: Doesn't have native look and feel, and last I checked has some issues on MacOS. I've also gotten the impression that the widget selection isn't as rich as that of wxWindows, although I haven't looked at it closely enough to judge for myself.

On the topic of RAD tools; wxWindows does not yet have a usable RAD tool, although the wxStudio IDE is under development and there is a working dialog and panel editor. wxPython has the Boa Constructor IDE which seems to be almost in usable condition; it could also be argued that compared to using C++, even manually writing Python code practically *is* a RAD environment.

Hope this successfully addresses some of the issues, and hope it isn't buried so far down in the responses that it never gets noticed...

HTML/GUI

[adnt]

I think we have need for cross-platform GUI toolkits, whose also offer web-browsers and smaller devices such as portable phones as interface options in addition to just traditional Windows, Mac, ...

Currently the best way to do that is to try to separate application from UI and to build different frontends. I sure hope we're going to get such a toolkits in near future.

Of course if you're targetting to native GUI sets and HTML and such, the descriptions of the UI should be more higher-level than in most applications, maybe containing some hints which is the preferred way to get the functionality.

Bad thing is that I don't know any toolkit this sophisticated. Maybe XUL and a set of parsers for it or something is the way to go to implement this.

Java has some nice points

[mlgm]

I'd recommend using Java and I believe there are lots of advantages:

Portability
===========

Often discussed but actually quite good. Try using two virtual machines (e.g. Sun and IBM) during development and I believe you will easily find most portability issues. In my experience those issues most of the time are only minor differences like the following: a method defined as returning an Object[] might in the case of an empty array return a null pointer or an empty array. You can work around this easily and write a portable program [if (result == null || result.length == 0)].

Support
=======

You can get virtual machines or programming tools from various sources and there is lots of documentation, literature, classes, etc. This is not available for most small cross platform toolkits.

Nice language
=============

You might argue about this, but I like Java as a language. In my experience most of the things you might imagine are possible without major hacks (at least most things I can imagine :-).

Speed
=====

If you're not into 3D game programming or do have extreme wishes (as supporting 66MHz 486), I believe that speed isn't much of an issue any more and I have three reasons: first, todays hardware is rather fast. Today you hardly can buy a machine with less than 500MHz. Second virtual machines get faster with compilation techniques, etc.

But I believe my third point is an important one: even though modern GUIs work event driven and mostly react on events, Java gives you the oportunity to design software in a way that can use the processor cycles between user interactions (and normally there goes a lot of CPU power unused - at least outside of action gaming).

You can easily create background threads which already prepare dialogues which will be used in the future. Of course you have to change your application design to a multi-threaded architecture.

Dynamic layout
==============

One of the things I like most with Java and AWT/Swing as a GUI is the possibility of layout management. Your program can create layouts on the fly. This supports a more generic programming. Try yourself how easy it is to create a nice layout without pixel calculation and how easy you can have your dialogues generated by a program.

If you were a potato...

[Potatoswatter]

No, I would swat you.

Ramble on!
mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0

Gtk-Mac

[deeny]

Not to toot Arnaud's horn too much (I had the idea, so far he's done the work), but he should be posting stuff to:

http://gtk-mac.sourceforge.net/

Really soon. This will make Gtk cross-platform on everything that counts. :)

_Deirdre

Past Ask Slashdot articles

[NYC]

This Ask Slashdot did seem familiar, so I looked at some past topics. Two of them seem on-topic.

What is the Best GUI Framework?

Cross-Platform Development Tools?

Both of those articles did not specifically address cross-platform and GUIs, but many of the responses did.

--weenie NT4 user: bite me!

Re: Gui design tools

[spider]

See also Macbird,

http://sourceforge.net/project/?group_id=1101
http://macbird.userland.com/

Mac only, now, but Open Source (MIT license)

Smalltalk!

[tauzell]

Actually, there is something that's pretty good. Smalltalk. VisualWorks (by ParcPlace) supports MacOS, Windows, Linux, Solaris and HP.

VisualWorks has a RAD environment, database access (an OO-Relational framework).

It's been around for years and is very mature.

The downside, of course, is that you need to know and be willing to support Smalltalk.

Have you considered UIML

[Pilchie]

My Company has been considering UIML. UIML is an XML dialect, designed for specifying interfaces for multiple different platforms, machines, etc. It is then either compiled to native code, or loaded at run time and interpreted. Similar to libglade, and such, but potentially much more powerful.

Potential drawbacks are that it is still young, and may not develop enough momentum to carry on. Also at the moment there is only one Renderer, which is java based. What we have been doing is rendering the gui in Java/AWT and then using JNI to call our existing C++ code. It has been working fairly well, although I wish the renderer offered more complete support for the spec.

All in all though, I think it is a good way to go.

>~~~~~~~~~~~~~~~~

Re:Asynchronous communications???

[alienmole]

You got it - a Java applet that uses HTTP, to avoid problems with firewalls. It's easy enough, since standard Java has the URLConnection class which works fine, if you don't need HTTPS support.

Re:Asynchronous communications???

[alienmole]

We use standard Java, in the form of the java.net.URLConnection class, which does all the work of making an HTTP connection with the server and retrieving data - very little code is involved.

Sun has an example which uses URLConnection.

Another useful tool we use is IBM's XML4J, now part of the Apache project. There are a number of useful Java, XML and other tools at the same site (alphaWorks), it's worth browsing around.

Finally, here's the XML-related Apache site.