Slashdot Mirror

FWIW, FLTK provides the same advantages as Qt but is provided under the LGPL and is a lot smaller and faster.

The 2.0 release (currently in development) will take us beyond what most of the current toolkits can do, and is the basis of the Equinox Desktop Environment. At the same time, 2.0 retains the same goal of small size, high speed, and portability/cross-platform programming.

While I'm not officially responsible for the build process at my workplace, I've taken that responsibility as we've been porting our code to a new operating system. Here are some things we've learned that may help you.

We recently switched from Make as our build tool to Jam which has worked great. Like you, we didn't have the option of using GCC on every platform, and Jam made it easy to configure all the operating systems we're interested in using with the fewest headaches. After using Jam for quite a while now, I think all of the developers and I are very happy with the decision to axe Make. Honestly, I can sympathize with your effort to use Make to do all your compiling since we gave it some effort before switching to Jam. Try Jam - you'll be amazed at how much simpler your build process becomes.

Whether or not you use Jam (though we use Jam to do this), setting up nightly builds, capturing the output, and sending status emails with the results makes bug finding much simpler, especially on multiple platforms. Part of the nightly builds include built in testing. If any of the tests fail, we know we've broken something in our code.

Another suggestion... Look for a threading wrapper package like CommonC++ or ZThreads. Both are fairly well developed now and make programming multithreaded applications for multiple platforms pretty easy. For multiplatform GUI tools, try FLTK. It's tiny compared to WxWindows or other bloated GUI wrappers, plus it's easy to use.

wxWindows is pretty heavy weight compared to Qt, FLTK, FOX, etc., and the other toolkits (with the exception of Qt) are totally open-sourced with "designer" apps.

We shied away from wxWindows several years ago because of binary compatibility issues (in the vendor GUI libraries, not in WxWindows) and because of the bloat. I'd be interested to see how wxEmbedded measures up...

Huh? How is Troll Tech evil? People wanted QT under the GPL, and lo and behold, they released it under the GPL. Seems like a nice bunch of folks to me.

Not quite. People really wanted it under the LGPL or BSD licenses, just like GTK+, FLTK, FOX, wxWindows, etc.

One of the problems (unless you follow Stallman's manifesto) is that although the Free version is free for open-source, their commercial licenses are structured so that if at any point in time your software project is touched by a free (free, non-commercial, acedemic, etc) version of Qt, you may never at any later time buy a commercial license and release your software commercially.

It's much simpler to program than ANY other toolkit (yes, Qt included); It doesn't cover as much but it tends to be sufficient for 99% of the programs. It works on Win32, X, MacOS and easy to port to other systems. Did I mention it's open source? It also has an extremely well written manual, and tens of concise, useful example programs.

And ... there's an included checkers program with full source that you can consult, as the GUI for chess and checkers is similar. Go on, download, compile and check it out; then look at the "possible moves" and "rank moves" display, and tell me if you can do it elegantly with that simplicity and without flickering in any other toolkit.

FLTK website

Ant they are using my favorite FLTK toolkit for new stuff!

Operating systems have so much material available because there's science involved - there are a few things that can be proved (e.g., shortest job first, lock-free / wait-free synchronziation primitives, Belady's FIFO anomaly) which should be known to everyone starting to practice. There is also a considerable accumulated body of knowledge which, though not based on solid math, has reached a "common knowledge" status.

The same cannot be said about windowing systems. The algorithms are well documented, but there isn't much connection between them and actually building a windowing system. Building a windowing system is an art more than science or engineering - a system that's a masterpiece to one is considered bad practice by another.

That said, if you want to learn from a system IMO exceptionally well balanced between doing things cleanly and making them work, take a look at FLTK (pronounced FullTick) - it revolves around the ridiculous and totally unaccepted idea that the GUI is only an aspect of your program, and that the logic of the program should not be influenced by how the GUI is implemented. How silly. (Yep, I know, SDNWOTN).

Both Gtk and Qt look bloated when compared with FLTK. It is LGPL so it can also be used to build commerical applications without additional licensing. Qt on the other hand is GPL for free or commerical license for purchase. And FLTK is a true C++ UI like Qt.

FLTK is very lightweight and easy to use. It is used extensively on handheld Linux devices. FLTK1 lacks some functionality that you may need, but FLTK2 is shaping up to be quite complete.

Also, Qt is not the only game in town for commercial toolkits. If you want something commercial, look around. In the past, other commercial toolkits had much better tool support than Qt.

GTK:
GTK

QT:
QT
Excellent QT Tutorial

wxWindows:
wxWindows
wxPython

Mozilla:
Mozilla
Cross-platform implementation of COM
develop your UI's in an XML dialect called XUL

Others:
FLTK
Fox Toolkit

Side-by-side comparison of GUI Toolkits:
The GUI Toolkit and Framework Page

I needed this list for my own use. Maybe it will be of interest to you.

The FLTK web site is http://www.fltk.org/.

Both libraries you mentioned have their disadvantages (one isn't always free and isn't normal C++, the other doesn't exactly have the best windoze support), but IMHO, FLTK and FOX both seem to avoid these pitfalls. Both support windoze and unixy platforms with X. FOX is capable of doing more things, but FLTK is as fast a heck.

Geez. Talk about flamebait topic. Personally (and personal opinion only, here), I'd say, Qt is better designed, clearer, and easier from a programming standpoint - but it's actually not clean C++, what with its dodgy signals/slots stuff, that gtk-- manages to do within the bounds of the language.

If you're writing commercial, proprietary software, then you have to pay to use Qt - but Trolltech provide a thoroughly professionally supported toolkit to you for your money.

The Qt class library is actually more akin to the standard set of Java classes than just a widget set - there's decent cross-platform support for sockets, xml, threads, unicode, etc. It really makes C++ programming very easy.

OF course, there's other cross-platform C++ tollkits like FLTK... The gui toolkit page lists many more.

You are so right. I've been programming java on and off for 6 years (on again at the moment, server side, marketing decision...)

My main problem with java is not the speed of execution (although that's still a problem). It's the ton's of superfluous shitty code that seems to get generated in any java project.

The flaws you mention aren't even the main ones IMHO - lack of MI (no, interfaces are *not* as good, eg EJB programming wouldn't be quite so cumbersome if the methods one needed to overload had default implementations) and templates is even more irritating. Then there is the stupid overuse of try/catch blocks because the style encourages this, leads to local error handling code all over the place and defeats the whole purpose of exception. The lack of enums is unforgivable too, aargh... And then Swing - good god, what a piece of shit. Try FLTK instead, to reduce code size by factor of 4 and increase speed by factor of 100.

Glad I'm not the only one who feels this way..

You don't need Qt to "develop for KDE". Lots of other Xlib toolkits work just fine (I can plug the one I am working on, fltk which is LGPL and totally free for commercial use). Yes they lack some of the stuff that Qt has, so you need to decide if it is worth $2K to get those extra features...

I was originally going to post something negative here, but as I read the article, I came across this article on what Century Software has done working with the distro from handhelds.org. And other open software, like FLTK. FLTK is a neat tool kit that uses OpenGL as its window renderer, and pretty much works on any os that has OpenGL libraries.

I was impressed enough to revise my original opinion of Linux on a PDA. Which was the thought that it is neat to run Linux on a PDA, but why bother? I use a PDA to sync my calendar and emails. Everytime msoft changes express or whatever, the linux equivelants are broken, so why fight it?

But in reading what Century has done, well, it hasn't changed that opinion, but their package is cool enough that it makes me want to install it on my Ipaq anyway.

There's nothing wrong with Motif. It has been designed from scratch to be extensible and it can still get improvements over years.
I've written Motif, QT, Gtk, Photon (QNX) and Fltk apps. They all work the same way. The basic widgets are the same, and when you've learn how to code one, you can easily move to another one. They all work on a hierarchical component model, with inheritable attributes, and an event-based system.
For some apps, especially those who are dynamically building widgets, QT and GTK are easier to program. And libglade is something worth to look at. It goes one step further than other toolkits, because an user can build his own interface for any compliant app, not only customize an existing one with themes or colors. For widgets with dynamic content (lists, panes), Photon (on QNX) beats them all. It's easy to code, smooth and damn fast.
The only problem with Motif IMHO is that it eats up a lot of memory. Especially when you are using nested scrolling panes. Properly using widgets and gadgets can reduce the memory footprint, but it's always huge. It's not the size of the Motif library itself, but the amount of dynamic memory it requires for itself and from the X server. I can't run more than 3 or 4 different Motif apps at the same time without running out of memory (128 Mb) . Other toolkits don't seem to need so much memory, even with complex themes.
The FLTK toolkit isn't very popular. But it's really a very good one. It's LGPL'ed, and it has X, OpenGL and Windows backends. It's fast and lightweight. And it has many similarities with QT. If you want to write an applications with basic widgets in C++, try FLTK before QT. It's not easier to code, but your apps will run faster (at least the GUI part) . FLTK also comes with FLUID, an efficient interface builder.

Unfortunately DD decided to go closed source and no more of their tools were open sourced but the original idea behind FLTK was to provide a GUI toolkit to be used in movie-effect software. Now, it's come a long ways and is a much more generalized toolkit but it was the general idea behind it.

This is a bit off topic, but it's related because it was a Linux GPL'd toolkit that started for doing mainstream 3d effects on unix platforms (Cheap linux boxes, if I recall titanics render farms correctly). Blatant plug for a cool project...

Here you can find all the information you need to hack your VR3:

http://developer.agendacomputing.com/

One design flaw (IMHO) is that all of the user applications on the machine are written in C++, due to the embedded design of the software.. C may have reduced the footprint required to "push" the applications, but that is my opinion..you don't have to agree :)

The graphics toolkit (C++) they are using is very cross platform, perhaps they decided to use it incase they would later decide to move to WinCE?? It is called FLTK. The machine itself runs XFree86, so all of your existing X11 applications should run fine; although the screensize may be a little limiting.

This platform just needs optimizations, they are using very open technologies and opened it up to developers, infact.. most of the software is already on most linux machines!

As far as the WindowManager is concerned, it is FLWM.. of course based on this high-level graphics library. For speed's sake, there are definately much "lighter" windowmanagers out there! A modification of RatPoison or ION would be perfect for this device, much cleaner.. faster..

It shouldn't take much to make this a much faster machine, just remove all the applications shipped with it! :) Theys guys didn't really know what they were doing on the speed-side but they did make a good peice of hardware.

If I get the money, i'm buying one!

Is it running X?

Yes, it's running X. About a week and a half ago I began writing a simple game for the Agenda from scratch (you may have seen it mentioned on LinuxGames.com and the Linux Game Tome.

I'm practically done. It was incredibly easy. Developing it on the PC end wasn't hard (I obviously had some experience coding X apps), and making what I wrote run on the Agenda was a matter of using a cross-compiler.

Porting Atari800 has proven quite easy, as well. I had it cross compiled and up and running (albeit slowly) on the Agenda in less than a half an hour.

Of course, if you want to stick to the "standard look and feel" of applications already written for the Agenda, the tool to use is FLTK (Fast/Light Toolkit).

It's a C++ lib, though. :^/

1. Many toolkits aren't resolution independant and don't scale gracefully.

2. GTK can be liquid and slightly resolution independent for the simple UI widgets - but it's really still based around pixels and you can't scale tewers in any such way without breaking. BeOS's toolkit is heavily pixel based (try increasing widget sizes and watch even the preinstalled software break!).

3. Qt is a little better. Java's Swing is quite good for this type of thing, too.

4. If you don't mind the Motif'ish look try Fulltick.

5. I like number 5.

-- Eat your greens or I'll hit you!

It's not shipping yet, but the Agenda looks sweet. it runs MIPS Linux (2.4-test), X11, and FLTK for GUI. The software including GUI is entirely open source and they have cross-compilers of gcc and g++.

The problem is that the exact words of the LGPL seem to require dynamic linking of my library, so that it can be "replaced by the user". This imho is unacceptable, since my library is not popular and thus must be provided with the appliacation. This requires the application to be "installed", which greatly reduces it's ease of use. Perhaps more important: it means a programmer cannot modify my library (releasing the code modifications) and use it in their closed program, since the shared library would conflict with other users of my library, this completely defeats one of the main advantages of Open Source, which is that you can change it!

I have taken to adding a disclaimer that says "static linking of my library is allowed, no matter what the LGPL says, and is in fact even encouraged". But I would like to know if there is any better way, or if the LGPL allows this.

I would prefer not to make my own license just because of this, since we have way too many licenses as is, but this worries me no end...

Agenda Computing uses Linux 2.4.0-test, X11, and the lesser-known FLTK, or "Fast Light Toolkit" (backronym), which is a C++ OO framework. Very cool.

That's fundamentally different from using GPL'ed software like gcc. If you start developing using gcc, your software doesn't automatically become GPL'ed and you can always switch to any of a number of other vendors.

With KDE/Qt, if you start developing for it, you are for practical purposes tied to the library and the company. If you ever want to make a commercial version of your software, you must license from that vendor and pay whatever they ask.

Choosing a complex library that falls under the GPL is a big step that you need to consider very carefully, since it closes off most of your options later on. My recommendation would be to stay away from KDE/Qt development, as well as from any library portions of Gnome/GTK that are covered by the GPL. Of course, there is no problem with using GPL'ed software as applications or tools.

It's also unnecessary to make that kind of commitment to a GPL'ed library when it comes to GUI libraries. wxWindows is a very complete C++ interface to several different toolkits, including Win32 and GTK, and if anybody cares to, it could be adapted to a Qt backend as well. And FLTK is a nice, simple cross-platform GUI library, good for many applications and much easier to deploy than either GTK or Qt.

A few I've seen (but never used myself, mind you) are wxWindows, V and FLTK.

wxWindows still has some rough spots, but then so do almost all other toolkits. If you don't need quite as much functionality and can do without native LAF, FLTK is also pretty good and much smaller.

This daft window metaphore crap is largely responsible for reducing the most powerful invention of the previous century to just another time-wasting useless idiot-box where humanity's natural sloth and aversion for thought can reign supreme.

"A picture is worth a thousand words" - it's a myth. Draw me a picture of "love". The trouble with GUI interfaces is that they are predisposed towards the computer transfering information to the human. They are not an efficient mechanism for humans to transfer information to the computer. There is a good mechanism for this - one that has been used for millenia and which are brains have even evolved to use effectively. And that mechanism is language. This is why text based interfaces will always rule over this GUI shit. The "integrated" desktop is doomed to forever strive for the level of power, speed, simplicity and componentisation already provided by the shell tools.

Why use a metaphor for a work-style whose time has past (WIMP - "desktop") when the reality of the computer is orders of magnitude more powerful and more flexible. Even as programmers deny this, and preach the religion of GUIs they implicitly acknowledge that to do anything powerful, you need to use a language - a programming language.
"Oooh, but that's too complicated for my users..."

Am I saying that every computer user should be a programmer ? Yes I am, but only to the extent that it makes sense in the domain. For instance, any real power-user of autocad will write small lISP programs. How could a commerical company make a fully functional, mathematically pure programming language as the basis of an interface for a program intended for draftsmen ? Because they understood that stupidity is like work - it expands to fill the space allocated to it. Expect intelligence and you will receive it. Autocad dominated their market like this. This approach would work in other markets if programmers had the humility to admit that their "users" were as smart as they were, and deserved the same power that programmers reserve for themselves.

If I want to do GUI programming (which *is* good for computer->human interaction), I'll use fltk, a far more powerful and better designed toolkit than either Gnome or KDE. Plus it's cross platform, and LGPL. If I want to knit things together, I'll use a bloody pipe.

FLTK (Fast Light ToolKit) is available at http://www.fltk.org/
-- Floyd

Why not try fltk. Its small, fast, portable c++.

I like OpenGL for graphics and FLTK for GUI because they are cross-platform so that what they learn will be applicable no matter what system they program on.

-krish

Understanding is a lot like sex. It's got a practical purpose, but that's not why people do it normally.
----Frank Oppenheimer

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

Both Gtk and Motif are highly customizable. You'd be surprised how much better Motif apps can look if you mess around a bit with the resources, stopping it from thinking the menu font should be 18pts and buttons should be the size of Mount Everest. The same is true for Gtk, check out documentation on gtkrc.

The thing I dislike about Gtk is the API itself, which is the reason I use FLTK, which also helps keeping the tabs on memory overhead a bit better than the two mainstream linux toolkits at this time.

• Java 1.2. Technically, I think this is by far the best choice: easy to program, robust, extensive built-in APIs, etc. But you need to somehow get a Java 1.2 runtime onto your clients machines, and it still isn't efficient enough for number crunching (if that's part of your application).
• FLTK Small, cross-platform (Linux, Windows, ...), straightforward C++ GUI toolkit. You can link your applications statically and they are still small enough to distribute. It includes a GUI builder. Good OpenGL support. Has its on look-and-feel. Versions 1.x still lack drag-and-drop and dynamic widget layout support.
• wxWindows Very complete C++ GUI toolkit, cross platform between Linux, Windows, MacOS. Lots of widgets. Drag-and-drop support and dynamic layout. Uses platform look-and-feel. Very MFC-like, including the use of event tables for event routing. Steeper learning curve. GUI builder doesn't seem to be quite ready yet.
• Qt Commercial toolkit. Pretty good quality. But you need an expensive, per-developer license unless you do open source. I don't think it's worth the money or hassle compared to wxWindows.
• Willows Supoprts genuine Windows programming on Linux, in an open source environment. (I haven't looked much into how complete it is because I don't actually like genuine Windows programming :-)
• GTK There is a Windows port as well as C++ bindings. I don't think the Windows port is far enough along yet for deployment, though.
• Tcl/Tk The Tk toolkit comes with a scripting language you may not want, and, out of the box, it has a fairly limited widget set by modern standards. No drag-and-drop support. Multiple GUI builders. Great canvas class. Exceptionally easy to get started with, great for prototyping.
• Fox Toolkit In may ways like FLTK. Has drag-and-drop support, but cross platform is still a promise.

Altogether, if you can deploy Java 1.2 and it's efficient enough for your needs (for most applications, it is), I'd go with that. If you need something in C++, I'd stick with wxWindows, FLTK, or Tcl/Tk, depending on your specific needs and preferences. I think you may also want to reconsider whether you really want an IDE and GUI builder; I find writing GUIs by hand in toolkits that are set up for it is ultimately faster and easier.

The biggest annoyance is that people *expect* the VC++ "ide" files. In fltk's case these are approximately TEN times larger than all the Win32-specific code (and this is an entire GUI library)!!! This is absolutely insane but that's the way it is. Borland and cygwin are supported with normal makefiles (though autoconf does not work).

I would also expect you to see a Linux port as one of the first contributions you get from the OSS community. This should be considered a free gift, there is no need to even test it if your boss refuses to pay for a Linux machine, but put the porting into the official code set and then you will start to see the real bug fixes and improvements roll in.

Like many others here, I agree that you should NOT "force" people to send you their fixes. This will not change the actions of anybody, and just antagonizes the people who would send you fixes (the vast majority). Most software engineers writing for free want to see their stuff publicized, and the way to do that is to put their stuff back into the official version.

These filesystems are not as simple to interface in as the "Amiga filesystem" or other such stuff, as these FSes have expectations to be able to control somewhat how the kernel manages caches. They're not merely "drop in a patch and all will be well."

As a result, while I agree that it's good to have some diversity now to allow some experimentation, I am far less sure that it will be wise to have four (or more, if rumors of Compaq contribution of AdvFS code turn out to be true...) filesystems integrated in to the "official" kernel stream. There may be merit to having a couple of them, but not likely all of them.

So while I agree that it's quite OK for there to be 5 of them (and that ignores GFS, NTFS, and other stranger options that may be of less direct relevance), I think that there will be, ultimately, a need for several of the "integration projects" to fail.

Otherwise, Linus and others won't have time to fix up NFS3, improve memory management, implement ACLs, implement capabilities, implement IA-64 support, and all the other sorts of things that need to occupy some of their time.

The GUI comparison was pretty good; I agree with Per that it is a Good Thing that we have GNOME and KDE, as this is sufficient diversity to ensure that there is some competition whilst not being so much as to be completely fragmenting. It is unfortunate that this leaves some potentially good toolkits like FLTK or Tk or Amulet or Garnet or InterViews "out in the cold."

The point is that variety is useful at the point in time at which you're not sure what the results should look like.

But after that point, variety comes at the cost of having to support additional "development streams," and while there is logic to "letting the best man win," this has the side effect that if you agree with this, you have to also agree with the notion that the "not quite best men" need to be able to lose.

As for head-bashing, I agree that Motif & gtk are both wacky to program for, but what graphical API isn't?

FLTK. And it doesn't even have to look bad;).

HTH, HAND.
Pi

--
. -- Perth

--== www.fltk.org ==--

No bloat, no silly c cast checking. Portable to win32 and X11. No 1/2-assed license, uses LGPL. Cool object oriented design. Give it a try...

fltk is a pretty nice cross-platform toolkit. Gtk looks nice, but I'm not sure most Windows users would want to or would bother installing Gtk to run an app.
About FLTK

GTK+ and Fltk both work cross-platform. Both are under very usable licenses for both proprietary and open sourced projects (unlike Qt...) and are easy to use.

GTK+ is available at http://www.gtk.org.
Fltk is available at http://www.fltk.org.

Go check them out. I think you might find what you're looking for there- I know I have.

Qt is nice but not the only solution. If you need to do cross-platform Linux/Windows development without having to suffer too much here are some pointers based on my experience:

I'd personally recommend FLTK: http://www.fltk.org for a nice, easy to use C++ toolkit that works flawlessly between many Unices, Linux and windows, and of course wxWindows which is now well-proven (http://web.ukonline.co.uk/julian.smar t/wxwin/).

FLTK is very simple and fast but has its own look and feel (on the plus side Unix and Windows application look exactly the same). WxWindows is a wrapper on top of win32 and GTK+ or Motif (your choice) so is a bit slower, but the toolkit itself is a bit richer.

You can use the cygwin or the mingw32 compilers to work with FLTK on windows, which makes it really totally free, not quite as good a development environment as Linux, but close enough. WxWindows requires VC++ I believe (I'm not sure, I use the python bindings with a pre-compiled version. Very fast development cycle: http://alldunn.com/wxPython/).

I am not saying that you would look in the Mozilla code and see X calls. That is also stupid. What they should do is write a "toolkit", but that "toolkit" is totally dedicated to running Mozilla, and is statically linked with it, and the source code is right there with the Mozilla source code. It would provide a portability layer over the various windowing systems (on Windoze it should use WIN32 api only).

Multi-application toolkits have their uses, but on a system as large and complex as Mozilla it is much more efficient and less bug-prone to write everything at a very low level. In my experience it takes more code to interface to a toolkit when you need it to perform the slightest different than it was designed, than to just write all the gui widgets at a low level.

This was one of the reasons I created a toolkit of my own ( fltk). I tried to design it so that it could be static linked, and if you needed to make it work with your appliation, you were free to change the internal code and make it into an application-specific toolkit. I am actually rather disappointed that fltk is pretty much being used just like other toolkits, including the making of it into a shared library, which is exactly not what I intended...

I wish Mozilla all the luck in making the "Xlib" version and really look forward to seeing it. IMHO this version will be vastly superior in every way, and I do wish they would devote all their resources to it.

I've been looking recently at FLTK ("fast light toolkit") - it looks pretty good from what I can see. It's quite small, it's efficient, and its cross-platform (Windows, X and OpenGL) and includes built-in OpenGL widget support.

I'm quite impressed with it (it's very easy to setup, install and compile on both Windows and Linux), although it is a little bit lacking in higher-level widgets (toolbars for example) and has a somewhat primitive looking file-chooser. Nothing a few weekends coding/contributing (it's LGPL) couldn't fix though. It also includes a GUI-builder.

URL is http://www.fltk.org/.