by Robin Rowe 4/6/04 revised 4/8/04
CinePaint is taking a new direction to migrate away from GTK to FLTK. Owen Taylor of the GTK project asked me to explain why. I appreciate the help that Owen Taylor and Tor Lillqvist of GTK.org have given me with GTK. Everyone should know my reasons are not intended as criticism, nor as a call for changes to GTK2. I've spent many months trying to debug GTK1, the toolkit we currently use, which has given me a lot of time to think about GTK. In acknowledging that GTK is not working out for for us with CinePaint I am not implying anything about other projects. My concerns are specific to CinePaint.
- Like CinePaint, FLTK is a project that initiated in the film industry. FLTK was developed at studio Digital Domain for NUKE and is used by ILM in some of their open source OpenEXR tools. It makes sense for CinePaint to adopt a high performance GUI toolkit that maximizes compatibility with other popular programs in our industry. We are inclined to like FLTK because it is being used at companies we work with.
- We never chose GTK. It came with legacy code CinePaint inherited from GIMP. CinePaint is not tied to GIMP. We've resisted changing toolkits because of the effort involved, but the effort to continue with GTK seems even higher.
- GTK has a C API that many of our developers dislike. CinePaint is moving to C++. Using gtkmm is not elegant and would make GTK larger and slower.
- GTK2 is not fast and light. Several GTK applications report after migrating from GTK1 to GTK2 that they can't recommend less than a 1ghz CPU. Speed really matters to us, but the size kills us. GTK is so big we can't afford to QA it. Should we ship code that we can't debug? If CinePaint crashes users expect us to fix it. They don't care whether the problem is in our code or in a supporting library. FLTK is based upon about 120 source files weighing 337k. GTK2 is based upon about 340 source files weighing 7mb, plus many other libraries such as glib (125 source files weighing 2.8mb), gdk (62 source files weighing 938k), and gdk-pixbuf (62 source files weighing 1.4mb). An advantage of open source is supposed to be that you can fix problems yourself, but GTK is so big we can't do it. If GTK1 is too big to for us to handle, then GTK2 is doubly so.
- (Changed on 4/8/04) The GTK threading bug described by Tor (http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html) does not seem to be a bug. It is up to Windows application developers to have message pumps running in threads that need them. I knew that, but was confused by Tor's statement. I took that to mean there was threading inside GTK. That there is thread-related code in the message pump in GTK1 made it seem plausible. In fact, I still don't know what that code does. However, CinePaint Windows thread starvation was due to a bug in my code. Those who commented that it isn't the toolkit's job to fix that are quite correct.
- We can create a compatibility layer for FLTK so that GTK calls map into
FLTK without major code changes to our CinePaint source code. We have
a lot of experience with this sort of thing from tricks developed to make
GIMP plug-ins compile in CinePaint without GIMP. As a test I have built
hellogtkusing FLTK without GTK. In implementing a faux GTK API that shims into FLTK we're not going to be reimplementing glib, gdk, or pixbuf. The point of creating a thin GTK-like layer for FLTK is to remove GTK and all its dependencies, not duplicate them.
Some have the opinion that switching GUI toolkits is too hard or not worthwhile. Others disagree. Nobody actually knows, including me. There hasn't been a major open source project that changed GUI toolkits since GIMP migrated from X11 to GTK in 1996. In hindsight everyone agrees that was a good move, but it isn't clear that it relates today.
Everyone could be glad someone is stepping forward to put it to the test, to find out exactly what's involved and what the consequences are. How hard is it really? Are there any extra capabilities in GTK2 that I would ever miss? Actually doing it is the way to find out. Then everyone could base opinions on something more than supposition.
As to fatalist arguments that it isn't worth shedding 10mb of GTK code to make CinePaint smaller because we still have the overhead of other dependencies to contend with, that seems weird. Many people say they object to applications for being too big. That we are trying to make CinePaint as small and tight as we can seems a good thing.
Nice to see CinePaint moves on.
Sounds a bit fuzzy -- Wed, 07 Apr 2004 05:43:48 -0700 reply
1. How would your choice of GUI toolkit "maximise compatibility with other popular programs"? 3. If you like C++, then use gtkmm. You can start to use it gradually, because you can use the C API at the same time. 4. What does the source size have to do with anything? Are you talking about compilation times or runtime problems? 5. A bugzilla link would be useful here. Is this a problem with GTK+ 2 as well as GTK+ 1.2? 6. I think you are vastly overestimating the work involved in either adding an intermediate layer or porting to a completely different toolkit. If you do this, it'll be a long time until you get back to working on stuff that users actually notice.
flawed logic -- Wed, 07 Apr 2004 06:40:59 -0700 reply
1)Points 1 and 2 aren't reasons to use one toolkit over another. They are just statements of fact. 2)Why don't you use gtkmm? 3)What difference does it make, how many source files are in a toolkit. Most users and developers just install prebuilt toolchains. Tor provides these for Windows, and every Linux distribution provides these too. 4)Speed, ok that is valid point 5)What is this threading flaw on windows? Is there a bugzilla entry? 6)That compatibility layer sounds like a nightmare. That will be a lot of work
I've used both Fltk and Gtkmm, and I have to say that Fltk is great on my 60MHz Arm7 board, but GTK+ apps are much nicer to develop and use on a PC where the extra speed is available.
Robin responds -- Wed, 07 Apr 2004 09:27:58 -0700 reply
Appreciate everyone's feedback in the comments! That was helpful in making me understand where I wasn't clear. I haven't changed my opinion, but have added further explanation.
MultiThreading in FLTK and Windows -- Wed, 07 Apr 2004 10:22:28 -0700 reply
I think that you will find the same problem as in GTK2 in multithreading application in Win32. Probably you will still need main thread for windows operations. How do you plan to solve this problem ?
performance -- Wed, 07 Apr 2004 12:09:50 -0700 reply
I'm currently developing a gtk+ application for windows and we just purchased a 455mhz celeron prorcessor machine to do testing. the only part of the application that has noticable performance hit is in start up because the bulk of the application was built using libglade as well as another xml binding language that connects the application to a sql database. Why do i point out all of this stuff about libglade, xml and sql, because they all have one thing in common they read from the disk. My point the only slow part about the application is startup and that is because of all the disk reads when the program starts. Once the application is loaded, running with a memory foot print of 17 megs (loaded libglade file, xml files, and embedding the firebird database) the application runs very smoothly. I had a few issues with one of my gtk+ widgets but it turns out the performance hit was because i was doing a gtk_widget_queue_draw where i should have been doing a gtk_widget_queue_draw_area to reduce the amount of redraw. That's my experience with gtk+ anyway, and I can say that I like the apis and working with libglade and glade means I dont' have to think about the GUI, which gives me more time to focus on the important parts of the application
Good luck -- Wed, 07 Apr 2004 13:00:43 -0700 reply
It seems a lot of the people who have replied about this are GTK fans who want to keep a star application in the fold. That's valid and understandable. As an impartial observer who's never used CinePaint and doesn't use Linux or anything of that sort, I just read this and went "Man, what a shame." The world of pain you are rushing into strikes me as truly frightening. There's got to be something on joelonsoftware.com that might convince you of the low likelihood of this succeeding (without taking 10 times longer than you think it will and consuming massive development resources all the while).
That probably sounds condescending; I don't mean it to be. I would just rather see CinePaint continue, and that is my fear about what will happen. If the transition to FLTK is successful, I'll have every reason to be happy.
Good luck -- Wed, 07 Apr 2004 13:27:03 -0700 reply
Replying to myself, putting my money where my mouth is: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000348.html (I know technically, you are not starting from scratch, but I feel that your attempt to rewrite GTK for FLTK is basically a new toolkit).
Threading -- Wed, 07 Apr 2004 15:05:28 -0700 reply
As I pointed out on gtk-devel-list, the threading issue on Win32 is impossible to fix short of making the program entirely Windows specific and porting it to use Win32 directly, as no other toolkit is actually thread safe. If CinePaint hits this "bug" (really a design problem/quirk with windows) then it's going to be broken on almost any toolkit, whether that's GTK or FLTK which is likewise not thread safe.
Threading -- Thu, 08 Apr 2004 01:27:56 -0700 reply
If I understand the description of the threading problem (http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html) correctly, then it's a design problem in the application using GTK: Even directly in Win32 it is not always safe to access a window that was created by another thread. In some cases it works, in others it doesn't (depends on the type of Window, like which control is used etc.). Even in Windows the only
good approach is to let each thread manage its own Wwindows. Any other thread has to send messages to the owning thread to let it manipulate its windows itself.
So if thats the only problem of GTK on Win32, then it's not a problem of GTK but a mis-design in the application.
Just my (not so humble) opinion.
Why not refactor ? -- Thu, 08 Apr 2004 01:33:13 -0700 reply
In building a GTK wrapper for FLTK, you will introduce a new intermediate layer that you will first have to develop, then maintain. Why not spend some time in looking for how to refactor CinePaint from a GTK UI to a FLTK one ? In this refactoring process, which IMHO will be as costly as developing the GTK wrapper, you will even get a chance to improve your software architecture.
So if thats the only problem of GTK on Win32, then it's not a problem of GTK but a mis-design in the application.
From the message: "One problem is that each thread in Windows have its own message queue. GDK-Win32 currently uses just one "message pump" in the main thread. It will never see messages for windows created by other threads."
So the problem is in the GDK not in the application. You can design a correct application which use only one GUI thread, but that isn't a nice solution.
Point 4 alone is enough reason not to use GTK. When somebody have to support an application on 2-3-4 platform, then it does matter that how big is the underlying library. It is very expensive to debug a big library's errors.
Why another toolkit? Why not QT? -- Thu, 08 Apr 2004 04:09:28 -0700 reply
It's always good to have choice. But I think people should try to use GTK+, QT or other Wrapper which are based on these 2 Toolkits. It is difficult enough with 2 toolkits to keep your desktop Look
n Feel consistent. If you use another Toolkit it's nearly impossible to get a consistent Desktop in the future...
Why don't you use QT from Trolltech. Although I'm not a C++ specialist I heard that QT is the best documented and developed Toolkit which is available today. You get it free for Linux, Windows and Mac OS X.
Re: Threading -- Thu, 08 Apr 2004 04:35:50 -0700 reply
No, the problem is in the application. The only solution to this problem on Windows (and it's a problem that affects all Win32 apps) is to pump the message queue in each thread that creates a window. This is true even for threads which implicitly create windows (for instance, by performing an inter-thread COM interface marshal).
If CinePaint is not able or willing to run a message loop in each thread that creates a window, then it will never run correctly on Win32. The best solution is just to have a single thread for all window operations, and then run all code that needs to be perform window ops in the context of the main thread.
performance -- Thu, 08 Apr 2004 05:22:36 -0700 reply
Good to hear someone switchs to a resource-friendly graphics library. GTK and QT are just bloated and need to be redesigned from scratch to have a good design, but the authors won't do that and will continue giving us bloated code.
Nice to see someone makes real profress.
performance a white elephant -- Thu, 08 Apr 2004 05:33:33 -0700 reply
I use Abiword and GAIM (both GTK2 applications) on my old P166 latop running Windows 98 specifically because of their acceptable performance in that enviroment. To say that any software written using GTK2 requires at least a 1 GHz CPU is simply ludicrous.
No major GUI toolkit is really thread-safe -- Thu, 08 Apr 2004 06:08:10 -0700 reply
Most toolkits are not thread-safe for upper-level GUI functions. For example, you cannot do GUI operations in OS X's Cocoa API from multiple threads. The recommended model by Apple is to spawn "worker" threads that send messages to the single GUI thread, or do things like setNeedsDisplay: on windows to tell the GUI thread to redraw them. While I'm definitely not an expert on GDI/GDI+ programming, I'm fairly sure its not significantly thread-safe for GUI operations either. KDE/Qt also have some serious multi-thread issues for higher-level GUI classes. In general, if you want to write a cross-platform GUI application, you cannot rely on a completely thread-safe API unless you use a toolkit directly on the framebuffer.
You should use QT -- Thu, 08 Apr 2004 06:40:22 -0700 reply
Apart from being the best C++ toolkit nowadays, apart from its great performances, apart from being free for non-commercial apps, you should really use it since (at least on linux) consistency is the main concern of modern desktops...
If you want c++, consider wxWindows. If you really want fltk, instead of writing a gtk+ -> fltk layer, consider writing a wxWindows -> fltk layer.
A move of isolation -- Thu, 08 Apr 2004 08:06:26 -0700 reply
Migrating Cinepaint to FLTK would be a move of isolation, distancing Cinepaint from useful contributions from the current Gimp codebase, and from the GTK2 development platform in general. Running Cinepaint in a mature GTK2 environment (Gnome) might also increase the likelyhood of seeing Cinepaint complemented with a suite of studio quality open source software (3D/vector/animation/editing).
(4) There are many GTK2 apps that will run just fine on a 350 Mhz PII machine. A one gigahertz machine does not seem unreasonable for a heavyweight app like Cinepaint, and cannot even be considered an entry-level machine (try finding anything slower than 2Ghz at your local computer store).
gtkmm won't make your app slower -- Thu, 08 Apr 2004 08:34:56 -0700 reply
By the way, I don't agree that moving to gtkmm would make your application slower. In fact, I don't see how any GUI toolkit is likely to have a noticeable effect on CinePaint's "performance", by which I assume you mean its responsiveness. This sounds like premature untargeted optimisation rather than a response to actual user experience.
Yes, gtkmm would make your application larger, but I'm sure that's nothing compared to the size of the image files that you load into memory.
You are the maintainer, and you should use whatever makes you feel comfortable, but your justifications for that seem insubstantial.
By the way, the win32 threading bug seems completely fixable.
GIMP -- Thu, 08 Apr 2004 09:13:09 -0700 reply
I run GIMP just fine on my 700 Cele laptop, the only slow part is loading it (it's a 4200 RPM drive). I realize it is less responsive, but geez it's not unbearable for me. GTK runs plenty fast for me. There are superior toolkits, but I still use GTK2.
... -- Thu, 08 Apr 2004 09:49:21 -0700 reply
Stop saying unbearable for a graphic toolkit! User should not __bear__ a GUI. User can wait on actual work but the GUI should not getting in the way, no matter how little it is.
gtk2 is getting in the way now. Some people see it and some people don't. But there are enough people see it.
Is Jave threadsafe? -- Thu, 08 Apr 2004 11:13:17 -0700 reply
Just curious -- I know Java isn't bloat-free -- but for the thread safety concerns, how does Java fare? If it is thread safe, how does Java accomplish this on the different platforms that it runs on?
FLTK is a Great gui toolkit -- Thu, 08 Apr 2004 11:41:39 -0700 reply
I think this is a good choice. FLTK is a great gui toolkit which has many benefits. "FLTK provides modern GUI functionality without the bloat and supports 3D graphics via OpenGL? and its built-in GLUT emulation." And "FLTK is designed to be small and modular enough to be statically linked - the "hello" program is only 97k when compiled on an x86 Linux system!" It is also very cross platform (Linux/Unix, Windows, MacOSX) Not to mention that it's easy to learn.
Jumping the gun -- Thu, 08 Apr 2004 12:45:50 -0700 reply
Why do you need threading in CinePaint in the first place? I have been guilty of this in the past when developing GUI software, pthreads is an attractive option but often considered prematurely. I believe more often than not people use pthreads when they should have just changed the design of the program before resorting to using threads, especially in GUI applications due to the extreme complexity it introduces thanks to toolkits and windowing systems being largely thread-unsafe. If you must use threads to scale on multiple processors just keep the threading simple, e.g. spawn a worker thread for an expensive task and just have it report to the main GUI thread so you keep the GUI things seperate from the multithreading.
Alot of the above posts are correct IMO, if you are encountering threading problems with GTK+, you will likely encounter the problems again with whatever toolkit you use. Instead of changing toolkits change your programs design to make the thread-safe requirements easier. (even parts of libc and other libraries you will use trivially will often be thread-unsafe, to expect the GUI toolkit of all things to satisfy this requirement you're on a different planet, based on my past experiences with pthreads programming).
You do have valid points regarding performance and size of codebase though, if you must do QA on all the supporting libraries I am sorry. But if this is true, GTK+ is the least of your problems, do you link against GNU libc? You also are likely using X for your display, and the linux kernel for your system calls and hardware support. Where does the line get drawn in your dependancy tree? You dragged in gdk and glib, why not the x libraries or video drivers in X? or the memory management in linux X will be using? GTK+ suddenly is just a blip on the radar, X and glibc are huge codebases.
good show -- Thu, 08 Apr 2004 16:04:56 -0700 reply
I heartily applaud the decision to move away from GTK. The gimp toolkit is ok for big clumsy programs, but I have a laptop w/P3, and it runs GNOME et al. quite slowly. Windows, otoh, is much, much faster (comparing same apps, like OO.org, Abiword, etc). I look forward to the faster cinepaint :)
An example of app which switched toolkit -- Thu, 08 Apr 2004 16:11:06 -0700 reply
Rosegarden switched from gtkmm to Qt. Quoting the website (http://www.rosegardenmusic.com/): "Rosegarden is a professional audio and MIDI sequencer, score editor, and general-purpose music composition and editing environment.", so it's definitely a complex application. One of the author was a member of the gtkmm dev team before this switch. You might find his site interesting: http://www.telegraph-road.org/
Qt -- Thu, 08 Apr 2004 20:12:44 -0700 reply
That's right! Qt is NOT free for commercial apps. Only GPLed apps can use Qt for free on Unix/Linux. If you want to sell your app it's approx. $1500 USD per seat. I have used FLTK and I have tried just a little bit of WxWindows. Wx binaries were MUCH larger and they even recommend distributing a dll to reduce bloat. FLTK is small, fast and statically linked. I haven't tried GTK or Qt but I have heard they are even more bloated. Not to say that large binaries and slowness is totally unacceptable. I'm sure Qt and GTK have features not yet implemented in FLTK,but if speed and size are important then they made the right choice.
http://www.thirdwishsoftware.com/magpiepro.html http://www.matthiasm.com/movido.html http://www.easysw.com/~mike/flphoto/ http://www.osc.edu/~jbryan/VolSuite/ http://fl-inventor.sourceforge.net/ http://www.simulation.com/products/glstudio/gl_studio.html http://gmorgan.sourceforge.net/ http://www.geuz.org/gmsh/ http://fgsd.sourceforge.net/ http://www.wizards.de/earthsight/ http://zynaddsubfx.sourceforge.net/ http://csounds.com/maldonado/ http://www.physcip.uni-stuttgart.de/phy11733/quat_e.html http://www.geocities.com/nicholasshea1/tesselsphere/tesselsphereindex.html
GUI toolkit migration -- Fri, 09 Apr 2004 08:42:55 -0700 reply
I moved my proprietary motion capture application (120 source files, many megs of code) from Motif to FLTK a long time ago (SGI/Irix). Today, the app runs superfast, and on four platforms (Linux, Irix, OS X and Windows). I am glad I did the port and I congratulate the Cinepaint team on that decision! Thanks.
GTK+ size -- Fri, 09 Apr 2004 09:06:16 -0700 reply
I use Debian for my development box. When I program with gtk+ I simply run apt-get install libgtk2.0-dev. What I don't understand is what difference does it make if GTK+ is 100 lines of source code or a 100 billion lines of source code? I've never looked at any GTK+ source code, as that isn't relavent to me. I believe Tor also provides Windows binaries, so you aren't even required to even ever build GTK+. If you use libglade, you become even more removed from GTK and can concentrate more of just your application
... -- Fri, 09 Apr 2004 19:14:36 -0700 reply
Size matters. As the guy need to fix all the gtk+ bugs before he can move his effort to Cinepaint. At least the author blamed all the stagnation of Cinepaint on gtk+ 1.2.
I mean it is funny to complain that no one is care about gtk1.2 after gtk2 were released for so long. Oh well, obviously the cinepaint team will be maintaining FLTK 1.1 from now on. Good work!
... -- Sun, 11 Apr 2004 09:56:24 -0700 reply
If you read the FLTK announcments you will see that the FLTK team is currently working on UTF-8 and printing support. http://fltk.org/newsgroups.php?s1+gfltk.announce+Gfltk+v1 It's in version 1.2 which is currently beta. It should be final sometime this summer.
On Friday 09 April 2004 08:21, you wrote:
Just curious, is RoseGarden an example of a large app that converted mid-stream to another toolkit?
Not exactly, the story is a bit more complicated. Between the time when we decided to ditch the old C code base of v2.1 and the time development really took off again, there were two "aborted" rewrite attempts (hence why RG is now "Rosegarden 4", although the 4 is often dropped to avoid confusing people too much). These two attempts are somewhat intertwined in that I don't recall there really was a clear seperation between them, but the point is that the second of these two aborted attempts was using (well, trying to use) gtkmm. So when I left gtkmm 4 years ago, we started clean again.
Therefore it's inexact to say that we migrated from gtkmm to Qt. What happened is that we had a small stillborn code base using gtkmm which never did anything useful (not even loading and rendering a file), we ditched that and started clean with Qt/KDE.
And with the benefit of hindsight, what did you learn about the level of difficulty and rewards?
Given that we didn't do what you think you did, I'm not sure what to answer here. However I did learn a lot from switching to Qt, and the one thing I can tell you that may be of interest to you is this : NEVER rely on a tool which will require you to spend time on itself.
If you're writing an end-user app (with real users, as I understand from the Cinepaint homepage), then it is absolutely vital that any tool you use never gets in the way. It must work, period.
So for instance, things like "creating a compatibility layer for FLTK" will at the very least drag you down, if not kill the project eventually. Choosing gtkmm for Rosegarden was one of the biggest mistake we made, because it wasn't up to the task and required some improvements right from the start. At first I naively thought it wouldn't be a big deal, and a couple of years later I was so involved in gtkmm development that I had almost forgotten why I was doing it. That it was a binding over a large, scattered and ever-moving API was a very aggravating circumstance, but nonetheless this kind of sub-project development never ends.
You might find some more info from rough notes I had thrown on a page long ago : http://www.telegraph-road.org/writings/thoughts_on_rg_devel.html
Anyway, I've read the wiki page, and quite frankly I don't think you have much of a choice : go for Qt. I'll spare you the advocacy, if I understand correctly the problem is that you need Windows portability so the Qt license is a problem. You have two options : try to get a deal from Trolltech (they're most likely open to the idea), or use the cygwin-based port (KDE compiles on Windows thanks to it).
Hope this helps,
-- ????????????????????????????????????????????????Guillaume. ????????????????????????????????????????????????http://www.telegraph-road.org
USE FLTK --> AVOID SOURCE CODE BLOAT -- Tue, 22 Jun 2004 19:52:11 -0700 reply
Good on you. Avoid BLOATED GUI toolkits and use a decent LIGHT-WEIGHT toolkit like FLTK. Remember, you are dealing with source code and for something as "simple" as GUI the last thing you want is to be scanning through excessive code while possibly extending the toolkit for your specific needs. Hey, the default FLTK distro would most probably be fine and this is still a GOOD reason to use FLTK. Myself, I deal with specific instances of an object database, neuro-fuzzy environment, and a 3D graphics engine (at source code level) and using/enhancing (e.g. custom widget creation) FLTK gives short times for GUI work and allows me more time to spend on my algorithms.
My BLOAT argument is not related to effect on executable performance but the effect on the developer's (e.g. myself) performance at "cutting" code.
My other reason for preferring FLTK is due to familiarity of "base" Xlib and Win32 APIs and was interested in a light-weight toolkit (FLTK) that is layered directly above these "base" APIs.
Use FLTK. I have switched from several toolkits in my lifetime and the experience can only make you better.
BTW, my C++ development platform is OpenWatcom Version 1.2.
Why another toolkit? Why not QT? -- Sat, 24 Jul 2004 04:04:37 -0700 reply
Not really ... GPLed versions of QT do only exist for Linux/X11 and MacOS afaik. At least I haven't been able to dl a free (or personal or whatever) version for Win32. :-(
GUI, GUI, GUI, blah, blah, blah -- Tue, 02 Nov 2004 20:09:31 -0800 reply
We need faster math! I compile both CP and GIMP with various optimizations and test the speeds, and GCC is limiting...but so is the math. GIMP 2.2 is now on CVS and it is noticably faster when blurring, etc. Cinepaint development must absolutely concentrate on image editing speed [ok, and memory] NOT gui.
Who should give a darn about gui? Nobody. There's a gui. It exists. Use it and get on with improving the meat and potatoes.
GNU = Zealots + Over-coded Junk -- Wed, 12 Jan 2005 04:46:38 -0800 reply
The subject line "says it all". GNU lovers are Richand Stallman sycophants. Stallman seems to claim "ownership" over all open source software. GNU lovers seem to think everthing should be 1) developed using GNU-based products 2) every non-GNU-based product should become one, surrendering to the GNU Licence.
Good for the CinePaint people. Avoid inefficiently designed, over-coded GNU software. It's part of the MIT coding philosophy of "everything and the kitchen sink, twenty times over". Move to the light and use software based upon Bell Labs coding philosophy (aka the
C and UNIX philosophy), which is "fast and simple".
"Trolltech to Extend Dual Licensing to Qt for Windows Qt cross-platform development software will be available under the open source GPL license for open source development and a commercial license for commercial development PALO ALTO, Calif. - February 07 2005
Trolltech?, a provider of leading application development software, today announced that it will extend its successful dual-licensing business model to include the Qt? cross-platform application development framework for the Microsoft Windows operating system. The availability of Qt for Windows under the open source GNU General Public License (GPL) will bring the benefits of open source software to the Windows environment, fueling the development of open source applications for the mainstream PC market. Qt for Windows is already widely used for commercial software development." http://www.trolltech.com/newsroom/announcements/00000192.html
My 0.02 -- Mon, 30 May 2005 13:42:01 -0700 reply
I think what most people here are missing here is the perspective of the developer developing the app for the customer. Most of the comments tend to take a "who cares about the GUI code, give me meat and potatoes" or something about the threading issue (which may in fact not be solved by FLTK). These are not the points or at least the main point.
I too found myself blissfully jumping into GTK and using it for GUI programming since I didn't want to do .NET/C# or worse: MFC, and I did want something cross-platform. As I looked at the GTK port to Windows, I noticed several things:
- although the look and feels, although quite pretty and functional, suffered from redraw problems (especially the WinXP look and the Java Metal look) - the horror of programming GUIs in C brought me back to my Motif programming day - something I would rather not have to remember. (My left eye still twitches when someone mentions Motif)
Realizing that I could quickly solve the problem, I downloaded the C++ library (now gtkmm) but quickly came across strange refresh errors with, for example, models and grids - sometimes the model does not get reflected in the view.
Bottom line is, (and I think again) this is a perspective that most Open Source/GNU-style license devlopers forget or have not placed themselves into the position of: customers. Or in the very least developing for customers. Most open source free projects don't take into consideration customers. The attitude is overwhelmingly: RTFM. Robin is explaining that if the customer isn't happy and the problem lies somewhere inside of gtkmm, gtk, libglade, pango, etc. then there's not much that can be solved. I'm not saying that FLTK is going to be serviced any better but the truth of the matter is FLTK has much less in terms of layers. More layers = more chances for bugs, errors and problems, which Robin has made clear he has come across.
The other issue is license. GTK is LGPL whereas FLTK has modified that license to allow "the library" to be bundled with "the work" without "the work" having to be LGPL. Again, think customers. "Ok, now sir, just download GTK 1.x, then download GTKMM 1.x, then download GTKextGLMM ...". This is something most people in the open source/GNU world miss, the customer perspective.
My response to the GTK supporters would be chill. Take a couple of deep breathes. Accept this as opportunity for constructive criticism where you listen to the shortcomings of the framework and try to improve them so that other large-name free projects don't migrate elsewhere as well.
/steps down from soap box
An Old X11R6 GUI Developer's View -- Tue, 07 Jun 2005 18:54:25 -0700 reply
I built a lot of stuff with the Widgets, and was never happer than when I could automate building GUIs when the builders came along.
FLTK now has a GUI builder. If it is really 10% of Gtk+ that is 90% you don't need to debug.
I think the Cinepaint crew has a point many miss. They are building a tool that goes into production.. Supporting an industry... not a toy... an experiment.... a hobby...
They are following ILM's path. It's stuff works... had better work....
As for GIMP... 16 bit has been promised for 2 years now.... no delivery..... Still waiting for GEGL... I am a photographer... I need 16 BIT NOW !!! I don't need GEGL... I don't want GEGL... I want 16 BIT NOW !!!
If I could modify GIMP source to support 16 bit... I'd do it tonight... and kiss GEGL goodbye!
I need plugins to process RAW files. refocus images .... correct color...
So, why don't you boys quit this ruckus... and build something I and everyone else can use to process images? NOW !!!
Oh... I forgot one important thing.... something that doesn't crash, is ROCK SOLID... I HAVE WORK TO DO !! If I want to fix the god damn code, I'd write it! And I'd use my porprietary CASE tools to document it and generate the code so... I'd have some god damn idea of how it is supposed to work And... when I wrote it... I'd do what I did for Motorola, Exxon, USS and many others... I'd make it fail gracefully... or not at all....
And one more thing... I built the paging and handoff algorithms for 2G cellular in 4 months... Built the soaking pit scheduling system for Inland Steel in 3 months... I don't take 2 years to do something... I design it.. check the design.. build it... test it... and deliver it.... FAST !!!
So boys... how about converting some of that steam into something useful.???? 16 bit image processing for the professional photographer... Yesterday would be just fine for a delivery date....
Dr. George W. Oprisko, Dean, School of Engineering Shenzhen University email@example.com
Now that Qt4 is out with a GPL'd version for windows, you guys going to switch? Because Qt really is the best toolkit around.
Have you not understood anything that people have been talking about here? Look at the licensing! Do you not understand the implications of the license? Please go off and read about the idiosyncrasies that LGPL, GPL pose on developing to customers (read above) and you'll quickly see why this doesn't work.
As well, if QT4 is ready it's certainly well hidden as TrollTech has no link to the download for such a binary.
GUI API Change won't fix your performance problems -- Fri, 23 Sep 2005 22:14:07 -0700 reply
I'm not a fan of GTK myself. In my Humble oppinion I've tried to program in it and I find it to be as much brain dammage as win32. Its big bulky and its signal slot mechanizms are overly complex. If fltk will make programming faster for you then go for it. Its a good library. However the GUI change won't fix your threading or software performance problems.
I'd suggest maybe finding some way to incorperate the functions of the GPU a little more. OpenGL and DirectX both support shaders now. And the GLSL and Cg are both portable to all the platforms. Shaders may be a very good fix. GPU's are capable of doing graphical calculations much faster then the CPU is. Although you would also need some way of extracting information from the framebuffer afterwards.
As for threads they should only be used for two reasons in a program. One to improve program responsiveness and two to allow calculations to be split up between processes. Improving program responsiveness means using threads to handle input mechanisms. Locking reasources is a nightmare at the best of times. Changing libraries won't fix that. You should also be very carefull to make sure the library is thread safe as well.
Heavy-threading GUI intensive applications as FLTK viability examples -- Fri, 07 Oct 2005 12:54:06 -0700 reply
If you want to check out a very heavily multi-threaded example of an application with FLTK-based GUI framework, take a look at Gled, a grid application framework and toolkit in C++ based on ROOT: http//www.gled.org/. (Dislaimer: I am part of the project.) C++ classes behave as plugins, extending the GUI with widgets for all member methods and values that can be used to build application GUI and set up multithreaded multi-cluster grid application with 3D rendering, sound, heavy input-output and a built in C++ interpreter. For ROOT, see http://root.cern.ch/ - it is well worth checking out, but it is probably too big for you to use. And all the best of luck, yours is a great project! -Kvorg
Do it! -- Sat, 05 Nov 2005 03:27:33 -0800 reply
It seems the problems both users and developers report are completly ignored by the GTK developers. Everytime someone mentions it he is completly ignored. Seems to quite the same that happend when XFree was forked to xorg -> a few stupid lead-deveopers keep the whole thing down!
So QT4 won't happen? -- Tue, 20 Dec 2005 22:30:19 -0800 reply
It was unclear to me who responded to the last question about QT4 but I'll ask again for clarity, is QT4 beyond consideration as a display toolkit now that it's free for gpl programs on windows? The license discussion posted above seemed a bit irrellevent, since its my understanding that cinepaint is distributed under the GNU GPL license. I totally understand if you guys choose not to go with QT though (you're probably pretty far along with fltk by now). I was just wondering since most of our studio internal tools have migrated to Qt in the past year.
Please do whatever u like but NOT gtk+2 :) Gtk IS a mess and it is difficult to develop/maintain a large application. Just look on Acrobat Reader a 45 MB download and very slow application, i heard they consider switching to QT too.
Oh dear lord... -- Thu, 16 Mar 2006 17:50:38 -0800 reply
Well, I've used FLTK and TRIED to use GTK. I must say that FLTK is the simpler of the two. Sure, FLTK is not going to have everything in it that GTK (and it's dependant packages) has, but the question should be "Does Cinepaint need them?" I wouold guess that it doesn't. Why? Because I have to asssume that the people coding Cinepaint are competent enough to tell the difference. If you don't believe that - then why are you following the project?
Good idea, good luck -- Sun, 02 Apr 2006 01:33:26 -0800 reply
I personall try to avoid all applications based on GTK2 since I also own a slow Duron800 where GTK2 runs very slow. resizing windows etc. all causes artifacts, just ugly :-/
Adobe Reader's bloat is not caused by Gtk -- Tue, 11 Apr 2006 18:33:19 -0700 reply
Adobe Reader is a 45 MB download because Adobe reader is a bloated mess, not because of GTK. Sorry. Neither is Gtk a "mess" to program. Gtk (and Qt) is on the of the cleanest, most extensible GUI apis ever designed. Clean OOP. As far as C++ goes, GTKmm is a very nice binding, a little nicer than Qt (no preprocessor). That said, there are outstanding issues with Gtk on Win32. For a commercial, production app, they should give a developer pause.
Gtk resizing stutter problems are an X11 issue -- Tue, 11 Apr 2006 18:36:56 -0700 reply
Because X11 is asynchronous, as the window resizes, configure and expose events are sent to the GTK widgets to get them to redraw. Because of this asynchronous nature, until recently there was no good way to synchronize the redrawing to the actual expanding of the window, as OS X and Windows do. This is changing and a synchronization mechanism is being built into X11 that will allow Gtk (and Qt and any other widget set) to be able to resize fluidly. On my machine, Qt and Gtk apps tear and stutter equally when I opaquely resize windows.
QT 4 -- Sat, 15 Apr 2006 19:33:16 -0700 reply
Not being able to "debug" the graphics library is not really the issue here, that's just an excuse. From Cinepaint to processor there are millions of lines of code that the Cinepant team will never debug (X11, GDK, kernels, win32).
The reason Cinepaint is switching from gtk to fltk instead of the sane choice, QT4, is because Robin hates the GPL because of a "bad experience with RMS". Note the fact that rewriting all this code allows Robin to switch the license of a huge amount of code from GPL to MIT. You can look at the license of all new code to see this. Robin wants to use the code and work of all these volunteers and workers of the studio to allow him to create custom proprietary solutions for people.
QT4 is a proven cross platform library used in many major commercial applications. But the fact that it is GPL and not LGPL makes it untenable for someone who's agenda is conversion to the MIT license and to evental closed source proprietary versions sold to studios.