I've never done UI myself other than some tkinter and awt, gtk sounds
terrible.
On Dec 6, 2014 11:51 PM, "Roger Leigh" <rleigh@???> wrote:
> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
::
Re: [Dng] GTK
