LWN: Comments on "GTK++, stability, and the uncluttered future"

GTK++, stability, and the uncluttered future

glaesera — Wed, 28 Aug 2013 13:50:49 +0000

Boredom really is, what I need very often, too. So I am quite compassionate with projects, that still stick to GTK2.
At this time I use GNOME3.2 from Debian-Wheezy and think it is quite OK, only marginal problems appear, for example, when the cairo-dock interferes with fullscreen or almost fullscreen-windows or with popping up context-menus.
Nothing of that was reported yet, because it really seems marginal, though it slackens the workflow sometimes.
Today I found, that Windows that were dragged to the side of the screen to fill the right half, for example, cannot be altered in size, but only torn away from their side of the screen again, in order to continue their lives as normal windows.
Maybe it would be nice, if that half-screen-condition would be less of an exception.

GTK++, stability, and the uncluttered future

ScotXW — Thu, 22 Aug 2013 17:01:02 +0000

Up until recently I wasn't even aware, that clutter is a toolkit, like the other toolkits...

So I draw this two svgs: [1]. Is this correct? Anything to add or remove again? I see modern compositing but also modern 3D-gaming being important. A lean and mean design (Latency...) is important for both.

I watched the video from LCA2013 [2] Clutter 2 and GTK+4 and also some other stuff. I am not a programmer myself, and I do not plan to become one. But I do use software, and friends and friends of friends sometimes ask me 'bout their OS and how to fix it, and I began telling them to switch and use GNOME or Xfce instead of the evil OS or the other evil OS. ON either Debian stable or now on Fedora (because the newer the GNOME the better it seems to work, this means the less feature in-complete GNOME is... *cough*)

Out of curiosity I started snooping around the bases of the desktop and which one (Qt-based or GTK+-based) has the brighter future, i.e. can attract most talented core developers AND application developers. I still have no idea, but at least I draw those stupid SVGs to brings others like me more quickly up to speed. So, can you mend them, make them better, use them to explain the future?

[1] http://en.wikipedia.org/wiki/User:ScotXW
[2] http://conf.linux.org.au/schedule/30067/view_talk?day=thu...

GTK++, stability, and the uncluttered future

heijo — Thu, 22 Aug 2013 15:12:45 +0000

The problem of all this is that the GNOME brand and desktop are now dead after having been devastated and vandalized by McCann & co., and GTK+ is almost surely doomed without those.

The future is HTML5, Android and to some extent Qt.

GTK++, stability, and the uncluttered future

PhilHannent — Thu, 22 Aug 2013 11:29:03 +0000

To answer your last question. GTK 2 shouldn't need porting as it could run on XWayland: http://wayland.freedesktop.org/xserver.html

GTK++, stability, and the uncluttered future

tuna — Thu, 22 Aug 2013 10:58:50 +0000

Then help those apps move forward. You have the source and everything needed.

GTK++, stability, and the uncluttered future

torquay — Thu, 22 Aug 2013 06:24:44 +0000

I'm also rather confused by:

His answer historically was that GTK3 is awesome and everyone should port, but he said he has begun to doubt that. The truth is that GTK2 is stable and unchanging, even boring—but that is what some projects need. ... The real reason someone should port to GTK3 today, he concluded, is to take advantage of the new features that integrate the application with GNOME 3—but doing so means committing to keeping up with GNOME 3's pace of change, which is intentionally bold in introducing new features. ... Eventually, he said, he hopes that GTK+ will reach a point where the bold experiments are done.

So is GTK 3.x stable or not ? Specifically, if a given package is linked with GTK 3.8, is there a guarantee that it will work with GTK 3.10 ?

Or are certain specific parts of GTK 3 marked as unstable ?

On a related note, if people are not encouraged to port to GTK 3, what happens with GTK 2.x based applications when the switchover to Wayland happens? Is there going to be Wayland backend added to GTK 2 ?

GTK++, stability, and the uncluttered future

dvdeug — Sat, 17 Aug 2013 09:20:28 +0000

What does that have to do with anything? Things that are ahead of their time are often cannibalized by their more-popular siblings and left to die. Many of the languages of the 1960s were way ahead of Fortran and Cobol; not one of them is still used, while Fortran lives, with object orientation no less. (If you don't count C, at best a language of the tail end of the 1960s.)

GTK++, stability, and the uncluttered future

hunger — Fri, 16 Aug 2013 10:06:29 +0000

Thanks for that link, it is a very interesting read indeed.

I went ahead and added a Porting page to the Qt project wiki to collect pages like that and added that link for future reference.

GTK++, stability, and the uncluttered future

tpm — Thu, 15 Aug 2013 22:26:40 +0000

Most of the awkwardness of putting a video on screen is gone in GStreamer 1.0. You can now simply set the window handle/id on playbin, and it will proxy it to the video sink later. That's about 3 lines of code for a Gtk widget. I don't think that qualifies as "frickin' hard". In the old 0.10 days you had to do complicated things in a synchronous bus handler called from another thread etc., that's no longer required.

We certainly need nicer high-level API for playback, especially for Gtk+ users. A full-featured GtkVideoWidget with some nice API to control it would be great, whether in Gtk+ or elsewhere. Even the Qt folks have something already.

But all that is a different discussion really and not related to your claims why Totem switched to Clutter, since Totem doesn't even use any of clutter-gst's convenience API, it only uses the sink for output and still controls playbin directly. The savings in terms of lines of code were minimal (+282-856, 9ef416ce) btw, not least because it then had to copy'n'paste in a new widget (+498) to restore proper aspect ratio functionality "until we get a solution for this directly in ClutterGst" (f782e2e1).

Not that I think there's anything wrong with using Clutter, it's just that Totem didn't switch to it for the reasons you claim. It's simply the most sensible option for video rendering in a GNOME3 context given Gtk-3's massive lack in this area, which is hardly GStreamer's fault, and mostly a symptom of the Linux graphics stack having been in flux for the last few years.

In any case, I'm looking forward to your work on all this inside Gtk+.

GTK++, stability, and the uncluttered future

maxiaojun — Thu, 15 Aug 2013 16:52:07 +0000

Continue your lies: http://www.tmrepository.com/trademarks/uratroll/

GTK++, stability, and the uncluttered future

maxiaojun — Thu, 15 Aug 2013 16:48:07 +0000

BTW, the golden age of Linux GUI application has gone. There are many useful GUI applications （[1], [2] and many more) dead with random version GTK2 and often libgnome*.

New application should indeed go with HTML5 or Qt, which are much better documented and supported. Let the shoddy designers of GNOME continue to steal ideas from other people, continue to build majestic core Apps like Clocks.

1. http://i8086emu.sourceforge.net/
2. http://sourceforge.net/projects/gstm/

GTK++, stability, and the uncluttered future

ebassi — Thu, 15 Aug 2013 16:22:50 +0000

obvious troll is obvious. also, you fail at reading comprehension.

GTK++, stability, and the uncluttered future

ebassi — Thu, 15 Aug 2013 16:21:44 +0000

I think it's worth to reiterate that "small" and "simple" are relative terms.

an application is "small" or "simple" if it does not have a large quantity of custom widgets that handle presentation in a completely different way than the stock layout managers and widgets provided by the toolkit itself. Gimp, for instance, uses gtk for many of its UI elements, but the large chunk of the UI is built on very custom widgets, which occupy a very small niche of use cases. the example that Benjamin brought was the dockable widget — i.e. a widget capable of containing a set of tool boxes that can be rearranged by drag and drop. while it's a concept used in a certain set of applications, it's highly unlikely that we can add such widget inside gtk, because it would need to satisfy different use cases and then port all the applications using their own custom widget to the new, generic, one.

another point is that both LibreOffice and Firefox don't really use gtk at all, except for integration purposes on Linux. they both have their own toolkit, which may or may not draw something resembling the gtk style.

as the last few cycles of the 3.x branch demonstrates, gtk is getting a wealth of new widgets, as well as new layout managers; if a widget is used by various applications, and it expresses a common UI pattern, then it should definitely be included in the core toolkit.

GTK++, stability, and the uncluttered future

maxiaojun — Thu, 15 Aug 2013 16:15:47 +0000

From the code example, GTK+ should be referred as "GTK+, or the GNOME Toolkit, is a single-platform toolkit for creating graphical user interfaces.". Fix http://www.gtk.org/ please.

GTK++, stability, and the uncluttered future

drag — Thu, 15 Aug 2013 15:58:41 +0000

> E libs such as Evas really were way ahead of their time.

Hard to believe that when the E17 project has been around for longer then GTK2 and yet has a tiny fraction of the useful applications of GTK3.

I suppose it's the same sort of thing people bring up with Resier4 vs Btrfs as "being ahead of it's time".

GTK++, stability, and the uncluttered future

halla — Thu, 15 Aug 2013 14:28:45 +0000

I've never had to do such a port (fortunately), so I cannot assess how useful this guide is, but it was recommended to me as pretty useful: http://wiki.lxde.org/en/Migrate_from_GTK%2B_to_Qt .

GTK++, stability, and the uncluttered future

hunger — Thu, 15 Aug 2013 14:24:24 +0000

Thank you for explaining why projects like LXDE are considering to move from GTK2 to Qt. That must be a lot of work and a lot of relearning and I had been wondering why they are willing to do that for a while now.

GTK++, stability, and the uncluttered future

ebassi — Thu, 15 Aug 2013 11:34:34 +0000

Now perhaps some can see that Gnome is _still_ trying to catch up.

GNOME and GTK haven't been "catching up" to EFL. it's actually pretty much the other way around, and to be fair, it's going to be a long time before the EFL set of bajillion libraries can compete in terms of design, engineering practices, and implementation, with the libraries in the GNOME platform.

I think you missed the point that Clutter has been available and used for 7 years; all this time, it has been integrated with the GNOME platform. in order for Clutter and GTK to get better, and get more features and users, they need to merge. Clutter has to turn into something at the very core of the platform diagram, not as something that you can opt in.

GTK++, stability, and the uncluttered future

ebassi — Thu, 15 Aug 2013 11:28:01 +0000

sure, and as I said in the talk, you can easily witness the amount of code that the Totem maintainer was able to remove just by using Clutter and the Clutter-GStreamer API.

the main objection is not that putting a frame of a video on the screen is impossible with GStreamer: it's obviously possible. the objection is that it's frickin hard - and, to be fair, quite unnecessarily so. there is a distinctive lack of convenience API in that sector, which is why people started using Clutter-GStreamer as soon as it was published, 6 years ago.

GTK++, stability, and the uncluttered future

zenaan — Thu, 15 Aug 2013 10:51:06 +0000

For future reference, and for those wishing to research, I just added the "Scene graphs in user interfaces" section which is primarily a list of various canvas libraries, to:
http://en.wikipedia.org/wiki/Scene_graph

GTK++, stability, and the uncluttered future

tpm — Thu, 15 Aug 2013 08:20:05 +0000

The reason Totem uses Clutter is not "because putting a video on screen with GStreamer is such a pain", but because it's the easiest way to draw stuff on top of videos, which you generally can't do with e.g. xv overlays. Totem managed to put videos on screen with GStreamer long before Clutter even existed.

GTK++, stability, and the uncluttered future

zenaan — Thu, 15 Aug 2013 07:13:22 +0000

> Ultimately, though, Bassi does think that GTK+ needs to start adding a scene graph library
..
> The scene graph is important because GTK+'s current drawing functions make it difficult to tell what element the cursor is over at any moment. Making each GTK+ widget a Clutter-based actor would make that determination trivial, and provide other features like making widgets CSS-themable

Welll ...
"Evas is a clean display canvas API that implements a scene graph," see
http://trac.enlightenment.org/e/wiki/Evas

Back in the day Rasterman/Carsten implemented some GTK+ theme engines and more. E libs such as Evas really were way ahead of their time. Now perhaps some can see that Gnome is _still_ trying to catch up. That's how it looks to me anyway.

Gesture support?

Scalable/dynamic, declarative UIs?

Multiple platforms?

Clean architecture, comprehensive and well thought out library layers ... the list goes on and on.

There was even a time in my memory when it looked like it might be possible that Gnome and E might merge.

Anyway, I think it might greatly behoove Gnome/GTK+ developers to take another look at the Enlightenment libs. Really, a lot of ground has been thoroughly trod over in the E camp.

I would very much appreciate any feedback here on LWN re E libs etc.

GTK++, stability, and the uncluttered future

tetromino — Thu, 15 Aug 2013 03:21:21 +0000

The way I read it, gtk developers are targeting the new widgets they have been adding primarily at small and simple applications by giving these widgets only the most commonly requested features. Gimp and other large applications with unusual UI requirements are expected to implement their own widgets if they need something with extra functionality which no other project would ever be likely to use.

GTK++, stability, and the uncluttered future

tnoo — Thu, 15 Aug 2013 02:46:52 +0000

I'm utterly confused.GTK used to mean "GIMP Toolkit", and was written to suit the GIMP, Based on this effort the GNOME desktop evolved. But here it is said that applications like GIMP would be unlikely to use GTK?