User: Password:
|
|
Subscribe / Log in / New account

Clasen: Introducing GtkInspector

Clasen: Introducing GtkInspector

Posted May 19, 2014 9:00 UTC (Mon) by jospoortvliet (subscriber, #33164)
In reply to: Clasen: Introducing GtkInspector by tristanb
Parent article: Clasen: Introducing GtkInspector

The coupling is great if you develop GNOME Apps like clocks and image viewers. If you're an actual third-party application developer (or theme developer or anything else non-core-GNOME) it is a pita.

So yes, it IS great for GNOME, just not for GIMP/Inkscape/GCompris/XFCE/LXDE/etc and that's why several of these are moving over to Qt.

We get innovation on the desktop shell level (GNOME certainly does innovate there) and apps moving cross-platform and to newer UI development technologies (QtQuick and QML) so I guess it is a win for everybody...


(Log in to post comments)

Clasen: Introducing GtkInspector

Posted May 19, 2014 9:47 UTC (Mon) by tristanb (guest, #85904) [Link]

>We get innovation on the desktop shell level (GNOME certainly does innovate there) and apps moving cross-platform and to newer UI development technologies (QtQuick and QML) so I guess it is a win for everybody...

Agreed. My personal feeling is that GTK shouldn't try to be a "cross-platform toolkit" in the same way it has in the past, attempting to emulate native look & feel on Windows and Mac. Qt fills that niche very much better than anything else on the market, GTK cannot compete and shouldn't try to.

Instead, GTK should focus on *being a native platform*, just as Cocoa is for the Mac. Nobody complains that their Cocoa apps don't run on Windows; if they want a single, cross-platform UI that looks pretty good everywhere, they use Qt.

(That's not to say that that GTK apps shouldn't be able to run on Windows or MacOS --- just that the GTK devs shouldn't try to make them exactly resemble native apps, in the same way that Windows iTunes and Safari still feel/felt unashamedly like Cocoa apps.)

In short, let GTK be "opinionated".

Clasen: Introducing GtkInspector

Posted May 20, 2014 22:25 UTC (Tue) by rleigh (guest, #14622) [Link]

While I think this is indeed the direction things are going in, I think it may be the death knell for GTK.

I'm working on developing cross-platform free software libraries and applications, both for my paid job and for my own projects. They all build on Linux, FreeBSD, MacOS X and Windows and build using all of GCC, clang, mingw and MSVC. They are typically using C++(11) and Boost and other standard free software C and C++ libraries for the core functionality, and Qt for the UI where applicable. In other words, the free software I produce is available to about as wide an audience as I could hope for by deliberately making the software as portable as I can (with not all that much extra effort). I would have liked to have had the choice to use GTK+ here, but it's no longer a contender, lacking robust cross-platform support for MacOS and Windows, which is a shame. And it's increasingly unsuitable for non-GNOME Linux development too. And FreeBSD isn't exactly cared for either.

The question I'd like to pose is that, if GTK is not for serious cross-platform application development, what *is* it for? At a stroke, being Linux-only and GNOME-only eliminates a huge number of application developers. Probably most of them. And these are the people who will be pushing and testing the toolkit to the limits, and also hacking on it to improve it, add new widgets and fix bugs. Even if they aren't core maintainers. I was once one of these people for GTK+, but not since it became clear it wasn't being maintained well, and didn't have a future. And I take no pleasure in saying that--I invested significant time, both my own and company time, over the course of several years, in working on GTK+ applications and on GTK+/GLib including a lot of testing and bugfixing of its Cygwin and MinGW support across the whole set of GTK+ and base GNOME libraries (again: for cross-platform development back when we had hopes that GTK+ was good for such things). Ultimately, that was a wasted effort given where it's led to.

I don't think the Cocoa comparison is good for GTK+. It's a niche toolkit which you would use if you only want to target MacOS. True for some applications for sure, since MacOS has a large number of users, but not the majority. By restricting GTK+ to Linux/GNOME, you similarly limit the scope for its use and hence relegate it to a niche. And in the wider picture, GNOME on Linux is a very tiny niche. Very few application developers will wish to limit themselves in this way--the focus is on the application, not tying oneself to a barely significant desktop for little tangible benefit. GTK+ may well survive in this niche, but without any real incentive to use it, it's not likely to prosper.

Clasen: Introducing GtkInspector

Posted May 21, 2014 14:09 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> Ultimately, that was a wasted effort given where it's led to.

I'm sorry that you think so but if you got utility out of it at the time commensurate with the work you put into it, even if it isn't the future, then it wasn't a wasted effort. We don't need to be so attached to our particular systems that we are excessively loss-averse to changing how they work or changing to different systems altogether if the first one doesn't work out for whatever reason.

If GTK+ doesn't work out and gain significant traction outside of the GNOME desktop internal utilities, it still had a good run and it was useful to people for a time.

Clasen: Introducing GtkInspector

Posted May 23, 2014 9:16 UTC (Fri) by rleigh (guest, #14622) [Link]

In this case I'm afraid so say I got precious little utility out of it, after putting in many months of effort, so I do regard it as an unfortunate waste of time. Other than a salutory experience in how not to do things.

For both GTK+ applications and programs making use of GLib/GObject, I ended up spending over half my time working on and around bugs in the libraries and in the overhead of using GObject (I really can't stress how much the maintenance burden seriously hinders refactoring and introduces bugs). That's time I should have spent working on the applications themselves, so that's a serious cost to pay. Taking a few weeks out to convert some of them to pure C++ was one of the best decisions I have made, and really made a dramatic difference to their robustness and maintainability, and hence the time I could devote to actually developing the applications as opposed to dealing with GObject issues.

GObject requires "heroic coding", the attitude that in the face of a fragile API, it's not important because "I'm such an amazing programmer, I'll just not make any mistakes". Now I'm older and perhaps a bit wiser, I increasingly see the great value in having the compiler pick up as many errors as possible; having it silently pass over errors is simply unacceptable. I know that I'll make some stupid mistakes, and I want them to be caught early. Have you read the sources for a big application using GObject, such as Gnumeric? I have the utmost respect for Jody Goldberg, it's a great piece of work. But there's a reason people aren't writing more GTK/GNOME applications: this stuff is terrible to maintain and refactor. The same code in C++ would be more readable, maintainable and robust, and not just by a small amount.

Clasen: Introducing GtkInspector

Posted May 23, 2014 18:53 UTC (Fri) by welinder (guest, #4699) [Link]

> Have you read the sources for a big application using GObject, such
> as Gnumeric?

I have. In fact I wrote most of it.

There isn't a whole lot of GObject code in Gnumeric. The dialogs are all made with Glade with C code to implement the things that happen when you push buttons. _That_ code wouldn't look at whole lot different in any other language.

The hairy parts of the Gnumeric code are (1) the dependency code that tracks which cells depend on which other cells, and (2) the quad tree used to store cell formatting. Neither is related to GObject and both would look roughly the same if written in C++.

Re. refactoring: our graph engine has long been factored out and is used in other applications.

That said, I do agree that Gtk+ and the never-ending stream of ABI breaks and "deprecations" that come with it is a pain. I think that's a problem with the current set of Gtk+ maintainers more than with Gtk+ itself.

Clasen: Introducing GtkInspector

Posted May 19, 2014 22:31 UTC (Mon) by Wol (guest, #4433) [Link]

Except what does GTK stand for? As in GTK and not GTK+ etc. Yes, that's right - *Gimp* Tool Kit.

It was born as the toolkit used to implement Gimp, so it's a shame it's now considered unsuitable for the very use-case it was created to fill ...

Cheers,
Wol

Clasen: Introducing GtkInspector

Posted May 20, 2014 7:55 UTC (Tue) by jospoortvliet (subscriber, #33164) [Link]

That's what is being pointed out in this thread, too:
http://thread.gmane.org/gmane.comp.kde.devel.core/83320/f...

Clasen: Introducing GtkInspector

Posted May 22, 2014 18:00 UTC (Thu) by joshl (subscriber, #91369) [Link]

Clasen: Introducing GtkInspector

Posted May 24, 2014 7:11 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]

I wonder - will that port ever catch up to the changes in GTK or will it be finished by the time GTK4 is out?

Clasen: Introducing GtkInspector

Posted May 20, 2014 2:57 UTC (Tue) by coulamac (guest, #21690) [Link]

Citations needed. Where have the GIMP, XFCE, and GCompris stated that they would like to switch to Qt? (hey, it could be true, but it's news to me).

GTK had a nice ecosystem of desktops, including GNOME, XFCE, Mate, and Cinnamon.

GTK development has been very active. This article is just one sign of that activity. Others include new widgets, more Wayland integration, better documentation, closer bundling of GLADE, better integration with other operating systems, a new canvas from the makers of Clutter, etc. It's actually a rather exciting time to be working on/using GTK.

You don't like C? That's cool. Use C++ with GTKmm. Python, JavaScript, and Vala (a Java/C# like language) bindings are also well developed. As another poster commented, it is much easier to subclass in these other languages.

Qt is nice. So is GTK. I really don't understand all the energy here devoted to killing GTK. Developers enjoy developing it. Users enjoy using it. Yay for them. Why attack their preferences? Do you think that somehow the attack will make Qt better?

Clasen: Introducing GtkInspector

Posted May 20, 2014 14:01 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> Qt is nice. So is GTK. I really don't understand all the energy here devoted to killing GTK. Developers enjoy developing it. Users enjoy using it. Yay for them. Why attack their preferences? Do you think that somehow the attack will make Qt better?

GTK needs to go away because it hampers interoperability. When I write an application and I want to use a GTK widget written by person A and a Qt widget written by person B, I'm fucked, I can't use them together. And users end up with inconsistent desktops because GTK to this day cannot use the KDE file picker dialog. Perhaps they'll fix that some day (I doubt it), but that's just the tip of the iceberg.

Clasen: Introducing GtkInspector

Posted May 20, 2014 18:46 UTC (Tue) by coulamac (guest, #21690) [Link]

If I understand you correctly, you do not like certain of GTK's widgets and, because you use programs which in turn use GTK, you are irritated that you must use those widgets. This, I understand, is particularly irritating because the corresponding Qt widgets, which you prefer, differ in some material fashion.

As I see it, you have three realistic options: 1) write code that would aid GTK's interoperability widget-wise with Qt (to the extent it's possible); 2) stop using GTK programs and only use Qt ones; or 3) stop worrying and learn to love GTK as well as Qt.

You propose 4): everyone abandon GTK and refactor their projects to use Qt instead of GTK. I assume you propose 4) because there are certain GTK programs you will not abandon because there is no Qt equivalent or one not suitable to your needs.

One problem with 4), however, is that you must convince the developers of each of those programs to make the switch, which is not a trivial undertaking. Those developers may like developing in GTK. Those developers may actually help develop GTK. Those developers may, at the very least, be indifferent to the toolkit and, therefore, would not like to incur the pain and suffering of changing from one toolkit to another.

The other problem with 4) is that there may be users who prefer the way GTK widgets work. To them, the problem may actually be the opposite: they get irritated when they work with Qt programs that work in subtle (or obvious) ways differently than what they are used to because of the toolkit. You are asking them to abandon what they like to accommodate what you like.

Your proposal 4) is unrealistic. Further, even if everyone (developers and users alike) did magically agree with you, the process of refactoring each program and each desktop (GNOME, XFCE, Cinnamon, Mate, etc.) to Qt would likely take years. That is years of development wasted in otherwise quashing bugs, adding features, polishing interfaces, and optimizing code.

Logically, your position does not make sense and would not substantially further the Linux desktop ecosystem, at least not anytime soon. We would be better served cheering on the different projects, no matter what language or widget set they depend on, so long as the project promotes free software. The discourse here, I fear, just puts forward stop energy.


Clasen: Introducing GtkInspector

Posted May 22, 2014 9:08 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]

here for gcompris. They hope to finish the Qt port at the Randa meeting being organized this summer.

No idea about GIMP and XFCE, I'm sure some people there are looking at it but I don't think the entire projects are ready for that - yet. LXDE has already moved, as you know...

And sure, GTK development is active. It does form the base for GNOME Shell and there, lots of interesting stuff happens. But not much interesting happens for non-GNOME projects, that's the thing...

About attacking, well, the thing is: GTK simply isn't a good choice for a independent, third-party app. App developers moving to Qt would benefit users, both because Qt integrates far better in non-GNOME-Shell desktops and because Qt is cross-platform, higher quality and easier to use. It would be good if that was public knowledge, so people judging potential Linux development don't try GTK and come away with a feeling that the Linux desktop tech is lightyears behind the competition. It isn't, as long as you try Qt...

Of course, for writing a simple app for GNOME Shell, I'm sure GTK is far easier and better than Qt as it offers all these little conveniences that the GNOME Shell designers want you to use. That's fine, but many of these features break interoperability (see the huge discussion about CSD breaking GTK apps running on a non-GNOME-shell desktop for example). So if you want your app to be used outside of Shell - use Qt.

Clasen: Introducing GtkInspector

Posted May 23, 2014 1:57 UTC (Fri) by coulamac (guest, #21690) [Link]

Your preferences do not equal everyone's preferences. Just as there are current developers on Linux who prefer to use GTK over Qt, there may be *new* developers who will also prefer GTK. One size does not fit all, nor does one toolkit satisfy all developers. If a new developer should try GTK and not take a liking to it, there is nothing stopping her from trying Qt, which is hardly a secret, et vice versa. Your concern that GTK will give Linux a bad name seems unfounded at best.

Your attempt to ghettoize GTK to Gnome Shell (and small apps) is also unfounded. GTK predates Gnome Shell by many years and is used by multiple desktops. XFCE uses GTK. Mate uses GTK. Cinnamon uses GTK. You ignore this evidence when you insist that GTK is only suitable for, in essence, Gnome 3. Large programs use GTK. The GIMP does. Inkscape does. Evolution does. Nautilus does. Nemo does. If you include GLib in GTK, GStreamer uses the framework. These are just a few examples.

I fear you are continuing to fight the KDE/Gnome wars of the last decade. That's sad because many people worked very hard to put such destructive attitudes behind us. See the foundation of freedesktop.org or the joint adoption of DBus or the joint Akademy/GUADEC conferences. This does not have to be a zero-sum game. We can encourage each other and support each other. Free software can prosper if we work together rather trying to destroy the competition. Your efforts here do not help anyone, even Qt.

Clasen: Introducing GtkInspector

Posted May 23, 2014 16:32 UTC (Fri) by HelloWorld (guest, #56129) [Link]

Qt for X11 switched to the GPL in 2000, Qt for Windows switched in 2005 and the first LGPL release was in 2009. Most of the projects you mention were first released before 2000 or forked from such projects, so it's fair to assume that they first chose GTK for licensing reasons and then stuck with it because of the huge amount of work that porting would involve. IOW, the existence of these projects doesn't really say anything on the current situation.

What does say something is that projects like Subsurface, Wireshark or VLC are migrating away from GTK _despite_ the amount of work that involves.

> I fear you are continuing to fight the KDE/Gnome wars of the last decade. That's sad because many people worked very hard to put such destructive attitudes behind us.
I don't see anything destructive in his comments.

Clasen: Introducing GtkInspector

Posted May 24, 2014 7:38 UTC (Sat) by mbunkus (subscriber, #87248) [Link]

Quite correct for my little project (MKVToolNix) at least. Back in 2001 when I started working on a GUI for one of the command-line applications I looked at the various cross-platform toolkits available at the time. Luckily I'm using C++ so the selection was more broad, but the only three contenders left were Qt, F… something (can't remember the name) and wxWidgets (which uses GTK+ on Linux, MS' own stuff on Windows). I only chose wxWidgets due to Qt not being available for OSS projects on Windows at that time.

Nowadays I'm trying to switch, too, for many of the reasons listed in these comments, even though re-writing the whole application from scratch is a huge amount of work. But it's more than worth it.

Clasen: Introducing GtkInspector

Posted May 24, 2014 9:24 UTC (Sat) by patrick_g (subscriber, #44470) [Link]

I use this opportunity to thank you for MKVToolNix. It's a reliable and very useful software.
Thanks a lot!

Clasen: Introducing GtkInspector

Posted May 23, 2014 18:21 UTC (Fri) by boudewijn (subscriber, #14185) [Link]

"Your attempt to ghettoize GTK to Gnome Shell (and small apps) is also unfounded."

It's what the GTK developers themselves say: "The answer is that GTK+ is primarily intended to be used on the GNOME desktop, using X11 as the backend." and "Finally, he said, people ask whether GTK+ is focused on creating "small apps" or "large applications," and his answer is "small apps." In other words, GTK+ widgets are designed to make it easy and fast to write small apps for GNOME: apps like Clocks, rather than GIMP or Inkscape."

See http://lwn.net/Articles/562856/.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds