Erik Harrison wrote: > I think ultimately we just need to be active in the Gtk+ community so > that it as much as possible remains useful to us. > > It isn't going to become broken in the short term. The various changes > coming out of project Ridley could go either way. It could totally > screw up Gtk+ as a platform, and it could finally solidify it as a > more complete platform, getting in some critical features (like > printing support) while at the same time permitting applications to > cut silly Gnome requirements. > > Most likely, this is neither Gtk+'s glorious rebirth or the fabled > falling of the sky. Picking a new toolkit would involve a lot of > thought and planning - and if we saw signifigant reason to move all of > Xfce off of Gtk+ I suspect that we would not be alone - perhaps there > would be enough of us to maintain Gtk+ 2.8 indefinately. > > Who knows. It's all wild speculation at this point.
It's not just "Project Ridley", that's only one point. There are several issues with Gtk+, for example: - Deployment/Installation: Updating/Installing Gtk+ with all its requirements is so damn complex, esp. if you happen to use one of the 99% of all systems, that's not currently being used by one of the Gtk+ core developers. And this causes trouble for all other projects that depend on Gtk+, esp. Xfce, where we introduce damn stupid and damn unnecesary work-arounds to be able to run with Gtk 2.0 or Gtk 2.2. There's no excuse here, this is just stupid and broken, and a real waste of time and energy (and in case of Xfce, where we have only a few developers, it is frustrating to waste this little manpower to work-around the Gtk deployment issues). On the other hand Qt (just an example) is pretty easy to install/upgrade, just untar in /path/to/newqt, configure, make and you're done (no matter if you use a "mainstream linux" or a not-so-mainstream system like Win32 or Solaris). - Type/Object System: Nice, but useless. The GObject type system has a few oddities (for example, you're unable to unregister types, etc.), but in general its a nice way to add some structure to C code. But that doesn't matter, as it's too complex and poorly documented, and nobody's using it. Just check the average Gtk/C based project: Atleast 90% of them invent their own ways of structuring code and reinvent most of the features offered by the GObject type system, and only use the system if absolutely necessary (for language bindings or widget libraries). So what good is the best system if nobody's using it? Right, it's useless and should be improved/replaced. Compare this to the average Qt based project, where people make heavy use of C++ classes and the extensions provided by Qt. So, it's indeed possible to develop a basic framework that will be heavily used by application developers. - Documentation/Support: As already mentioned, the available documentation is useless or incomplete compared to for example the documentation available for OSX developers, Windows developers and Qt developers. I solved this problem for myself by checking the Gtk+ source code directly when necessary, but this is honestly by no way a good solution. Good documentation is important for a framework like Gtk+. - Memory/Performance overhead: As said earlier, the problem is not necessarily located in Gtk+ itself, but the memory management and the overall complexity of certain parts of the libraries cause trouble for application developers and that in turn leads to the overall overhead for the applications. Gtks primary user, GNOME, is a good example for the problem. To be fair, it's not only Gtks fault, it's also caused by the fact that C as a programming language is not really well suited for high level application development. - Language bindings: It is said that Gtk is very binding-friendly, but if you take a closer look, you'll discover that writing a new language binding for Gtk (indepent of the binding language) takes a LOT of time and effort. And running an application that utilizes one of the available language bindings involves quite a lot of overhead (both performance and memory). A common runtime (like for example .NET) would not only save time and effort, but would also help to get more people involved. It doesn't need to be .NET, that's just an example. And there are several more, but I guess you got the point. Note that I didn't say that Gtk is just a bad piece of software, I just said it features many problems, and atleast all of the above are indeed solvable. And to avoid confusion: I didn't say that Xfce should switch to another toolkit. I just said, it'd be nice if Xfce would switch as a whole. I'm talking about Thunar here (that's why it's on thunar-dev instead of xfce4-dev). And I'm not talking about switching right now. I'm currently looking for (read: evaluating) alternatives and the most promising for Thunar is Qt4. I could also imagine a KDE4-based Thunar, as the goals are pretty to those of KDE4 (and no that's not the "look funky" goal). I'm not that religious to say: Here we are with Gtk2 and there's no better foundation for the file manager. This mail is based on my current frustration with Gtk and other parts of the GNOME core, so interpret it accordingly. I spent so much time on Thunar just to make sure there are no memleaks or crashes, which was pretty successfull, but took so much time and energy that there's nearly no real progress, and that's frustrating and daunting. Sure, I'm not a C programmer, but nevertheless I'm sure that the problem is not solely on my side. Benedikt _______________________________________________ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev