[Thunar-dev] Fwd: Gnome is trying to decrease memory usage.

[Benedikt Meurer]

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