On Sat, Dec 06, 2014 at 06:44:01PM +0100, mutek wrote:
> On sabato 6 dicembre 2014 18:32:04 CEST, Mihamina Rakotomandimby wrote:
> >On 12/06/2014 04:57 PM, Hendrik Boom wrote:
> >>On Fri, Dec 05, 2014 at 02:54:09PM +0200, Vlad wrote:
> >>>I would propose that we do not waste any time with GDM, GNOME
> >>>or
> anything
> >>>else that has sprung out of that irresponsible organizations
> >>>other than gtk.
> >>I wasn't aware that GTK had anything to do with that organisation.
> >>Isn't it the Gimp ToolKit?
> >>And isn't the Gimp the GNU Image Manipulation Program?
> >
> >Yes, but the Gimp tool kit has been adopted by the GNOME
> >develoment team to be their toolkit too.
>
> whatever I saw in the industry...GTK it's not taken in account if
> compared with QT,MS-whatever,Java-whatever,HTML5-DOM-canvas-engines,

There are good reasons for that. As a (former) professional GTK+
developer, I have found out the hard way that it's unsuitable for most
projects. Nowadays, unsuitable for almost all projects outside GNOME.

> GTK did a very good job but seems invisible to the world out of the
> free softwares

That's because it's a terrible toolkit, and the number of people who
are experts with it is vanishingly small (and shrinking). It's not a
safe platform on which to build anything serious. Not because it
doesn't work, but because you can't easily hire people, and because
it's the least efficient and worst documented toolkit to work with.
If you want to achieve your own project's goals on time, this matters.

The C API is overly complex and fragile. You don't want to base your
project on a sandcastle. And the expertise required to use it is
very high. Implementing dynamic typing and manual vtable construction
rather than using C++ which does proper type checking? Just use C++!
In fact, you have to be an expert in C++ compiler internals just to be
able to understand and use it effectively. It's like being a master
carpenter and then willingly eschewing your workshop for a rusty swiss
army knife! While you could probably construct something with the
swiss army knife if you try really hard, the workshop will do a
faster, better, more professional job and let you get on with the job
rather than cursing at your inadequate tools every few minutes.

This is the reason it's not used; if I suggested using GTK+ to my team,
I'd be laughed out of the room (and for good reason). The bindings
like GTKmm are better but have their own problems, but eventually you
just run into all sorts of bugs, particularly as soon as you try to
use it cross-platform where the quality is seriously sub-par. But
that's all irrelevant due to the repeated and gratuitious API
breaks of recent times. And they were so eager to drop backward
compatibility, I can't even convert my GTK2 glade files to the new
format! All these problems add up to something which can't be used
seriously because its maintainers don't take it seriously; and it
coming under the care of the GNOME maintainers has made it an
order of magnitude worse than it already was (and it wasn't great to
begin with).

In short, if I want to write a quality, robust, maintainable, safe
UI, GTK+ doesn't even make it to the shortlist I'm afraid. It only
got established due to the Qt licensing in the late '90s and early
2000's; it's always been vastly inferior otherwise. And I say this
as someone who used to be a GTK+/GNOME fanatic primarily for
licensing reasons. After using it seriously in a commercial context,
it fell short on all counts. Nowadays I use Qt and am eternally
thankful that it works and I don't have to ensure the pain any more.

When I used GTK+, I spent about 75% of my time battling with the
innards of GTK+, GLib and GObject and other libraries like
libgnomecanvas. Because the documentation and quality of
implementation is *terrible*. And 25% on my own project's code: the
stuff I should have been spending 100% of my time on, and even that
included spending a lot of time with all the horrible GObject
boilerplate. And I ran into numerous bugs. And the turnaround for
fixing them was terrible, even when I supplied patches. The worst one
was closed a few weeks back. A tested and qa'd patch spent an *entire
decade* in the GNOME bugzilla before being CLOSED WONTFIX without
any review. You can't base a project on that level of uncertainly
when you're depending on this stuff working. And the flakiness of
the bindings means they can't paper over the deficiences
sufficiently to rely on them either. They all have their quirks which
vary from release to release; and across platforms.

After switching to Qt a few years back, I've spent ~95% of my time on
my own code, 4% reading the documentation and a very tiny amount
bugfixing. I encountered just one bug (on Windows), which was in
setting up an OpenGL debugging context. When I reported it, it had
already been fixed the day before and was in a point release a week or
so later. In short, it's a pleasure to develop with rather than an
exhausting battle, and it does genuinely work properly across
platforms. And the maintainers are friendly and responsive rather
than arrogant arseholes. In short, a night and day difference.

This sums up the experience well:
http://mirror.linux.org.au/linux.conf.au/2014/Thursday/83-Gtk_to_Qt_-_a_strange_journey_-_Dirk_Hohndel.mp4

> is there a very good reason why the free software world should
> continue to stick to GTK instead to start a rational QT fork to
> replace GTK? (it's not an obvius task of course and probably the
> necessary critical mass loves GTK)
> At the moment I consider Qt viable only if forked and granted by a
> true free foundation otherwise GTK wins because grants us true
> freedom consistency through the time

What? Qt has been freely licensed for several years now. No fork
required. It's LGPL 2.1 or GPL 3.0
(http://qt-project.org/doc/qt-5/licensing.html). It's easier to
contribute to than GTK+ and there are provisions for its freedom
if things happen to the current owners. And the licensing of GTK+
matters not one iota if its maintainers ignore and don't apply
needed patches since it makes the toolkit unusable for you without
them.

We used to use it because it had an acceptable licence and was the
"right" toolkit for "manly" C-only free software developers who loved
to do things the hardest way possible against all common sense. Just
because it's possible doesn't make it sensible. Sadly, reality
catches up and it really isn't a good choice today given that there
are vastly better options available.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800