Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Cross-Platform GUI Toolkits? 126

Posted by Cliff from the marginalizing-the-OS dept.
rrwood asks: "The company at which I work is about to overhaul an existing application. Strangely enough, we're primarily Macintosh-based, but are casting an eye towards cross-platform development (i.e. Windows, though I'm hopeful that an X/Linux-based version is also a possibility). Given that the app is to be a fairly rich GUI front end that talks to a database backend, I'd be interested in hearing any recommendations or advice anyone out there has to offer." Read on for more information on the toolkits currently under consideration (feel free to offer more suggestions), but we are talking toolkits here. The topic of cross-platform languages got a rather thourough treatment in a previous article.

"It's pretty much a necessity for the solution technology to include a RAD tool.

With respect to using a portable C++ core and platform-specific GUI layer (or even portable GUI layer-- keep reading), there are a few toolkits around that seem promising:

  • GLUI, an OpenGL-based GUI
  • Whisper, a Mac/Windows application framework
  • WxWindows, a framework which supports Windows 3.1/95/98/NT, and Unix with GTK/Motif/Lesstif, and MacOS
  • YAAF, Yet Another Application Framework, offering suport for Macintosh OS, Windows 95 and Windows NT, and X Windows
  • CPLAT, a framework for developing MacOS and Windows (Linux soon) applications
  • Ardi's Carbonless Copies technology, which is a portable rewrite of much of the MacOS API
Additionally, these URLS have a lot of info on Platform Independent GUIs:
This discussion has been archived. No new comments can be posted.

Cross-Platform GUI Toolkits? More

Cross-Platform GUI Toolkits?

Comments Filter:

  • Again? (Score:3)

    by Dr. Sp0ng ( 24354 ) <mspongNO@SPAMgmail.com> on Saturday June 10, 2000 @09:04AM (#1011525) Homepage
    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 :-)
    --
  • 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 =)

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

  • GTK ? (Score:2)

    by HomerJ ( 11142 )
    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.
  • 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
  • Basic? I think they're trying to sell this...

    -jpowers

  • Re:Again? (Score:1)

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

  • Good Detailed Overview (Score:4)

    by N8F8 ( 4562 ) on Saturday June 10, 2000 @09:19AM (#1011532)

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

  • 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 (Score:4)

    by BobLenon ( 67838 ) on Saturday June 10, 2000 @09:21AM (#1011534) Homepage

    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:why not try QT2.1 and KDE (Score:1)

    by Anonymous Coward
    Qt doesn't support MacOS.
  • 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 [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.

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

  • Tcl/TK and Perl/TK (Score:2)

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

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

  • 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 (Score:3)

    by sanguish ( 130391 ) on Saturday June 10, 2000 @09:31AM (#1011542) Homepage
    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/ [stepwise.com]

  • I have been playing with V gui [objectcentral.com] 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 (Score:1)

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

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

  • I've looked into this too. The toolkit I am leaning towards is V [objectcentral.com], located at http://www.objectcentral.com [objectcentral.com]. Well supported, and is under continous development.
  • 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).
  • Is Motif available for Windows?
  • 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
  • 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.

  • 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).
  • 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.
  • 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!
  • 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.
  • 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.
    --
  • 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.
  • Then use emacs as your front end!
    ___
  • 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/

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

  • (D)HTML + XML (Score:5)

    by alienmole ( 15522 ) on Saturday June 10, 2000 @10:02AM (#1011560)
    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.
  • 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
  • There is a GTK+ for MacOS [sourceforge.net] project on sourceforge.net, but like many other projects it appears to be stuck in the "wishful thinking" phase.
  • 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.


  • 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.
  • 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.
  • 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 :-)
  • Thanks for the link :)

  • Cross-platform APIs from a Mac OS perspective (Score:5)

    by nanouk ( 189974 ) on Saturday June 10, 2000 @10:38AM (#1011568)
    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 [mailto] 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 [apple.com], which is now a part of Apple's WebObjects product.

    Handy-dandy URLs
    Mac OS X Developer Documentation [apple.com]
    GNUStep, a free implementation of the OPENSTEP spec. [gnustep.org]
    Java 2 Documentation [sun.com]

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

  • VisualWorks (Score:3)

    by Ken Treis ( 90058 ) on Saturday June 10, 2000 @10:52AM (#1011573) Homepage
    You'd be hard pressed to find a much more portable GUI building toolkit than VisualWorks Smalltalk [cincom.com] 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 [parcplace.com] 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 [signalground.com]

  • OOUI (Score:5)

    by jesser ( 77961 ) on Saturday June 10, 2000 @10:57AM (#1011574) Homepage Journal
    Ben Bucksch [bucksch.org] (who also works on mozilla [mozilla.org]) has started a project he calls OOUI [bucksch.org]. 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 [bucksch.org] 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 [bucksch.org])

    --

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

  • Seriously! (Score:3)

    by luge ( 4808 ) <slashdot&tieguy,org> on Saturday June 10, 2000 @11:00AM (#1011576) Homepage
    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.
  • 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. :)
  • 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.
  • 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.
  • 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).

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

  • Xlib (Score:1)

    by Mathieu Lu ( 69 )
    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. :)
  • 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.

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

  • Bindings to the native widget sets (Score:4)

    by stab ( 26928 ) on Saturday June 10, 2000 @11:54AM (#1011587) Homepage
    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.

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

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

  • 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:GTK ? (Score:2)

    by mvw ( 2916 )
    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 [gimp.org].
    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. :)

  • 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 [talla.de], 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 [siemens.com].

    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.

  • I think Forte for Java, Community Edition [sun.com] is a good option, but people might also want to take a look at the JBuilder Foundation, Community Edition [borland.com].
  • Why not just use wxwindows since that is pretty much what it does.

  • Fox (Score:2)

    by Jinxx ( 104687 )
    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 [cfdrc.com]

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

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

  • Java (Score:1)

    by gcw22 ( 140334 )
    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.
  • 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

  • Re:OOUI (Score:2)

    by mvw ( 2916 )
    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.

  • 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.
  • 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 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 [att.com]

    .

  • I just can't pass up the opportunity to plug my very own toolkit, ftTK [simons-rock.edu]. ftTK was my senior thesis [simons-rock.edu], 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....
  • 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 [w3.org] 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.

  • 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+.
  • As long as Windohs is not one of them! Damn this wheelmouse xx!!xx00.
  • 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).
  • 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.
  • 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.
  • ... 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.


    --

  • 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.
  • 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.
  • 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?
  • 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
  • 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.
  • There is also GTK for Windows. /i

    Horribly slow. At least GIMP is.
  • PowerBuilder Unix, Windows, Macintosh...use as a front end...or the whole damn application.
  • 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
  • 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.)

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

  • 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/ [sourceforge.net]

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

    _Deirdre

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

  • My Company has been considering UIML [uiml.org]. 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.


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

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close