
Wireshark 2.0: Now with Qt - signa11
http://lwn.net/Articles/667165/
======
creshal
It's a shame how far GTK is falling behind. From a user's perspective, I liked
GTK2's smooth, clean interfaces much more than anything made in Qt, so much
that I didn't even mind putting up with its insane APIs.

But now? GTK3 interfaces are horrible from an user's perspective – client-side
decorations are a sin that we should know better than to repeat, plus a whole
load of changes just for change's sake to spite users (the file chooser dialog
has a much worse UX; mouse wheel support was widely gutted because apparently
I'm supposed to want touch interfaces instead?) –, and the APIs are still as
bad to use, most changes seem to have been made out of spite; a small shim
would have allowed most programs to switch from GTK2 to 3 without code
changes, had it not been for those.

Now I find myself increasingly switching to Qt programs. While the interfaces
are still somewhat rougher than GTK2 ones and not as unified, it still beats
GTK3 crap. That seems to be turning from "a reasonable toolkit for all X11
invironments" into "the official Gnome 3 toolkit, beg us if you want
interoperability".

~~~
bkor
I mostly disagree with you entirely.

Client side decorations give way more space to the actual content than to
waste space for an almost empty titlebar. It allows to combine the titlebar
with content from the application itself. You regard them entirely off as a
"sin". Very strong language but you don't explain _at all_!

For the file chooser, some never things that were never implemented were added
recently: double vs single clicking, renaming and some other super old bug.

Regarding mouse wheel support: What basis do you say that 1) it was removed 2)
it was made out of spite?

Too many people have way too much time talking down on the work of others. You
go out of your way to imply that GNOME developers are intentionally evil. What
the hell.

PS: I agree it needs way more developers. But that's nothing new.

~~~
creshal
> Client side decorations give way more space to the actual content than to
> waste space for an almost empty titlebar.

If Gnome 3 wanted to fix that, it should just replace its space-wasting
default theme. And in reality it's a non-issue everywhere else. No other
desktop environment even has this debate.

> Very strong language but you don't explain _at all_!

Very easy: Consistency. Look at how absolutely, utterly _shit_ Windows looks
nowadays. Word doesn't blend in with Explorer doesn't blend in with regedit
doesn't blend it with (the still XP-themed) GPO editor doesn't blend in with
the new settings app doesn't blend in with the control panel doesn't blend in
with Edge …

My window manager should dictate how windows looks. This works for all
toolkits, from GTK2 over FLTK over Qt all the way to Mono's GDI. All, except
GTK3.

And yet, it does not have to be a problem! A few years ago, this would have
been a no-brainer: When GTK was presented with behavioural differences between
desktop environments, it was implemented as a run-time option, configured by
the GTK theme to allow desktops to configure GTK to its needs (like "images on
buttons", mandatory in Xfce, shunned in Gnome).

Client-side decorations are a compile-time switch. What the hell.

> Regarding mouse wheel support: What basis do you say that 1) it was removed
> 2) it was made out of spite?

GTK's notebook widget. It was removed for no reason, and users were told to
just reimplement it in all applications they needed it in. What the hell.

~~~
nona
> My window manager should dictate how windows looks. This works for all
> toolkits, from GTK2 over FLTK over Qt all the way to Mono's GDI. All, except
> GTK3.

So you're arguing that because the window decorations are consistent, apps are
consistent?

Hate to break it to you, but running a GTK2 app under KDE/KWin will still look
inconsistent.

The only way you get to be consistent, is by having your app developers use
the same toolkit. I don't see why the windows' frame should be regarded as
"special" when all the button/tabs/filechooser/… widgets are different
depending on the toolkit.

~~~
jstimpfle
> The only way you get to be consistent, is by having your app developers use
> the same toolkit.

Will never happen. Instead, if you want consistency, avoid redundancy in the
first place (where it's practical)

~~~
nona
I agree, but well, you can choose to run only or mostly GTK or QT apps, and
stop caring the occasional out of place app (Blender? Steam?) doesn't look
consistent.

And to be honest, I don't see why I would care that apps like Blender or Steam
have a window frame that looks exactly like the window frames of my (non-CSD)
desktop environment/window manager, when the apps themselves are completely
out of place. But that's me, I suppose.

~~~
jstimpfle
> I don't see why I would care that apps like Blender or Steam have a window
> frame that looks exactly like the window frames

Unless you use blender or steam, or evince (!) with anything other than gnome3
and default theme, that is, and unless any of the many reasons against CSDs
resounds for you (as somebody below posted)

[http://blog.martin-graesslin.com/blog/2010/05/open-letter-
th...](http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-
with-client-side-window-decorations/)

Sounds very unrealistic, doesn't it?

------
tenfingers
I'd say good riddance GTK3. I really liked GTK1/2, to be honest. I liked the
column-based (unixy) file dialogs, detachable menus that you could use as a
poor-mans toolbars, and many minor tweaks.

The API was always horrendous (it still is!), but as user I liked it so I just
coped as a developer anyway.

Since the full embrace of gnome, I started to dislike GTK2/3 more and more.
The stupidity of file dialogs starting in "recents mode" also for save, to
name one. Saving a file again? You see restarting at the top directory, just
like in windows. Well, it's because the file dialogs don't have any saved
state if you happen to destroy the dialog instance. A tweak that costs
literally nothing to implement, but probably "not granma friendly"?

GTK3 is also downright slow. The new theming mechanism might be fancy, but
objectively I have some UIs that I left at GTK2 intentionally for lower
latency.

I re-evaluated QT4 as a user. The API and developer tools are just light-years
ahead.

It's unfortunate that I cannot say I like the evolution of QT5.

~~~
ultramancool
Been using Qt5 for quite a while at work - what changes don't you like in it?
Most things seem to just be relatively minor improvements from Qt4.

~~~
tenfingers
As for GTK3, rendering performance, latency and memory usage in QT5 suffer
significantly. QT4 is not light, but QT5 adds overhead for no reason.

I like the general polishing in the core modules, but I have really no use for
qtquick. For this reason, I _really_ encourage anyone to get onto copperspice
([http://www.copperspice.com/](http://www.copperspice.com/)). Without MOC, QT
really feels an awesome API.

~~~
joezydeco
I use Qt a lot on smaller embedded targets and I haven't moved to 5. Don't
really want to mess with the new windowing system and I can't put
Wayland/Weston on a lot of my smaller projects.

I'm pretty much locked into 4.8 (and it's eternally open tickets) for life.

~~~
turrini
Qt5 doesn't require Wayland, I'm using Qt 5.5.1 with widgets on embedded
environments (X11 included) without problems.

~~~
joezydeco
_X11 included_

Yeah, um, not possible for me. I use the Linux framebuffer and that's it.

------
dorfsmay
Two things about Witeshark that I hadn't realised until recently but that
changed my life:

    
    
      - Wireshark has a Command Lime Interface that is very usable and incredibly useful to debug a machine you can only ssh to: tshark
    
      - you can look at packets captured with tcpdump with Wireshark/tshark

~~~
Kurtz79
Command lime would be a great name for a shell :)

Jokes aside (sorry), it's an absolute godsend when trying to debug embedded
systems.

~~~
dorfsmay
(now I'm going to spend the rest of the day thinking about how I could make a
funny pun based on my typo!)

Life saver when debugging even mundane web servers:

    
    
        tshark -i eth0 -O http -Y http
    

This is one place where TLS (https) everywhere is a pain.

------
noselasd
Note that 2.0 still can be used with GTK. I'm a daily wireshark user and had
to switch back to the GTK version - the Qt version is currently incredible
buggy - at least on Windows.

~~~
bkor
Please file bugs! It is sometimes surprising what developers don't notice. At
most you'll file a duplicate. One bug per issue is usually best.

------
jaybosamiya
> There are many more keyboard shortcuts in Wireshark 2. The full list of
> those shortcuts can be found from the "Help" menu. In addition, individual
> windows have their own shortcuts, which can be listed from the window
> itself.

More keyboard shortcuts always makes me happy. Less usage of that tiny little
touchpad on my laptop.

------
topspin
Watched someone via GoToMeeting try to use 2.0 yesterday on a Windows server.
They couldn't start capture on the interface; start button grey'd out with no
explanation. Installed the older version (1.12.8) and it worked perfectly. QT
is great and all but I'll have to stick with the legacy stuff for a while.

~~~
NetStrikeForce
I've used 2.0 on a Server 2016 TP4 and two different Windows 10 with zero
problems. The person you've seen running it probably didn't install Winpcap or
something along those lines, hence why installing 1.12.8 solved the issue.

My main criticism is that I don't get a separate window telling me the
progress of the file loading. I work sometimes with big files and it takes a
few seconds to load them. On 2.0 at first I didn't know what was going on,
because there's only this very tiny progress bar at the bottom.

------
shmerl
I wish Firefox would also start using Qt.

~~~
nwah1
browser.html makes more sense. Web standards are, at this point, their own
form of GUI toolkit, and why does Firefox need more than one? It is just
bloat.

[https://github.com/mozilla/browser.html](https://github.com/mozilla/browser.html)

~~~
shmerl
Mozilla rejected this webbiness approach in their own release on Android using
the excuse that Android applications cheat because Android runtime is always
loaded in memory, while any other runtime has to be loaded which causes a
startup delay. It actually caused them to kill Fennec which had portable UI,
and instead create an unportable Android UI.

So if they already stick with native UIs, let them use Qt.

------
NelsonMinar
I've been using the 1.99 builds on my Mac for, oh, a year now. And I'm so
grateful. It works great and was miles ahead of the old X11-based thing.

------
WhitneyLand
I wonder if they would have considered HTML5 if NW.js / Electron had been
around when they started.

~~~
scrollaway
Please stop with the HTML5 UI madness. While HTML/CSS is, imo, a great UI
toolkit, nobody wants a browser engine in every separate application. A
browser engine that needs to be kept up to date with upstream on an extremely
regular basis, separately for every app, lest you are vulnerable to whatever
exploit of the month.

~~~
zanny
On top of this, Qt 5 _is_ a browser engine. Kind of. That is what QML is meant
to be. Its application javascript done _right_ , rather than the mutant
horrible diaster that is web standards. If you write a full application in QML
today and experience how amazingly easy it is to do fancy visual effects since
the whole thing is hardware accelerated you will never be able to develop web
app code again without desperately praying for sweet release.

I dream of the day QML is standardized as webapp tech in browser standards, so
we can have cross platform native applications over the browser that use a
reasonable programming paradigm rather than trying to turn markup documents
into mission critical applications.

~~~
jalfresi
Couldn't agree more. I've used QML for a Go app and the sanity prevalent in
QML vs. web standards is like night and day.

I actually don't want anything more to do with web front end development -
leave all the react/flux/angular nonsense to the JS package manager of the
month crowd.

~~~
gnufied
So I have used QML plenty too and it isn't all that great honestly. In fact in
many ways it is backwards.

For example, all Qt widgets instantiated via C++ can be styled using an
external stylesheet, but not so for QML stuff. All the margin, padding you
have to specify inline in the code. If that is not going backwards, I dunno
what is.

~~~
zanny
You can style Qt Quick Controls, which are the QtWidgets equivalent objects in
QML.

[http://doc.qt.io/qt-5/qtquickcontrolsstyles-
index.html](http://doc.qt.io/qt-5/qtquickcontrolsstyles-index.html)

This is how many new apps are coming out using QML and doing their own custom
UI theming rather than doing system default. It also beats the hell out of CSS
by using the same object model relationships you are already using when laying
out QML objects.

Yes, if you use language primitives like rect's and text's then you have to
create either your own theming engine template classes and then use those, or
manually manage all the styling per object. But then you are doing it wrong if
your project does not warrant that kind of ground up custom craftsmanship.

