
Wireshark is switching to Qt - Tsiolkovsky
https://blog.wireshark.org/2013/10/switching-to-qt/
======
ryandrake
The thing I most remember about having to program with Qt was having to
convert all my standard C++ types back and forth to QStrings and QLists and
QFiles in order to work with the library's APIs, and witnessing what happens
when all the QThis and QThat objects start leaking over into your non-UI code
if you're not careful.

I've always found it annoying to have to work with frameworks that invade your
project with their own type defines, particularly when they are just parallel
versions of types already in the language's standard library.

~~~
cageface
I would pay cold hard cash for a modern UI toolkit that leveraged all the new
stuff in C++11 and used OpenGL as a rendering backend. All standard containers
and algorithms plus leveraging lambdas and C++11 concurrency tools. Most of
the C++ libraries out there now have a ton of legacy cruft.

~~~
andrewflnr
Interesting that you would prefer OpenGL and not native widgets/controls. Can
you elaborate on why?

~~~
cageface
Most of the apps I write have highly customized UI so I don't get that much
benefit from native controls anyway. And having GL shaders available for any
UI element would enable some pretty cool effects.

------
general_failure
Is this Qt5 or Qt4? If it's Qt4, I have some terrible news. The Qt project in
its infinite wisdom has pretty much obsoleted Qt widget stack and moved on to
QML. It's a completely different beast and requires a complete rewrite.

Edit: grammar and some bloopers :)

~~~
general_failure
Downvoter, care to explain? This information is 100% correct.

~~~
sho_hn
No, this information is hardly "100% correct". Here's what's actually going
on:

(1) During the 4.x cycle, Qt integrated a new declarative markup language
called QML, as part of a new language + batteries module called Qt Quick. In
Qt 5, Qt Quick has improved significantly and become a very viable choice for
many interesting and useful applications.

(2) Desktop-type applications are not yet among those. While Qt 5.2, to be
released toward the end of this year (currently it's in alpha) contains some
new Qt Quick batteries to implement desktop-type interfaces that are quite
promising, they're also still fairly young and rough, and not suitable for
demanding applications.

(3) QWidget continues to be maintained and fully supported. It's mature
technology that hasn't seen massive changes in the initial leap to Qt 5, but
has nonetheless benefitted from many improvements in the core of Qt.

(4) Further, in Qt 5.2, the KDE community in particular (which is in the
process of transitioning to Qt 5 and is a major stakeholder of QWidget, while
also making strong and increasing use of Qt Quick) has upstreamed tons and
tons of features and code that make QWidget and related APIs even stronger
than it already was. Qt 5.2 is an exciting release for users of QWidget and
QML alike.

(5) Qt is a proper open source project with well-working governance today.
It's also a well-modularized, well-layered codebase. There are no significant
roadblocks to caring for and maintaining QWidget for as long as the Qt
community sees fit. At the same time, Qt Quick offers some compelling
advantages and is likely to evolve as well.

~~~
Derbasti
Actually, QML has included Desktop Widgets for QML since Qt 5.1 under the name
Qt Quick Controls[1], which means that desktop-type applications are now
supported for QML as well.

Having used those a bit, I have to conclude that they are FREAKING AWESOME.
Sorry for yelling. If you are used to developing Qt applications using C++ and
the Widgets only, please do check that out. It is amazing!

[1]: [http://qt-project.org/wiki/New-Features-in-Qt-5.1](http://qt-
project.org/wiki/New-Features-in-Qt-5.1)

~~~
general_failure
QML is awesome, no doubt about it (and I am big fanboi myself). But that
doesn't take away the fact that Qt Widget -> QML is basically a complete
rewrite of your app.

~~~
CountSessine
No - not at all. We're doing this right now and we've structured the change by
using QDeclarativeView/QtQuickView within our existing QWidget architecture.
Depending on how you want to structure your application, using QML can be as
easy as converting a widget/dialog/form at a time and allowing the C++ code to
drive the QML, or going for a full re-write with the core of the program in
QML with C++ helpers bound to it.

QWidget isn't going anywhere. If "Qt Widget -> QML" is an unpleasant "complete
rewrite of your app" then don't do it. Stick with QWidget.

------
grn
Is there a solution better than implementing OS-specific GUI to provide native
look and feel? I was thinking about that and came to the conclusion that the
best thing we can do is to separate the business logic from the GUI. We can
then equip the application with a CLI, a GTK GUI, a Qt GUI, etc.

~~~
bluedino
That's what is suggested by this blog:

[http://blog.backblaze.com/2008/12/15/10-rules-for-how-to-
wri...](http://blog.backblaze.com/2008/12/15/10-rules-for-how-to-write-cross-
platform-code/)

 _Rule #2: Factor out the GUI into non-reusable code – then develop a cross-
platform library for the underlying logic_

I'd like to hear others experiences and views with doing that as opposed to
using something like QT or GTK.

~~~
ballard
This makes sense, since vying for cross-platform tends to result in awkward
experiences like the windows Treo.

Using MVC, it's more straightforward what components are specialized per OS
and which ones are common.

Not only that, having native apps would make the app UX "feel" better too.

------
groovy2shoes
Much of Wireshark uses not only GTK, but Glib as well. I'm wondering how the
move to Qt will affect plugins that manipulate the Glib structures, as I'm
assuming these will also be migrated to Qt.

What I'm trying to get at is: as the maintainer of a Wireshark plugin, what
should I be doing to prepare myself for the switch? Will I need to start
maintaining to versions of the plugin, one for Glib and one for Qt?

~~~
jeorgun
Though I have no idea about the specifics of Wireshark, there's no particular
reason for them to have migrated from Glib— PCManFM, for instance, still uses
Glib in its Qt port.

~~~
groovy2shoes
Right, that's why I'm wondering :)

------
raminf
"If you’re using Windows, Mac OS X, or Linux Mint we need to support Windows,
Mac OS X, and Linux Mint. If you’re using an iPad or a Galaxy Note we need to
give you a long, hard, nonplussed stare and think about supporting IOS and
Android at some point."

Comedy gold!

------
AlexMax
I am very pleased by this news, as using Wireshark on the Mac is not a
pleasant visual experience.

However, having only casually looked at both Qt and wxWidgets, how do MODERN
versions of both compare?

Doing something with a GUI toolkit is something I'd like to visit at some
point in the future, and Qt seems to have more mindshare, but from what I
understand Qt doesn't actually draw native widgets, merely emulated ones.
Reading about MOC and seeing the number of .dll's included with the average Qt
project also put me off a bit.

~~~
gnud
The MOC isn't scary, it's a simple first compiler pass that makes Qt's meta
object system a lot lot lot easier to use.

But it does rather limit you to either qmake or cmake, afaik.

~~~
dima55
It doesn't dictate your build system. A few lines of GNU make can support it.

------
tuananh
Qt app still looks like alien on OS X though but at least, it's less awkward.

~~~
matthewmacleod
It's possible to build a cross-platform GUI app using Qt that looks pretty
much at home on all platforms. Certainly requires a bit more work and
customisation per-platform, but good Qt apps are almost indistinguishable from
native ones.

~~~
Osmium
Honestly, I think it'd be better if they kept a non-native UI that was at
least internally consistent rather than trying to replicate a Mac native UI
badly. I use so many apps with bad Mac ports that look perfectly decent on
Linux...

~~~
tuananh
The only decent look cross-platform app I found is Transmission
([http://www.transmissionbt.com](http://www.transmissionbt.com))

~~~
Osmium
That's because they build a native Mac GUI (same for certain other cross-
platform apps, e.g. Handbrake).

------
radikalus
Excellent -- I use wireshark probably every other day on my osx laptop and
this looks like a pretty good improvement.

Have there been any performance improvements to command line tshark recently?

------
secstate
Hrumph ... should just port it to shoes[1] and be done with it. Just kidding,
just kidding. But really, why can't we have an HTML5 layout engine for native
applications?

1: [https://github.com/shoes/shoes4](https://github.com/shoes/shoes4)

~~~
depr
Why would you want to use HTML5 for native applications? It's bad enough that
you have to use it for websites.

~~~
secstate
A fair point and I was mostly joking about shoes. Though the child to this
makes a solid point that if you've ever done GUI work, HTML5 is at the very
least comparable to the pain of the myriad toolkits provided on other
platforms.

Also, +1 for the resurgence[1] of tk for lightweight GUI apps : -) Who needs
native anything, when THE tool kit is installed everywhere python is (which is
also everywhere).

1: [http://pybee.org/](http://pybee.org/)

------
shmerl
I wish Firefox would do the same. Sailfish browser already does (which is
basically Gecko with Qt UI based on IPC embedding API). There was initial work
to make Firefox with Qt, but Mozilla never officially started supporting it.

~~~
zokier
Firefoxs use of GTK is relatively minimal, especially when compared to
something like Wireshark. Almost all UI of Fx in done in XUL afaik.

~~~
shmerl
In the desktop version yes, but not in the mobile versions though. They are
relying on native UI heavily.

Even though it's minimal on the desktop, the styling of the UI is still
affected primarily by the GTK theme. On KDE I'm using oxygen-gtk to make
Firefox look native.

~~~
S201
> In the desktop version yes, but not in the mobile versions though. They are
> relying on native UI heavily.

This is because the startup times with XUL were simply too slow. The first
version of Firefox for Android did, in fact, use XUL just like desktop
Firefox. The app startup times were atrocious. The decision to use a native
Android UI made the app usable while Gecko was starting in the background.

~~~
shmerl
Partially, that's because Android applications are cheating - Android runtime
is always loaded in memory. Using native UI has its downside - XUL Fennec UI
was portable, native one is not.

Sailfish browser isn't XUL UI either though, it's Qt (QML) based but relies on
IPC to separate UI from the heavy components:
[https://wiki.mozilla.org/Embedding/IPCLiteAPI](https://wiki.mozilla.org/Embedding/IPCLiteAPI)
That also provides fast startup.

------
clumsysmurf
The inkscape project hasn't put out a Mac OS release in years; from the little
I know it seems to be related to the UI toolkit / XQuartz. Maybe they should
consider a move like this also.

~~~
illumen
The gimp, and some other projects have recently done non-X releases on OSX.
They are much better apps because of it.

There are still a few issues in gimp OSX... like some dialogs needing ctrl+c
ctrl+v instead of cmd+c cmd+v for copy paste. However, it is a very nice app
on OSX now.

------
leephillips
I've never used this, but from the screenshots it looks like a perfect
candidate for a curses-type interface. Is there a good reason for using the
extra resources required by the GUI?

~~~
pjmlp
We are no longer in 197x?

~~~
astrobe_
Wrong. This is a common misconception that command-line tools are no longer
relevant because they are "old".

In some cases text/keyboard interfaces are better. Like for instance when
editing case. In some other cases, graphical/mouse interface is better. Like
for instance web browsing.

Command-line tools generally offer a larger language than GUI applications.
And if that language is not enough, you can still combine them; something that
is impossible with a GUI app.

~~~
takluyver
curses programs are not command line tools - they're effectively GUI
applications, but using the terminal as their 'graphical' toolkit.

------
staunch
I just wish Wireshark didn't barf when I throw a 1GB capture at it.

------
pjbringer
Just the other day, I noticed that on my kde desktop, wireshark was the only
program using gtk3, whereas gtk2 is used by a bunch of cross platform
programs. I'm not too sure what that means though.

~~~
tenfingers
GTK3 has a very small adoption rate for cross-desktop/OS applications. Except
for the gnome DE (which I'm not using), on my system the only two applications
using GTK3 are wireshark and lightdm. Heck, even GIMP on Debian is still using
GTK2.

QT4+ is faster than GTK3, the API is superior in almost every respect, has
better cross-platform OS support. It should be telling to every user how some
basic widgets like the file-open dialog in GTK3 has actually regressed in
every respect compared to GTK2, and many others actually behave worse from the
user's point of view (which should be the #1 priority of any widget system,
even before the API).

I used to prefer GTK for the footprint (and mind you, I was always aiming at
pure X11 development), but not anymore.

------
BinaryBrainz
In case anyone missed it or might be interested, Gerald Combs was interviewed
about Wireshark on FLOSS Weekly:
[http://www.youtube.com/watch?v=rE_QIqcB8Mg](http://www.youtube.com/watch?v=rE_QIqcB8Mg)

I would say it is was a fairly interesting interview that covered the future
developments for Wireshark.

------
hcarvalhoalves
Great. I tried using it on OS X last week and gave up after having to deal
with X11, slowness and crashes. I ended using tcdump. I look forward to trying
the Qt port since Wireshark (Ethereal) has saved my bacon many times in the
past.

------
stock_toaster
I use wireshark regularly (on OSX these days). Looking forward to this!

------
b4d
Looks good, just needs some retina support on OS X.

------
sambecket
There's always JUCE ! A little slow to catch up at first,but after a while
you'll get it and be able to build amazing things easily, plus its pure c++ no
prepoocesor or anything like it.

------
_-_-_-
Poo.

Qt has been a pain in my ass in OS X. You get the wrong version installed in
the wrong place and you're fucked. I think it is something that is kind to
developers and a headache to users.

Personally I give a big thumbs down on this decision. It's one thing for some
random program or library to use Qt that I don't care about, but I've been
using Wireshark since it was Ethereal. It should not be Qt. That's lame.

------
znowi
tl;dr

We wanted to please the trendy Mac users, hence switched to Qt, which
providers a more authentic interface on Mac OS X.

~~~
malkia
Qt has much more compact packaging - few dlls, maybe plugins, and even static
linking maybe possible for GPL or other free software.

While I love gtk for the fact that it's C, it's not that easy to use from ffi-
exposed systems like luajit, since it relies too much on preprocessor macro
magic that has to be replicated there...

------
jebblue
Actually I prefer SWT or Swing with Java for a mature looking, cross-platform
application. I thought Qt went away until I read Ubuntu will use something new
for Qt called QML. If I were to consider something for Linux Desktop GUI's
other than SWT/Swing/Java I would probably use Gtk+Python.

~~~
veeti
> Swing for a mature looking, cross-platform application

Dear lord.

~~~
jebblue
Why did you downvote me when we simply have a different opinion? Is the
expression of opinions no longer welcome on HN? I don't have the ability to
downvote you? Does your ability to downvote me mean your opnion is more valid
than mine?

~~~
veeti
Did I?

This really isn't up to some subjective opinion either. Swing doesn't have a
native look & feel on _any_ platform: it's awful no matter what OS you're
using.

~~~
truncate
Adding to that, Swing is just almost always annoyingly slow and unresponsive
in my experience.

~~~
fdr_cs
IntelliJ is one of the only exceptions that come to mind. But, I would _LOVE_
if intelliJ used Qt instead of Java/Swing ...

------
guilloche
Why bother wasting effort on GUI?

GTK3 is good enough and QT seems more bloated and has more dependencies.

Anyway, I will use tcpdump.

Byebye, wireshark.

~~~
guilloche
No different opinion allowed? Please give me more down vote, I do not care in
fact.

~~~
derleth
It's not the difference of opinion, it's the fact your post adds nothing to
the discussion. This adds even less.

~~~
yeukhon
Well, you know anyone can comment and surely can downvote him. If we need "to
add something to discussion", let's have a moderation. Let a bunch of karam >=
500 to decide before publishing. Don't downvote. It's stupid.

There is a reason why upvote exists. It pushes good discussion top. If you are
worrying about space complexity: good news! HN is using a modern database, not
flat file. You can store 10k comments.

~~~
derleth
> There is a reason why upvote exists. It pushes good discussion top.

And downvoting helps push bad comments down, which is by design.

> If you are worrying about space complexity: good news! HN is using a modern
> database, not flat file. You can store 10k comments.

This is irrelevant to having a good discussion.

