10 ms·
Wireshark is switching to Qt
- leephillips 13y agoI'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?
- iends 13y agoSome find a gui more usable. You can use tshark of you disagree.
- ajross 13y agoSome (hi!) find that a UI of any kind gets in the way and prefer to do this kind of work with tcpdump logs and perl. It's as much a taste thing as anything else, and certainly wireshark is very well regarded. It's basically the gold standard in this world. It also used to be very Linux/Gtk-centric too, and part of me is sad that the focus is now on enabling proprietary platforms at the same level of robustness. But that's obviously a philosophy thing and I'm not the developer. And to get to the point of the blog post: it's absolutely true that cross-platform sanity has never been part of Gtk+'s design goals. It's always (well, since Gnome 1.0) been a playground for stuff in Gnome, and work on other environments a secondary thing done mostly by volunteers. From the perspective of an app developer, Qt is much (much!) cleaner in this regard. Though it gets that at the cost of staggering code size and build complexity. Really Qt has to duplicate the superset of features provided by all the supported environments. It does it, but I can't say it's pretty.
- routelastresort 13y ago^^^ some
- avtar 13y agoIs there a good reason for using the extra resources required by the GUI? Do you mean extra resources required by the GUI while capturing data? I've never captured traffic on a server using Ethereal/Wireshark. It's easier to use tcpdump to do that, save the captured data to a file, and then view that in Wireshark. http://www.wireshark.org/docs/wsug_html_chunked/AppToolstcpdump.html http://www.wireshark.org/docs/wsug_html_chunked/AppToolstcpd...
- Shish2k 13y agoThe screenshots there are fairly minimal; there are an insane number of knobs and twiddles when you start digging through the menus (I know you can do modal dialogs, comboboxes, even graphics in a console, but most people seem to agree GUI is better for that)
- pjmlp 13y agoWe are no longer in 197x?
- icebraining 13y agoThe mouse-driven GUI was invented in 1973. What do you use, a Kinect?
- kristopolous 13y agoForgot Engelbart in mother of all demos (1968)??
- icebraining 13y agoOh, right, I was thinking about the Alto, sorry.
- pjmlp 13y agoBut it only become widespread to the what was the technical average Joe in the 80's.
- astrobe_ 13y agoWrong. 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.
- sp332 13y agoYeah, usually the packet data doesn't all fit on the screen. SO first I'll resize the top pane(that lists packets) so I can browse, then when I pick one I'll click the field I want to look at in the next pane, then probably resize again so I can see more data in the lowest pane. Using a keyboard to switch which packet and which field you're looking at sounds like a pain to me.
- mikecarlton 13y agoThe wheel goes full circle as always. If you're worried about resources just use tcpdump. I've always viewed wireshark as a GUI alternative to tcpdump. And yes, I know wireshark does more packet dissecting, but I rarely need that.
- digitalsushi 13y agoI walked around at sharkfest in 2011 and got to chat with a lot of wireshark users during the picnic lunches. What struck me as interesting is that so many people use wireshark that are not network professionals by trade. They are poking through it, trying to just find a clue or two to see what the issue of the day is. I think that's wonderful! That wireshark is accessible enough with the gui to let people who are not diehard packet geeks really take a stab at looking under the hood and having a go at it.
- cbhl 13y agoUsing Wireshark was actually part of the assignments a mandatory course for my undergraduate program at the University of Waterloo.
- tuananh 13y agoQt app still looks like alien on OS X though but at least, it's less awkward.
- matthewmacleod 13y agoIt'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 13y agoHonestly, 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...
- interpol_p 13y agoDo you have any examples of OS X apps written with Qt that are indistinguishable from great Cocoa apps? I'm considering using Qt for an OS X project and would love to see what it can do when used well.
- outworlder 13y agoWith some care, you can get very close to the native look and feel, to the point that the average user won't notice. It does require some work and familiarity with OSX UI idioms.
- radikalus 13y agoExcellent -- 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?
- general_failure 13y agoIs 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 13y agoDownvoter, care to explain? This information is 100% correct.
- mdda 13y ago(I didn't downvote, but) : (0) Reread the first sentence; (1) Dismal tone; (2) Its; (3) Downvote complaint inaccurate in that it ignores (0).
- general_failure 13y agoSorry, all that was just a typing mistake. Fixed. Thanks for pointing it out.
- ihsw 13y agoI believe you meant to say "Qt5 or Qt4" instead of "Qt5 or Qt5." Please correct me if I'm wrong.
- emilsedgh 13y agoQtWidgets are marked as 'Done' it Qt's module list, which means its maintained but no new features are added. However, since this module has been under heavy use in the past, its feature complete and needs no new features. Its still used by hundreds of legacy applications and is in no way 'obsolete'. [0]http://qt-project.org/wiki/Qt_Modules_Maturity_Level http://qt-project.org/wiki/Qt_Modules_Maturity_Level
- general_failure 13y agoOK, so we agree that: 1. It won't have new features since it's feature complete. 2. Nothing will basically change. 3. All new development of Qt project is done in QML. 4. New features will be added in QML only. So, if some cool widget comes along in a new OS version, you don't have it Widgets anymore. For me, it's all but obsolete. If you want to argue about English usage, then that's fine.
- grn 13y agoIs 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 13y agoThat's what is suggested by this blog: http://blog.backblaze.com/2008/12/15/10-rules-for-how-to-write-cross-platform-code/ http://blog.backblaze.com/2008/12/15/10-rules-for-how-to-wri... 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.
- bcoates 13y agoThat link has some solid advice. I had to learn a lot of that the hard way.
- ballard 13y agoThis 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.
- erichocean 13y agoThat's exactly how the iOS app I'm building right now is factored, specifically so that all of the networking/model layer/sync code is identical between iOS and Android. I'm using libuv, SQLite, CurveCP/NaCl and MessagePack for the cross-platform stuff, and the rest of the code is straight C (which I prefer to C++). So far, it's working well, although it did require more effort to set up initially, primarily due to multi-threading.
- AnthonBerg 13y agoQt is very very good at being non-OS-specific. Qt is also a lot more than a GUI toolkit. Until something major changes, me, my colleagues, and my company made the decision to just use Qt. You can do CLI and very very good cross-platform GUIs. Qt is underappreciated.
- staunch 13y agoI just wish Wireshark didn't barf when I throw a 1GB capture at it.
- pjbringer 13y agoJust 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 13y agoGTK3 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.
- secstate 13y agoHrumph ... 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
- guidopallemans 13y agodoesn't this happen with node.js? (I'm not sure at all)
- spoondan 13y agoNode.js is not a rendering engine. It is a platform for implementing server-side software in JavaScript.
- depr 13y agoWhy would you want to use HTML5 for native applications? It's bad enough that you have to use it for websites.
- saejox 13y agoNo no no. I wish i could always use html ui in my applications. It's leagues ahead of layout/form/widget based ui solutions. Styling native elements is like bending metal bars with bare hands.
- secstate 13y agoA 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/
- jcheng 13y agoYou can, that's our app[1] works; it's essentially a webapp hosted in a QtWebKit widget. And Brackets[2] and Light Table[3] work similarly. 1: http://www.rstudio.com/ide/ http://www.rstudio.com/ide/ 2: http://www.brackets.io/ http://www.brackets.io/ 3: http://www.lighttable.com/ http://www.lighttable.com/
- shmerl 13y agoI 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 13y agoFirefoxs use of GTK is relatively minimal, especially when compared to something like Wireshark. Almost all UI of Fx in done in XUL afaik.
- shmerl 13y agoIn 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 13y ago> 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 13y agoPartially, 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.
- AlexMax 13y agoI 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 13y agoThe 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 13y agoIt doesn't dictate your build system. A few lines of GNU make can support it.
- malkia 13y agoMy experience with wxWidgets is that it's full with leaky abstraction... Not really wxWidgets fault here, but the philosophy - they wrap native widgets under common interface. To give you an example - getting the current line or number of lines from wxTextBox control on Windows might in fact do way more than what you expect (the leaky abstraction) - it sends a message to the control to get size/current line - but what that does internally could be something which scans the buffer over and over - so if you have a hundreth of megabyte window with text (log screen) - you might have severe slowdowns. Also I've found it very hard to extend with custom widget and make it right. Qt is much easier, while MFC has been the hardest for me. Juce is also easy, and I guess gtk would be too.
- _-_-_- 13y ago> using Wireshark on the Mac is not a pleasant visual experience. I personally do not give a flying fart what the "visual experience" is as long as it works and the interface is very usable. You know who said something similar in the last few years? Jony Ive at Apple. Even though I like the concept of flat design and really wanted to like iOS 7 at first, it is the first time since Jobs left the world that they royally fucked over the UI. And it was in the name of "visual experience". It's hard to believe they even tested it on humans. To tell you how bad I think it is: I used it for days in inverse color mode, because that was better. If you've used that for a while, you know what that means. I know they tried and they got some things right, but that is the reason you give interface to UE people, NOT designers. Great designers don't make great interfaces. They make great designs. So, screw the visual bells and whistles. Give me emacs and midnight commander.
- znowi 13y agotl;dr We wanted to please the trendy Mac users, hence switched to Qt, which providers a more authentic interface on Mac OS X.
- sigzero 13y agoVast oversimplification...really.
- mindstab 13y agoand say things like 64bit windows (only the most popular desktop OS on the planet) with a non alpha GUI toolkit.
- malkia 13y agoQt 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 13y agoActually 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 13y ago> Swing for a mature looking, cross-platform application Dear lord.
- jebblue 13y agoWhy 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 13y agoDid 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.
- dfox 13y agoMost authors of niche or custom software either don't care about native look and feel (making application with modules written in C with Motif, Qt, MFC, Tcl/Tk, Java and two or so custom languages look seamless is colossal waste of time and that kind of construction seems to be common for most niche things I've seen) or actively make their applications look non-native (Even Microsoft's ERP solutions have decidedly non-native feel to them).
- truncate 13y agoAdding to that, Swing is just almost always annoyingly slow and unresponsive in my experience.
- raminf 13y ago"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!
- ryandrake 13y agoThe 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.
- AsymetricCom 13y agoTransform or overload them. Maybe someone should fork it to a standard-conforming version.
- adamnemecek 13y agoWhile I agree with your overall point, I think that in Qt most of the objects have a reason to exist. E.g. QString, unlike std::string has Unicode support.
- bcoates 13y agoNormally you'd either just use UTF-8 in a std::string or use std::wstring
- mpyne 13y agostd::string with UTF-8 is not a replacement for QString though. std::wstring is actually closer but then you're still going to have to do tons of conversions, and you still don't reach the feature scope of QString.
- sho_hn 13y agoThis is a completely fair point, however I think it's worth pointing out that especially considering the broad range of stuff Qt covers by itself, it's actually quite willing to intermingle with standard C++, and has continued to inch closer to standard C++. For example, Qt's containers work with std's algorithms (including the new C++11 iteration protocol) and Qt 5 introduced a new form of the signal/slot connect that's type-safe, based on templates and can connect to any callable (so including lambda, wheee ...), instead of being a macro that operates on normalized signature strings and annotated methods (while also still allowing you to ditch Qt signal/slots and use e.g. boost's if you prefer). And there's of course also a lot of historical reasons for the overall approach - when Qt started out, standard C++ was significantly weaker both in what the standard contained and how the standard was available. That's not to say I think Qt's mode of operating is obsolete, though; a lot of the value of Qt comes from good API hygiene (pleasant API design, consistent API pattern reuse), and I find that having my $usecase be met by a nice Qt-style API is generally a pleasant discovery.
- stock_toaster 13y agoI use wireshark regularly (on OSX these days). Looking forward to this!
- guilloche 13y agoWhy 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 13y agoNo different opinion allowed? Please give me more down vote, I do not care in fact.
- derleth 13y agoIt's not the difference of opinion, it's the fact your post adds nothing to the discussion. This adds even less.
- yeukhon 13y agoWell, 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 13y ago> 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.
- clumsysmurf 13y agoThe 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 13y agoThe 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.
- groovy2shoes 13y agoMuch 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 13y agoThough 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 13y agoRight, that's why I'm wondering :)
- hcarvalhoalves 13y agoGreat. 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.
- _-_-_- 13y agoPoo. 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.
- sambecket 13y agoThere'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.
- b4d 13y agoLooks good, just needs some retina support on OS X.
- BinaryBrainz 13y agoIn 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.