LWN: Comments on "GTK+ 3.4.0 released"

GTK+ 3.4.0 released

rahulsundaram — Tue, 10 Apr 2012 18:27:17 +0000

No. Not the same. FSF is a nonprofit and the agreement gives legal guarantees that the code won't be used in proprietary projects. Also several GNU projects don't demand any agreements

GTK+ 3.4.0 released

Zizzle — Tue, 10 Apr 2012 16:48:56 +0000

> the wheel was kinda problematic, especially when used on touchscreens

The new GNOME/GTK motto?

If it doesn't work on touch rip it out?

Desktop users be damned, it's all about touch screens.

GTK+ 3.4.0 released

Zizzle — Tue, 10 Apr 2012 16:45:14 +0000

But so does GNU/FSF.

GTK+ 3.4.0 released

schabi — Sun, 01 Apr 2012 08:52:10 +0000

Does anyone know the state of gtk#?

http://www.gtk.org/language-bindings.php indicates that GTK# is the only "official" language binding which starved at version 2.12, but on the other hand, the table seems not to be updated for gtk+ 3.2 and 3.4.

GTK+ 3.4.0 released

rahulsundaram — Fri, 30 Mar 2012 18:21:37 +0000

I understand your perspective and don't think removing features is a good solution in general but I am willing to accept that in some cases especially in major revisions and in this specific instance, I don't know the value of it and reserve judgement. I don't think the use of fake transparency in the past is a good justification for retaining features now however. It is a era of poor and ugly hacks to overcome stagnation of XFree86, I rather forget.

GTK+ 3.4.0 released

marduk — Fri, 30 Mar 2012 18:14:36 +0000

Perhaps I shot off too quickly.

What I was saying was.. in the "old days" despite the "performance/quality" issues with fake transparency, some developers apparently thought it was worth it to create/add this so-called feature.

The justification we're given for the eye-dropper tool is just the opposite: that it's too complex/finicky/not-universally-available for a feature that is *already* implemented. And so the baby gets thrown out with the bath water.

GTK+ 3.4.0 released

marduk — Fri, 30 Mar 2012 18:09:23 +0000

So are you saying as a user we should expect less (I am a user)?

As a user, I had an eye dropper tool... less than a week ago, and I didn't notice any performance or quality issues. Now I don't have that tool. Perhaps you can cite the bug report[s]/mailing list threads pertaining to user complaints of performance/quality issues with the eye dropper tool.

GTK+ 3.4.0 released

rahulsundaram — Fri, 30 Mar 2012 17:58:25 +0000

Yes. Precisely. The standards of what people excepted from computers and Linux in particular has changed so drastically in the last few years. Users won't put up with that kind of performance or visual quality anymore.

GTK+ 3.4.0 released

raven667 — Fri, 30 Mar 2012 17:56:35 +0000

I wouldn't say that nobody complained about that old method of "transparency", I would say that maybe standards were lower then and people were more desperate for bling. Window dragging performed poorly in that environment as I recall and it was all to easy to see the ugly limitations when the "transparency" wouldn't work with overlapping windows or with animations running in the root window.

GTK+ 3.4.0 released

marduk — Fri, 30 Mar 2012 17:48:50 +0000

Yeah, it's kinda funny because, back in the day before there was compositing, programs like terminals would take a snapshot of the entire screen in order to give the illusion of transparency, and it did so frequently (for example when moving the terminal window) and nobody complained. But now to ask it be done once just to get the color of a on-screen pixel and it's suddenly not performant enough to justify. *sighs*

GTK+ 3.4.0 released

blujay — Thu, 29 Mar 2012 22:16:28 +0000

> the wheel was kinda problematic, especially when used on touchscreens

Fail. Touchscreens require separate UI. (cf. Windows 8, Metro)

> yes, the eye drop picker was removed because it was hard to justify the use case in a generic toolkit, after we ignored user feedback

FTFY.

> plus, the code was seriously iffy: in a composited environment you cannot get a pixel from the root window and expect that pixel to be exactly what you see on screen. plus, reading back from the GPU is always a synchronisation point, and it can be expensive, so you really want to do it at the right time.

Translation: "The code wasn't pretty enough, and we don't feel like beautifying it, so we ripped it out. Code elegance > usefulness."

I hate to be abrupt, but this is what it boils down to--developers' personal preferences over users' needs. That's reasonable for volunteers, except when it comes to removing existing functionality. Being responsible for a piece of code ought to entail making sure it continues working as expected, in spite of redesigns or rewrites.

GTK+ 3.4.0 released

oak — Thu, 29 Mar 2012 20:01:58 +0000

Regarding the "industrial strength", the smaller widgets sets have fairly large gaps in their internationalization & accessibility support compared to Gtk and Qt.

Supporting UTF-8 or some other unicode encoding is just a first small step in internationalization and proper accessibility support is a requirement for software used in government.

GTK+ 3.4.0 released

renox — Thu, 29 Mar 2012 12:31:06 +0000

> That said, if there's no other way to do it, the colour picker should just take a screenshot of the entire screen and use that. It sucks, but at least it's not a regression.

Hum, why does it suck?
Reading from the GPU is slow but noone cares one bit about the colour picker's performance!

GTK+ 3.4.0 released

daenzer — Thu, 29 Mar 2012 12:24:16 +0000

The problems you mention might apply when reading from *application* windows, but not when reading from the root window (which is also the obvious way to get a screenshot).

GTK+ 3.4.0 released

cortana — Thu, 29 Mar 2012 12:11:45 +0000

The user clicks on a window, and you can get the colour of the pixel that was clicked, but that's no longer enough to know what colour the user sees on screen. That window could be set to 50% opacity, or it could be overlapped by the shadow drawn around another window on top of it. I guess if the composite manager could even decide to rotate the window, so that the pixel clicked on screen is actually coloured by combining the surrounding pixels transformed and blended into each other during the rotation.

That said, if there's no other way to do it, the colour picker should just take a screenshot of the entire screen and use that. It sucks, but at least it's not a regression.

GTK+ 3.4.0 released

daenzer — Thu, 29 Mar 2012 11:14:31 +0000

> in a composited environment you cannot get a pixel from the root window
> and expect that pixel to be exactly what you see on screen.

Why not? The root window is still what's being displayed, compositing merely changes how its contents are drawn.

GTK+ 3.4.0 released

scientes — Thu, 29 Mar 2012 03:29:40 +0000

I was also referring to the previous sentences in the paragraph, which stressed the attributes of the LGPL

> GTK+ is free software and part of the GNU Project. However,
> the licensing terms for GTK+, the GNU LGPL, allow it to be
> used by all developers, including those developing proprietary
> software, without any license fees or royalties.

However, I do agree that my post was not clear in this.

GTK+ 3.4.0 released

scientes — Thu, 29 Mar 2012 03:20:07 +0000

oh, and XUL as well (which is also in the process of being ported to GTK 3)

GTK+ 3.4.0 released

scientes — Thu, 29 Mar 2012 03:15:36 +0000

> or wxWidgets

wxWidgets uses GTK, at least on Linux (and GTK 2 ATM, although a port is in process)

GTK+ 3.4.0 released

ekj — Wed, 28 Mar 2012 20:30:26 +0000

Taking a full screenshot to extract the color for a single pixel is vastly preferable to killing useful functionality. The performance doesn't much matter, I spend several seconds interacting with the dialogue, if getting the color takes 10ms or 1000ms, is damn-near irrelevant.

If you can do it faster, then go for it.

To me it seems like you're saying you've built a platform where even common and trivial things that have been taken for granted for decades, is now so hard you choose to drop the feature instead. That doesn't exactly instill confidence in the platform.

Come now: "what color is the pixel at x,y" should *not* be an unanswerable question in a grapical user-interface.

GTK+ 3.4.0 released

Cyberax — Wed, 28 Mar 2012 20:22:06 +0000

Bookmarked!

GTK+ 3.4.0 released

drag — Wed, 28 Mar 2012 20:21:05 +0000

> As you may have figured out,

Na. You really are spawn of satan for indirectly insinuating that the widget used in the a particular desktop preferred by certain peoples may be less then optimal compared to the project you spent a considerable portion of your life working on.

This sort of stuff is unforgivable. I am sure that people will be remembering your transgressions for years to come.

GTK+ 3.4.0 released

mclasen@redhat.com — Wed, 28 Mar 2012 18:27:53 +0000

As you may have figured out, this is pretty much boilerplate text that I've just been copying from old release announcements for a long time. I agree that it is overdue for a refresh.

I'll make sure that the next GTK+ release announcement comes with a more accurate self-description.

Thanks for pointing this out,

Matthias

GTK+ 3.4.0 released

Cyberax — Wed, 28 Mar 2012 17:28:02 +0000

Nope.

You can certainly use gvim with GTK+ everywhere, but vim also supports native Win32 (and even Win16!): http://code.google.com/p/vim/source/browse/src/gui_w32.c and even native X11.

GTK+ 3.4.0 released

mathstuf — Wed, 28 Mar 2012 17:21:43 +0000

> GTK is mostly used right now in Linux/*BSD and it probably should be somewhat of a priority to support them.

Doesn't gvim use GTK+ on all of the target platforms?

GTK+ 3.4.0 released

sorpigal — Wed, 28 Mar 2012 17:07:27 +0000

I say it like this:

less is more, but more; most is more than less

Of couse it isn't strictly true by these measurements:


$ man most | wc -c
15369

$ du -sh /usr/bin/most
60K     /usr/bin/most

GTK+ 3.4.0 released

Cyberax — Wed, 28 Mar 2012 16:46:58 +0000

>yes, let's read back the whole screen, however big it is, for getting the 32 bits that are inside 1 pixel.

That's what I have to do right now. Manually. So I completely fail to see the problem.

Do a screenshot if you need. If you can somehow determine pixel color without making a screenshot - so much the better.

GTK+ 3.4.0 released

ebassi — Wed, 28 Mar 2012 16:26:37 +0000

yes, let's read back the whole screen, however big it is, for getting the 32 bits that are inside 1 pixel.

anyway, supporting this feature correctly opens up another interesting issue of platform integration; gnome-screenshot currently asks the Shell for the data, because the compositor owns every pixel you're seeing on the screen, and X11 doesn't any more; so, on GNOME 3, it would work to ask the compositor for a single pixel. obviously, now, we have to negotiate with every other compositor, on the various platforms (Mac OS and Windows, mostly, but Wayland is coming up fast) that we support.

it's not as easy as it was in 1997, mostly because the platforms that we target are not as simple as they were 15 years ago.

GTK+ 3.4.0 released

Cyberax — Wed, 28 Mar 2012 14:34:49 +0000

>I'm very happy that "your screenshot tool" works. now, go and try make it work on all the gtk platform, in every potential combination of environments, and future-proof it so that it exposes an API that may have to be frozen for the next 5 years.

Then I suggest removing the color picker altogether. After all, GTK is used on e-ink devices which can't display color at all! Better remove it ASAP.

I really really don't care about some obscure platforms (GTK on DirectFB? Just watch me ignoring it!). GTK is mostly used right now in Linux/*BSD and it probably should be somewhat of a priority to support them.

GTK+ 3.4.0 released

man_ls — Wed, 28 Mar 2012 14:30:58 +0000

As in beer? Yes. As in speech? Yes. As in software? It should; I refer you to this week's excellent quotes of the week, particularly to Greg KH's.

So, in a word: yes, it's free. It may not be effortless though.

GTK+ 3.4.0 released

nhasan — Wed, 28 Mar 2012 13:32:44 +0000

I believe the word is "truthiness" not truthfulness :)

GTK+ 3.4.0 released

man_ls — Wed, 28 Mar 2012 13:05:03 +0000

This is fun:

$ du -sh /bin/more /bin/less
32K	/bin/more
124K	/bin/less

Misinform?

niner — Wed, 28 Mar 2012 11:39:44 +0000

When someone says something he knows not to be true we call that a "lie" and the one who said it a "liar". Simple as that.

Of course there's still the next to 0 possibility, that he actually didn't know about all the other free toolkits which are 100 % free-of-cost, open source and industrial-strength (whatever that means exactly). But even that would not reflect too well on him. Especially since one shouldn't make such absolute statements if one has never even a single look outside his own project.

GTK+ 3.4.0 released

dgm — Wed, 28 Mar 2012 10:41:12 +0000

> I kinda suspect Matthias does this on purpose so that the bikeshedders get something to argue about with the KDE zealots and it's easy for us developers to ignore those threads.

If that is true, then he's simply of the passive-agressive kind. If it's not, then he's a little bit too pretentious and self-contempt. He clearly cannot plead ignorance here. In any case, it only makes him (and GTK+ by extension) look bad.

GTK+ 3.4.0 released

Pawlerson — Wed, 28 Mar 2012 07:47:32 +0000

What he does is misinformation.

GTK+ 3.4.0 released

ekj — Wed, 28 Mar 2012 07:13:59 +0000

I have no idea if it's easy. But taking a screenshot works reliably in a number of gtk-applications, and has for many years, including the first gtk-application of them all, Gimp.

It seems you're saying "Taking a screenshot is too difficult", if that's really the case, it's indicative of a problem. This is functionality that average users have expected for decades.

GTK+ 3.4.0 released

rahulsundaram — Wed, 28 Mar 2012 06:58:02 +0000

That's just not a honest argument since it is not a problem limited to one organization. If Qt project requires a contributor agreement, the direct consequence of it cannot be dismissed.

GTK+ 3.4.0 released

halla — Wed, 28 Mar 2012 06:55:01 +0000

Then it's your company that requires the hoops, not the Qt project.

GTK+ 3.4.0 released

ebassi — Wed, 28 Mar 2012 06:46:28 +0000

My screenshot tool does that just fine.

have you even read what I wrote, or are you in write-only mode? just writing for shits and giggles, eh?

I'm very happy that "your screenshot tool" works. now, go and try make it work on all the gtk platform, in every potential combination of environments, and future-proof it so that it exposes an API that may have to be frozen for the next 5 years.

but it's obviously easy, because Cyberax did it.

GTK+ 3.4.0 released

rahulsundaram — Wed, 28 Mar 2012 06:45:23 +0000

I wouldn't call anything that requires a contribution agreement to be extremely simple since it often involves lawyers to review and sign off on the process and that is sometimes difficult if not impossible if you are a employee of a organization not tuned to all this. That makes it less open. The dominance of a single vendor is the usual end result.