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

2005-09-30 Thread Benedikt Meurer
Xiong Jiang wrote:
 It's just my personal preference. :)  Some people like GTK more while
 some like QT more. Whichever they like, they always can express their
 preference. It's not about the business to _evaluate_ the toolkit.
 
 IMHO C++ _is_ a little profounded (or in my awkard English, bloated) in
 features as a language. That's why Java and C# are created and become
 popular.
 
 Again, this is just MHO. Please do not take it as bussiness of
 evaluating C++.

Sorry, I don't get what you are talking about. Do you mean that the
language specification for C++ is too complex (if so then Java is also a
bloated language)? You might want to check Scheme then.

If not, you should enlighten us poor souls, what's the difference
between a bloated formal language and a non-bloated formal language.

Benedikt
___
Thunar-dev mailing list
Thunar-dev@xfce.org
http://foo-projects.org/mailman/listinfo/thunar-dev


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

2005-09-30 Thread Jeff Franks
Xiong Jiang wrote:

 It's just my personal preference. :)  Some people like GTK more while 
 some like QT more. Whichever they like, they always can express their 
 preference. It's not about the business to _evaluate_ the toolkit.

 IMHO C++ _is_ a little profounded (or in my awkard English, bloated) 
 in features as a language. That's why Java and C# are created and 
 become popular.

 Again, this is just MHO. Please do not take it as bussiness of 
 evaluating C++.

 Have fun,

What C++ programming experience do you base you 'bloated' opinion on? I 
ask because it's funny how programmers who don't use C++, or have never 
taken the time to learn, keep calling it bloated. The key to 
understanding C++ is simple. It is the programmer using the C++ language 
that is the problem not the C++ language itself.

Jeff.


___
Thunar-dev mailing list
Thunar-dev@xfce.org
http://foo-projects.org/mailman/listinfo/thunar-dev


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

2005-09-29 Thread Xiong Jiang
I am just a user not a programmer of software based on GTK+ but I feel very sorry if GTK+ is on the track like what you guys expressed in this thread. I like GTK a lot as I always prefer C over bloated (somehow) C++ language. And GTK did very neat work too. I would think that many other people like GTK+ as me too.
If too much company interests are played in it, then eventually it will be forked, just like Xorg forking out of XFree86. It's painful but it's still good direction, towards the goal to build software strong, and flexible.
XFCE and Thunar will still be using the forked GTK+ then. :)Thanks,XiongOn 9/28/05, Biju Chacko [EMAIL PROTECTED]
 wrote:Benedikt Meurer wrote: Biju Chacko wrote:Benedikt, any time you and/or any one else wants to make the jump to QT4
I will gladly follow... and take my skills with me. I agree witheverything you have said on this topic. I have been fed up withGTK+/GNOME for years (and Fedora). The root of the problem as I see it
is Redhat's control over both projects (the project leaders work forRedhat). This has continually stifled innovation because both projectsare not independent and tend to program with Redhat blinkers on. I have
continued to write my C++ library for GTK+ for several reasons. I havealready spentyears on my project and it's hard to throw it all away.When I started out I thought that GTK+ needed all the help it could
get... but I was wrong. It is very hard to help either GTK or GNOMEprogrammatically. In the past my concern about moving to QT isWhatprogram would I write if I did? Language bindings are out... I wouldn't
know what to program. One thing I am looking forward to is the firststable release of openSUSE next week. Finally I can dump Fedora.Umm, Sun and Novell have a heck of a lot more GNOME guys than we (Red
Hat) do. I agree with Jeff except that I don't think that RedHat is the only problem source around. RedHat had the chance to turn Gtk+ into something usable years ago, similar to what Trolltech did to Qt, but they missed
 the chance. Now that Sun and Novell entered the stage, chances are very low that either of them will do it.I'm not very familiar with the history of GTK+, so I can't comment. I'vejust noticed a new trend of depicting RH as the new M$.
Just remember the old saying, Never attribute to malice that which canbe adequetly explained by incompetenceRH makes as many mistakes as the next company ...-- b___
Thunar-dev mailing listThunar-dev@xfce.orghttp://foo-projects.org/mailman/listinfo/thunar-dev

___
Thunar-dev mailing list
Thunar-dev@xfce.org
http://foo-projects.org/mailman/listinfo/thunar-dev


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

2005-09-29 Thread Brian J. Tarricone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/29/2005 10:19 AM, Xiong Jiang wrote:
 I am just a user not a programmer of software based on GTK+ but I feel
 very sorry if GTK+ is on the track like what you guys expressed in this
 thread. I like GTK a lot as I always prefer C over bloated (somehow) C++
 language. And GTK did very neat work too. I would think that many other
 people like GTK+ as me too.

At the risk of sounding like an elitist ass (not that this would be the
first time), if you think C++ is bloated, you have no business
evaluating the merits of a GUI toolkit.

-brian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDPHMh6XyW6VEeAnsRArbfAJ9lJscJF/19wjVCmL5EQAEfHtmxDACg8Jg+
IxwyxutlfyryVa+NqoQfqYA=
=Dr8X
-END PGP SIGNATURE-
___
Thunar-dev mailing list
Thunar-dev@xfce.org
http://foo-projects.org/mailman/listinfo/thunar-dev


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

2005-09-28 Thread 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