Wireshark switches to Qt [LWN.net]

First steps towards desktop consolidation?

Posted Oct 17, 2013 18:48 UTC (Thu) by proski (subscriber, #104) [Link] (23 responses)

It looks like we are seeing the beginning of desktop consolidation. GNOME is fragmenting and slipping into irrelevance, light-weight desktop environments are switching to Qt, popular standalone applications are switching to Qt as well. There will be still competing technologies, just on different levels.

First steps towards desktop consolidation?

Posted Oct 17, 2013 19:15 UTC (Thu) by Felix.Braun (guest, #3032) [Link] (13 responses)

While I share the general sentiment that Qt is gaining momentum relative to GTK+, I think it is a bit early for this conclusion.

First steps towards desktop consolidation?

Posted Oct 17, 2013 19:52 UTC (Thu) by ncm (guest, #165) [Link] (12 responses)

When Cinnamon switches to Qt, we will know how it all will end. When Gnome itself switches, the transition will be complete.

First steps towards desktop consolidation?

Posted Oct 17, 2013 20:52 UTC (Thu) by atai (subscriber, #10977) [Link] (10 responses)

These probably will never happen

First steps towards desktop consolidation?

Posted Oct 17, 2013 23:28 UTC (Thu) by FranTaylor (guest, #80190) [Link] (1 responses)

Why not? GTK is the GIMP toolkit, not the GNOME toolkit.

First steps towards desktop consolidation?

Posted Oct 18, 2013 5:21 UTC (Fri) by rsidd (subscriber, #2582) [Link]

It outgrew GIMP a while ago (i.e. about 15 years ago). In fact, the "+" in Gtk+ signifies this growth (in particular, object-oriented features, deriving new widgets etc) which weren't in the original Gtk.

Maybe not but

Posted Oct 18, 2013 3:51 UTC (Fri) by ncm (guest, #165) [Link] (7 responses)

Of course they won't. But you had to say "probably".

I don't know how to cope with the new fact that, given the advent of LED displays, monochrome text on a black background is by far the lowest-power-consuming way to present a UI. All I can hope for is that e-paper will eventually catch up.

Maybe not but

Posted Oct 18, 2013 5:13 UTC (Fri) by rsidd (subscriber, #2582) [Link] (6 responses)

That is true only of AMOLED (and similar) displays which are only widely available on phones so far. Backlit LED displays still consume power regardless of background, because they are still LCD displays where the backlight remains on at all times, only the backlighting is LED rather than fluorescent.

Maybe not but

Posted Oct 18, 2013 8:56 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

Well, that used to be true, but not anymore. Hint: look for the "Intel Display Power Saving Technology", you'll be surprised.

Maybe not but

Posted Oct 18, 2013 9:26 UTC (Fri) by rsidd (subscriber, #2582) [Link] (1 responses)

I googled, and this is one of the top three hits!

Besides, I doubt it will cause power saving for black backgrounds with white text. If anything, it would be the opposite -- turn down the backlight for bright screens, turn it up for dark screens.

Maybe not but

Posted Oct 18, 2013 15:44 UTC (Fri) by drag (guest, #31333) [Link]

Also with LED back lighting it's possible to adjust and decrease the lighting in order to get better black depth. I believe techniques in adjusting color brightness to parts of the display is used by television manufacturers to artificially improve the black level and dynamic contrast ratings in their displays.

Maybe not but

Posted Oct 20, 2013 1:02 UTC (Sun) by ncm (guest, #165) [Link] (2 responses)

Yes, it's AMOLED displays I am thinking of. In the really old days, green text on a black screen really did use less electron-beam power, but it didn't matter much because the whole apparatus cooked. An LC display monitor can (and in many cases does) turn down backlighting in areas of the screen that are supposed to be dim or black, but that's more meant to improve contrast than power consumption.

But on a display with one (or two) red, green, and blue LEDs corresponding to each pixel, everything changes. Only the LEDs that are lit up burn power, and for every
pixel kept black you gain battery life. It becomes actively irresponsible to present a paper-white background. You can watch The Dark Knight several times on the power used by one screening of Lawrence of Arabia.

I can't see any way around it. I will just need to get used to green-on-black text again.

Maybe not but

Posted Oct 21, 2013 17:47 UTC (Mon) by mstone_ (subscriber, #66309) [Link] (1 responses)

I always preferred grey-on-black, and my terminal windows have been that way for 20 years. Reigning in the web is hard, though--web designers seem to really like staring into a light, for some reason.

Maybe not but

Posted Oct 22, 2013 19:34 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> web designers seem to really like staring into a light, for some reason.

Maybe they hope it's the light at the end of the tunnel of designing web pages?

First steps towards desktop consolidation?

Posted Oct 19, 2013 6:14 UTC (Sat) by Rehdon (guest, #45440) [Link]

You can read Clem's take on GTK+2/3 and QT here:

http://segfault.linuxmint.com/2013/10/cinnamon-2-0-releas...

Spoiler:

"I don’t think GTK3 will ever get to a point where it needs patching or forking but it’s important to consider the risks associated with using it or migrating to it."

Rehdon

First steps towards desktop consolidation?

Posted Oct 18, 2013 13:06 UTC (Fri) by drag (guest, #31333) [Link]

> It looks like we are seeing the beginning of desktop consolidation.

Well.. No. This is just fantasy on your part. QT isn't KDE and GTK is not GNOME.

First steps towards desktop consolidation?

Posted Oct 18, 2013 14:55 UTC (Fri) by SEJeff (guest, #51588) [Link] (7 responses)

I think this is quite simple really. QT has had Trolltech^WNokia^Digia fulltime funding for quite awhile. GTK has developer and is primarily redhat working on it, but they don't have near as much of a vested interest in that they don't have a services business around gtk like the other various companies do around QT. It isn't a matter of this has more adoption, I think they are vaguely analogous. The thing that makes QT "superior" by some points of view is simply that it has had a lot more full time engineers working on it for a very long time.

This doesn't suprise me much at all.

First steps towards desktop consolidation?

Posted Oct 18, 2013 17:11 UTC (Fri) by yodermk (subscriber, #3803) [Link] (6 responses)

And it shows. Qt is so rich and such a pleasure to work with. Gtk seems, comparatively, to be a mess.

Hate to troll, but I can't think of any reason why one would want to choose Gtk over Qt today if they were starting out.

First steps towards desktop consolidation?

Posted Oct 18, 2013 21:41 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (5 responses)

Well, as an uzbl developer (and I also previously worked in KDE code, so I'm familiar with Qt as well), if you're looking at WebKit, the GTK port is just much richer than the Qt port. For a program like uzbl which is basically a shim, a socket, and a window on top of the WebKit API, this extra stuff is worth the pain of GTK over Qt. If you look at the "minimal" browsers, most use the GTK port, not Qt (I think Midori is the "lightest" of Qt browsers around, but maybe more have cropped up since) while GTK has uzbl, luakit, dwb, surf, and jumanji. Of course, I've also considered using WebKitNix, but I haven't had the time to dive into that since my initial look at it.

Other than that, the little Python scripts I'm working on as simple end points for various DBus API calls (logind, PolicyKit, BlueZ, etc.) use PyGTK because it seems to just be the lowest common denominator on Linux machines. I may just end up forking off to Xdialog at some point, but I haven't worked on these scripts much, so who knows when I'll even get to that point.

First steps towards desktop consolidation?

Posted Oct 18, 2013 23:57 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

is uzble still alive? the project news page hasn't been updated for over a year.

First steps towards desktop consolidation?

Posted Oct 19, 2013 0:04 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Yeah, I know :( . I don't have access to the website to do anything. Around a year ago, I started on a code cleanup which is pretty much done[1] (though I have some WebKitGTK features which are on their way in to test out). Unfortunately, it turned into a large rewrite branch and bct (the main developer) and I have plans to make my branch master and do a proper 1.0 release…at some point. I need to write a document for porting old config files and EM implementations to the changes in my branch yet.

[1]https://github.com/mathstuf/uzbl/tree/next

First steps towards desktop consolidation?

Posted Oct 20, 2013 20:22 UTC (Sun) by kalev (guest, #58246) [Link] (1 responses)

Midori is actually based on GTK+ as well.

First steps towards desktop consolidation?

Posted Oct 21, 2013 1:31 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Oops, yes. I was thinking of Arora but the wrong name came to mind.

First steps towards desktop consolidation?

Posted Oct 21, 2013 1:12 UTC (Mon) by kenmoffat (subscriber, #4807) [Link]

I think you probably meant 'arora' for the lightest qt browser - it's no longer developed, but still works on current qt4.

Wireshark switches to Qt

Posted Oct 18, 2013 4:17 UTC (Fri) by djzort (guest, #57189) [Link] (7 responses)

It seems odd they wouldn't choose to use WxWdigets, then people can use which ever widget toolkit makes sense to them on their platform...

Wireshark switches to Qt

Posted Oct 18, 2013 5:59 UTC (Fri) by jem (subscriber, #24231) [Link]

No they can't. WxWidgets uses GTK+ on Linux. There is no alternative, at least not in the sense that a WxWidgets application would automatically switch to using a WxWidgets implementation built on top of Qt when deployed on a KDE based Linux distro.

Wireshark switches to Qt

Posted Oct 18, 2013 7:08 UTC (Fri) by epa (subscriber, #39769) [Link]

wxWidgets is a good idea, but if Qt runs natively on all major platforms it seems simpler just to use that.

Wireshark switches to Qt

Posted Oct 18, 2013 7:57 UTC (Fri) by mbunkus (subscriber, #87248) [Link] (2 responses)

As someone who has done cross-platform development (Linux, Windows, Mac, *BSD) in both wxWidgets and Qt I would vote for Qt each and every time. wxWidgets has several drawbacks (from the developer's point of view): a lot less widgets available; far less abstraction of platform-specific details (leading to a lot of cases of having to use "#ifdef WINDOW" because that widgets behaves differently on Windows than it does on all the other machines); Mac is still a second-class citizen; a lot less support for stdlib compatible containers and algorithms; a lot less support (including bugs) for C++11 support.

Yes, I have reported most of those things upstream. No, they won't get fixed any time soon. I also don't see wxWidgets making headway into the territory mentioned in the article: handheld devices. Qt has been doing this for some time already and will continue to do so.

If you leave out personal preferences regarding looks then there are no cons for a project to chose wxWidgets over Qt. For Wireshark those cons are even more numerous than for other projects.

Wireshark switches to Qt

Posted Oct 19, 2013 9:51 UTC (Sat) by eternaleye (guest, #67051) [Link] (1 responses)

That's not even counting that Qt can use GTK+ themes, while the reverse is not the case.

Wireshark switches to Qt

Posted Nov 1, 2013 0:53 UTC (Fri) by bronson (subscriber, #4806) [Link]

And nowadays GTK+ can't even use GTK+ themes.

Wireshark switches to Qt

Posted Oct 19, 2013 12:02 UTC (Sat) by robert_s (subscriber, #42402) [Link] (1 responses)

Adding another level of abstraction in GUI work is like putting on another pair of gloves.

Wireshark switches to Qt

Posted Nov 1, 2013 0:49 UTC (Fri) by bronson (subscriber, #4806) [Link]

That is a supremely quotable quote. Exactly right.

Has QT fixed the speed yet?

Posted Oct 18, 2013 9:29 UTC (Fri) by Richard_J_Neill (subscriber, #23093) [Link] (8 responses)

I recall systems like the Zaurus (233 MHz single core) having 2 choices of environments, GPE (the "GNOME Palmtop Environment", using GTK+) and Qtopia (based on QT). Qtopia was slightly prettier, but it felt painfully sluggish (about 5x slower) compared to GPE which responded "instantly". Is it still the case, or is this now irrelevant?

Has QT fixed the speed yet?

Posted Oct 18, 2013 10:12 UTC (Fri) by halla (subscriber, #14185) [Link] (6 responses)

Yes, this is now completely irrelevant. Qt works extremely well on mobile platforms, and GTK is no longer a contender on mobile anymore anyway.

Has QT fixed the speed yet?

Posted Oct 18, 2013 17:25 UTC (Fri) by drag (guest, #31333) [Link] (5 responses)

Really?

How many people are actually using QT on Android for any of their software?

Has QT fixed the speed yet?

Posted Oct 18, 2013 17:39 UTC (Fri) by halla (subscriber, #14185) [Link] (3 responses)

Quite a few. And, of course, "mobile" isn't limited to "android". Not only did Qt work extremely well on Maemo and Meego, not only does it works very well on Sailfish and Ubuntu's mobile stuff, but it's also used in e-readers, like Kobo (entirely Qt-based) and there are actually even a few applications on iOS that use Qt (like Musescore). Qt runs fine even on Tizen.

And then mobile is bigger than just mobile phones. My own Krita Sketch and Krita Gemini works perfectly well on Windows 8 tablets, for instance. My company works on a Qt application for Sailfish.

So, yes, Drag, "really." Qt runs extremely well on mobile platforms. Really. Qt shines in more places than ever before.

Has QT fixed the speed yet?

Posted Oct 18, 2013 21:37 UTC (Fri) by kugel (subscriber, #70540) [Link] (2 responses)

Maemo used GTK+ for the most part, didn't it?

Has QT fixed the speed yet?

Posted Oct 18, 2013 23:45 UTC (Fri) by krakensden (subscriber, #72039) [Link]

Yeah, they switched around the same time that they transitioned into Meego.

The history of that project is so depressing.

Has QT fixed the speed yet?

Posted Oct 19, 2013 8:13 UTC (Sat) by halla (subscriber, #14185) [Link]

Yes -- the fremantle (the maemo version that came with the N900) mostly was based on GTK -- but that isn't the point. The point is that Qt applications ran perfectly well on it, with a nice look and feel fit for the whole platform.

This is all, remember, in reply to someone who trotted out a seven-year old anecdote about relative performance of GTK and Qt on mobile and asked whether that was still relevant for today's Qt on mobile experience. A lot has happened since the early qtopia days, his experience isn't relevant anymore.

Has QT fixed the speed yet?

Posted Oct 19, 2013 12:00 UTC (Sat) by hunger (subscriber, #36242) [Link]

There are lots of UIs written in Qt that runs on embedded hardware running a (often stripped down) version of Android.

So maybe there are not too many apps for the Android-on-your-phone yet, but I don't think that is surprising, considering that only the _next_ release of Qt does officially support that OS.

But I already ran two Qt apps (that I know of;-) that I got from the Google play store on my own phone. One was just a Qt demo though ( https://play.google.com/store/apps/details?id=com.digia.Q... ), so that does not really count, does it?

Has QT fixed the speed yet?

Posted Oct 18, 2013 13:02 UTC (Fri) by mirabilos (subscriber, #84359) [Link]

Funnily enough, KDE beats GTK+ on Debian/m68k (probably due to the latter using TLS and atomics much more, which have syscall penalty on some architectures).

This is not comparing apples and trees (I’m not comparing Qt and GTK+ after all) but really a full kde-plasma-desktop session (in a VNC server, due to the lack of a real X driver for the display in that machine) is faster to use (until you start KDEPIM, but that’s even slow on an AMD64 desktop) than an IceWM session (decent fast) with one single GTK+ application running…

Wireshark switches to Qt

Posted Oct 20, 2013 5:54 UTC (Sun) by Neowin (guest, #93001) [Link] (1 responses)

The claim that GTK+ being a multi-platform toolkit is a blatant lie. It is a toolkit specifically designed for GNOME hell that happen to have multiple crappy backends.

Wireshark switches to Qt

Posted Oct 20, 2013 19:47 UTC (Sun) by rleigh (guest, #14622) [Link]

GTK+ has been nominally multi-platform for some time. I spent a good amount of time fixing it and GLib to work with Cygwin/MinGW on Windows around 2004-5. (MacOS support was then just UNIX+X11, so not much different to Linux.) However, it was continually broken compared with Linux/X11, and suffered from repeated random breakage--it was quite clear it wasn't a primary target, and was obviously not subject to any integration testing. It appears that the Mac Cocoa port suffers from exactly the same problems.

In retrospect, I don't think GTK+ has ever been really suitable for cross-platform application development, despite the claims, and despite my extended efforts to do so. Non-X11 non-UNIX ports have always been broken and poorly supported, and this has never really changed. This also applies in a similar way to the language bindings, which are often slow to adopt API changes/additions and can also be buggy in their own right. GTKmm is wonderful, but it's still based upon a poor foundation; if that had been made the base API, replacing C/GObject entirely, it might have had a chance.

I switched to Qt a few months back, and while I still think GTK+ has the a nicer container model, I haven't suffered from a single portability issue to date, and the quality of implementation is so much better. Again looking back, the amount of pain and suffering you have to endure using GTK+ is absolutely ridiculous; GObject makes for unsafe, slow and hard to maintain code--justifying its use compared with safe C++ would be very difficult--imagine pitching this to your team in a commercial setting--and it's the primary reason GTK+ (and GNOME) ended up in this state. For example, creating new Qt widgets and subclassing existing ones is simple. Doing the same with GTK+ is a difficult and error-prone undertaking. And maintaining/refactoring after that even moreso. When you can just code in safe C++, choosing the clearly inferior solution makes no sense on any level--it's slower, unsafe, unpleasant to use, and barely maintainable.

GTK+3.x has broken several existing APIs, and made it even less portable than it already was. My existing code will remain using the stable GTK+2 APIs, and I have no intention of porting them to GTK+3--there would be zero benefit to do so. Eventually as I have to, I'll port to Qt. I'm by no means alone in this assessment. It's a quite unfortunate state of affairs, but it is what it is.