Wireshark 2.0: Now with Qt
lwn.net
lwn.net
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".
wxWidgets is different because the code is native - it is a C++ wrapper around the Cocoa code, so you make calls in C++ and it actually calls Obj-C code behind the scenes (plenty of .mm files in wxWidgets). I do not know if Qt does this or whether they do their own drawing of controls in some instances. (wxWidgets does draw some of its own controls, eg. toggle button on platforms older than Yosemite/El Capitan I think)
But the Windows compatibility of GTK is just horrendous. It seems to work now with the help of some people GTK 3+ can be used on Windows, but the icons sometimes don't work, transparency never works, expander window grippy thing doesn't look right, fonts look terrible, responsiveness is terrible, form fields look terrible and don't function normally, the list goes on and on.
Qt makes that relatively easy and painless.
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.
GTK3 is perfect if you want to develop for the GNOME desktop. for anything else it would need way more developers that are not focused on GNOME
QT caters to more platforms, because QT _is_ Digia/The QT company's product. For Gnome devs Gnome is the product.
So yeah, I agree with you: GTK3 is great if you do Gnome, QT otherwise. But some people in this thread (not you) seem to blame or resent Gnome developers for doing their jobs, which strikes me as odd, to say the least.
furthermore it is still advertised like this as well (from gtk.org):
What is GTK+, and how can I use it? GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces.
Where can I use it? Everywhere! GTK+ is cross-platform and boasts an easy to use API, speeding up your development time.
from my point of view, this is not exactly true anymore ..
More like: if anybody else wants to make GTK work better with other platforms, they're welcome to do it.
It may have been a universal toolkit, but if the people that made it so disappear, it's unlikely it will continue to be universal in the future; that's just the way it is.
Not really evil, just focused on other areas.
That's a problem that's better solved by the window manager, not by the application.
Ideally it would be nice to enhance all window managers and somehow make this possible in a different way. You'd still have practical problems in that the theme of the window manager won't align with your toolkit though.
But I prefer actual progress instead of the theoretical ideal solution that's way more work and involves co-operation with everyone.
Oh for the good old days when window management was so simple and straightforward, that all you had to do was memorize and follow every nuance and implication and extension of the ICCCM, before testing against every other application under all possible window managers in every platform environment with each possible hardware variation.
> But I prefer actual progress instead of the theoretical ideal solution that's way more work and involves co-operation with everyone.
You know what? Let's start by not making these silly thick titlebars, and not making these silly assumptions that everyone uses the library / framework of the day. Because these are actually idealistic and will never work out in practice.
GTK hasn't learned from the Windows 95 style GUIs (don't know any names) which never had any space problems in the first place. But I think it has a lot to do with portability to netbooks / tablets / smartphones in that they drove this development (look at Windows 8).
I use one that merges the title bar and the task bar! Like so
https://i.imgur.com/Zb5BoMf.png
> Even if there is, you need to think of Wayland as well.
I prefer not to.
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.
> 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.
Yes, other desktop environments have this debate. In Mac OSX, open any recent app and you'll see titlebars with actions (e.g. play/pause in iTunes, addressbar in Safari, etc.), presumably to compact window chrome.
I now the technical separation of window manager vs toolkit. It's nice that you can always close the window. But practically speaking, CSD gives me way more space vs some theoretical idea that "it should not be done".
The consistency argument I don't see. GTK+3.x apps can disable their CSD when running on other desktops. Within GNOME 3 though, it is consistent. Initially the apps would default to showing CSD but AFAIK latest GTK+3.x ensure they don't.
Anyway regarding consistency: It is way nicer! If it is way nicer, then why hold back for consistency? You'd never be able to make a change. And basically there are two toolkits anyway, Qt and GTK+. I've been around for ages, but FLTK/Java stuff, etc... eventually you'll go down to a: no change ever.
You said it is a compile time option. AFAIK it is not at all. Though with Wayland the use of xsettings is more difficult. They are specific to X after all.
Regarding mouse wheel support you didn't give an example?
In case of anything else you disagree with, please speak up as changes happen (d-d-l). It is pretty difficult to go against a decision that happened a long time ago. E.g. I could give a "this is bad / better revert" but unless people complain when things happen it is pretty hard/difficult. Notebook I didn't notice nor knew for instance.
I do see other changes that are made, but usually when that is done they seem to have investigated how often it is used (not just git.gnome.org). Usually they find 0 or 1 app and that app is on git.gnome.org.
GNOME 3's default theme has the slimmest window chrome any GNOME has ever had. People think it's space-wasting because the fonts are larger, but they got larger-looking buttons in fewer pixels by compressing everything into one place. It's only space-wasting if you're using applications that don't support menus in the title bars, and even then it's about the same as GNOME 2. You can check it by running GNOME 2 and 3 side-by-side.
Even if that was true, what your parent said is that it's space wasting (in absolute terms). Which is actually an understatement.
> It's only space-wasting if you're using applications that don't support menus in the title bars
That's really two pairs of shoes. And assuming support for the gimmick of the day (which also presumably only works for GTK3 apps) is totally insane.
And btw the default theme also sucks in that you can't easily see which window has keyboard focus. And if you change the theme, it gets messier as your parent described.
Sorry to get meta, but what is the rationale that HN doesn't show the number of upvotes to your comment? I hate that you get three counter-comments and zero agree comments (because it's dumb to comment "I totally agree"), but the fact that (presumably) most people agree with you is hidden from the user.
However, I'm often very interested what people's opinion is. For example, that has a strong influence on my temptation to raise my voice if I have strong opinions. So accessible vote counts might help reducing noise and pointing out where the controversy is.
I think it would be a great compromise to have the vote count one or two clicks away.
These days, they have a person running around reminding people who succumb to that temptation not to. Seems to work well.
So accessible vote counts might help reducing noise
It introduces noise very similar to the 'visible downvotes' noise.
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.
Will never happen. Instead, if you want consistency, avoid redundancy in the first place (where it's practical)
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.
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...
Sounds very unrealistic, doesn't it?
Certainly, but at least I can be sure that the inter-application[1] inconsistency in terms of overall window behavior/L&F is minimized (as far as practical) if the decorations are server-side.
... and that's a real win, at least from my perspective.
Others may place a higher value on the intra-application consistency of client-side decorations. Obviously, if, say, you're using KWin, but only GTK/Gnome apps you're probably going to prefer this option.
Thankfully, it seems that KWin[2] is going to allow both and is going to try to standardize a wayland protocol, so that users can choose what they want. Hopefully most Wayland clients will eventually respect this protocol -- we'll see.
EDIT: I should also just give a shout out to Mr. Gräßlin. He's been an incredible boon to KDE. (No affiliation, don't know him personally -- just a fan. Hopefully he'll read this!)
[1] For applications using different toolkits, obviously. Otherwise it doesn't really matter much except for misbehaving-application cases.
[2] http://blog.martin-graesslin.com/blog/2015/12/server-side-de...
See my other comment here:
https://news.ycombinator.com/item?id=10759579
As a TWM user, I have no idea what you're arguing against. GTK-3 is prettier, more functional and normally more compact than GTK-2. On top of that, smooth scroll is a blessing and touch support was lovely for PDFs when I had a touch screen.
You can do that without client side decorations.
KDE with Qt even plans to allow telling the Window manager to render specific widgets in the toolbar.
The manager can ignore that, and render them as separate toolbar – or even render them in a bar at the top of the screen.
Also the Gtk developers are (probably) not evil, they just happen to also be the Gnome devs and have made some choices that are a little questionable to the rest of us.
I used ratpoison/ion3 from about 2000 through 2007 and then switched to OSX. So I never saw this ...
You're saying that in modern Xwin/Xorg, the actual applications have title bars and so on ... such that if I were using RP/ion I would see the titlebars ?
Is that what you're saying ?
Go open the Steam client on Linux, it is using CSD so it always has min / max / close in the top right.
(That's my understanding from the pro-CSD crowd, I'm personally pro-SSD, so I may have misunderstood unintentionally, but I think I'm being as charitable as possible in the above interpretation/description.)
You'll see the titlebars anyway because they contain worthwhile controls now. You know, like with Chrome putting the close buttons on the tab bar. Evince (a document viewer) has the page number, back-next, find, annotate button, zoom controls, options dropdown and a lil' more on there, for example.
The other thing is that the control buttons you won't want are opt-out:
https://wiki.archlinux.org/index.php/GTK%2B#Client-side_deco...
https://wiki.archlinux.org/index.php/GTK%2B#Client-side_deco...
In GTK2 applications I can start typing the file name and the selector jumps to the file. E.g. I type "f", it jumps to the first file with name starting by "f", then I type "e" and it jumps to the first file with name starting with "fe", and so on.
In GTK3 they implemented some kind of filter, so when I type "f" the selector doesn't move but the dialog will show only everything containing "f" in its name, even in subdirectories! In big directories with many subdirectories and files it slows down everything while it's doing its filtering.
From the article "The main reason behind the change was to better support Mac OS X, which is something of second-tier platform for GTK+"
From the perspective of 'UI toolkit for cross platform development' Qt is superior over GTK+. If you want the best Linux desktop toolkit GTK is probably a better choice.
but consider that Qt aims to blend nicely into a GTK-based desktop environment, while its sometimes not even possible the other way round - eg using the "native" widgets of the desktop environment like file dialogs etc
"cross desktop environment" or whatever you might call this, is definitely not a top priority for the gtk-devs (see https://bugzilla.gnome.org/show_bug.cgi?id=735211 for example)
its all fine if you develop for GNOME only, but you should be aware of GTKs current limitations when it comes to writing applications that look nice on all linux desktops
and porting from one toolkit to another can be heaps of work, so choose wisely..
Other than that, describing GTK3 as "the official Gnome 3 toolkit, beg us if you want interoperability" seems pretty accurate. I personally enjoy the experience provided by GNOME 3, but will never, ever, use a GTK app under Windows or Mac OSX. They just look and feel terribly out of place.
However, does GTK have much choice given the resources at hand?
- With the Adwaita theme now being rolled into GTK itself, it's becoming clear the GNOME/GTK folks are not aiming at a good Mac/Windows experience, they're maximizing for Linux + the whole GNOME shebang.
- Could they do otherwise? Qt is backed by a big team at the Qt Company (ex Digia / Nokia / Trolltech) with commercial interest to support big $$$ Windows/Mac-based enterprise apps, while GTK seems maintained by a smaller core team of RedHat/Fedora folks, Canonical not so much, and individual contributors. I think they're just focusing.
* http://blog.martin-graesslin.com/blog/2010/05/open-letter-th...
* http://blog.martin-graesslin.com/blog/2010/05/why-you-should...
* http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-c...
* http://blog.martin-graesslin.com/blog/2015/11/october-plasma...
But looking at the first link (which is kind of a summary if my understanding is correct), I don't see any mention of the most important benefit to me: controls-in-titlebar.
Am I missing something? Is Martin avoiding it, or is it a non-problem that could have been solved without CSDs?
In KDE, the current plan of some is to allow the window to give the window manager the info that it should put some widgets in the window bar.
The manager could then put them in the window bar – or at the top of the screen – or in a separate toolbar.
This provides the advantages, and avoids the disadvantages.
https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candi...
Just look at stuff like Gimp and Inkscape - those things are atrociously bad from GUI perspective - huge ugly icons, huge panels with pointlessly large input fields/sliders and other controls - the ammount of space you need to scan and is effectively wasted is staggering.
It's like they want to make GTK+ a toolkit for pretty "two button apps" and "image viewer software with all the controls on the toolbar". Don't get me wrong - I like those designs - but those are of very very limited use - doing anything complex in GTK+ is just a no-go as shown in numerous IDEs/tools that use it. It's just built with the wrong set of defaults IMO. And I have no doubt that with some work you could reshape it to be much more usable - but the thing is most developers don't have that kind of knowledge, time or affinities.
If it integrated into native file dialogs and such I wouldn't care if it "looks non native" - intellij IDEA looks non-native as well - it still looks great. Can you imagine how IDEA would look like if it used GTK+ controls ...
GtkToolbar {padding: 1px;}
GtkButton {padding: 4px;}
GtkComboBox GtkToggleButton {padding: 2px;}
GTK exists because of Gimp. Gnome came later. Sadly, the GUI of Gimp is still behind of Photoshop.
Gnome 2 and KDE 3 were fine, then everthing went downhill. Nowadays Ubuntu and Gnome2-fork (Mint) are okay.
Maybe implement a transparent theme that looks familar to Vista/Win7 users? Most users aren't that happy with the Win8/10 theme, that can't be changed.
It really is more of a theming problem – Gnome 2's standard themes were in the really awkward spot where the controls are far too big than they need to be for mouse or stylus input, yet not big enough for touch input.
(Back then, I had a stylus-enabled X60 Tablet – with a whopping 1024x768 12" screen. I modded my GTK2 theme to have 8x8, 12x12 controls and icons, instead of the standard 24x24, 48x48. 30% more usable screen size without any changes to applications.)
With Gnome 3 deciding to focus on touch screens, they had to do… something! And that something was making controls even bigger. And to offset that, they decided to introduce CSDs. There's a dozen other ways that could have been taken instead, like not using a touch interface on non-touch devices.
Completely agreed, see my other answer to user `moonchrome`: I, too, make tweaks to my gtk.css to fix this, and I wish they had instead a "Tablet" on/off switch that would increase/decrease padding and widget sizes.
Well, maybe I'll get some flack for saying this without providing much evidence. But they aren't a very welcoming group. They have been very insular and tied to RedHat which is driving a lot of the GTK development.
The GTK developers are also incredibly resistant to changes. For example, the code base is still required to follow c89 because some arcane compiler somewhere doesn't support c99 yet and because the greybeards at RedHat thinks it looks nicer with all the variables declared at the top. New developers also struggle with autotools and there has been several calls on the mailing list to replace it with something else (virtually anything) but those suggestions also get shot down because autotools is what the GTK developers know and use.
Just to be clear, I'm not blaming. It is not objectively wrong to be incredibly resistant to change. And GTK is a decent and very polished product. But it is one of the main reasons why GTK doesn't get a lot of new contributors, or resources as you call them.
That would be Microsoft Visual C.
Gtk+ on MSVC is supported, sadly. It'd be really nice if it weren't, because then glib could be C99 and we'd all be really happy about it - the glib developers aren't stooges refusing to go forward, they're stuck between a rock and a hard place by Microsoft's amazing reluctance to build anything resembling a sane compiler and over a decade of binary stability.
Yeah, Gtk+ could've thrown the "fuck you" to the Microsoft compiler when they broke for 3.x, and in a lot of ways, I wish they would have, but making those decisions usually means porting software, and so nobody's willing to do it in a 3.x branch. Maybe when the fabled Gtk+ 4.x rolls around.
On a cursory grep through the gtk+ codebase, I can't find a single use of "new" as a variable name and only a scant few instances of "class". The gtk+ coding guidelines already recommends you to write "klass" instead of "class" probably for this reason. Replacing the remaining bad names isn't an onerous task. It's a days work for one person at most.
Some more details: Replacements for autotools often only handle the simple case. Widely known that autotools is difficult, however, the replacements cannot do what the GTK autotools is used for at this moment.
For the compiler: I think the Microsoft compiler is holding us back? Further there are two important parts: glib is used almost everywhere, so you have to be very strict in what you accept. GTK+ should be more easy going. They did add that support for (IIRC) automatically freeing variables.
Tied to Red Hat is very unfortunate. However good willed, it is better if there is a group of similar sized companies. I'd wish there were more (free software) companies the size of Red Hat.
So if the question is "why does GTK have a resource shortage when Qt does not?" then, imho, that is very easy to answer.
From my perspective, GTK has been mired for a very very long time. Essentially from its inception it was something that was required for other missions. There have been tons of volunteers and people working on it but I'm not sure how much of that was because they needed it vs because that's what they love to do. I also have some suspicions that certain UXy/visual type problems just don't seem to be good fits for the bazaar model, all my evidence would be tied to GNOME, GTK, and GIMP for the most part so I could see how I might be wrong. If it's being held back by some Redhat folks that are paid to maintain it because Redhat went all in with it decades back, a fork could potentially revitalize it.
Why do people always assume newer = better? Get the basics right. Yes, declaring your variables at the top does usually look nicer. It requires more code discipline, it often forces you to better decompose your code, but usually results in better code structure and readabilty.
C is not a language to program at scripting speed in the first place.
Among other small refinements, C99 is a set of features on top of C90, such as declarations anywhere, restrict pointers, and complex numbers. If you don't need these features, restricting to C90 is a very effective way to have your code auto-linted.
However, declaring variables close to where they use is a different kind of "cohesion", since it's keeping related things together -- just related in a different way.
I see your point, but it's still a matter of taste.
Cohesion is about keeping unrelated things apart (to avoid accidental complexity).
If two things are semantically unrelated, you should be able to name both (yes, it is hard). If you want the separation statically asserted keep them syntactically separated [1]. There you go -- make two smaller functions, each with a clear scope and a descriptive name.
If you feel a function is doing unrelated things (because the data is not very "cohesive") but can't tell why, why not being honest about it and still host all the variables at the top.
Being disciplined in this way has found me appropriate code factorings, and many bugs in previously ill-factored code, both syntactic and semantic.
[1] in John Carmack's words "what's syntactically allowed will eventually end up in your codebase"
I can't help but to notice the irony of your statement in a thread about GTK3 (since they are ripping out functionality in the pursuit of newness)
And from a programmer's standpoint, I wish we could end this battle already and someone just tell me what to use so that my app can become a part of everyone else's consistent look.
No great loss.
The "old" camp that has been with the ecosystem since the late 90s, and the new camp that came in with the post-dot-com/browser-war cheap and easy access to LAMP servers.
The former knows Linux from the kernel up, where the desktop is for the most part a way to deal with things that can't be represented in text.
The latter knows Linux from the desktop down, and want those shiny graphics everywhere.
GTK2 is of the old group, where tweaking and maximizing personal efficiency was king.
GTK3 is old the new group, where presenting some kind of top down design experiences is paramount.
Hell, it may not even be limited to Linux. Look at how Slack is getting all manner of attention, even though at its base it is IRC recreated. But now you can plaster every line with emoji(?!).
Damn it, i should not be feeling like a grumpy old geezer. I'm not even half way to retirement...
I've switched to KDE Plasma desktop on Fedora as my primary work environment now and couldn't be happier. If I wanted to write a native X app now, I'd definitely be thinking QT.
When QT first switched to LGPL, I hoped it would result in an explosion of interest in that environment. In hindsight, "explosion" would probably be an overstatement, but the K/QT world does seem to have been growing and improving since then.
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.
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/). Without MOC, QT really feels an awesome API.
I'm pretty much locked into 4.8 (and it's eternally open tickets) for life.
Huh? Qt5 doesn't require Wayland; I've used it on X.
Yeah, um, not possible for me. I use the Linux framebuffer and that's it.
That's my understanding at least, I don't use Qt on embedded platforms though, can anyone confirm this?
http://doc.qt.io/qt-5/embedded-linux.html http://stackoverflow.com/a/21489384/331041
* It's HUGE. A "hello world" QML program is like 50 MB. You can get it down to about 20 MB is you use a custom Unicode library build (there is a 20 MB DLL which just contains Unicode data).
* The QML compiler is only in the commercial version. I know there is a third party open source version, but that is too much hassle. And yeah maybe I should pay, but hey!
* Lots of things still are impossible with QML. There's no decent basic text widget (e.g. for a log output).
* You can make custom QML widgets, but they can't render text. Kind of limiting!
* I don't think the basic premise of QML works that well. There is such a big difference between C++ types and QML types most of your code ends up dealing with the mapping. Especially lists of things are very hard to get right (and the documentation doesn't really point you to the "right" solution - which is to subclass QAbstractListModel if you were wondering).
* QML seems very hacky and javascripty - it doesn't scale well. Especially scopes and id's.
* Some QML things are weirdly hard, for example
- Rich tooltips
- Adding padding around list items
- Doing anything with the rich text widget.
That said, I still really like it. I'd just like it more if they:
1. Reduce the size.
2. Redo QML (again!). I'd be even ok with a custom language. It can be similar to Javascript, but it should support the native C++ Qt types (and custom ones) much easier.
QML is designed with mobile in mind. For heavy desktop UI, Qt Quick Components, kinda fills the need.
Qt Quick 3 would be unwarranted, but a lot of maturation needs to happen.
The effort for doing from scratch native widgets in QML was greater than the approach I took, specially because Qt didn't provide wrappers for the APIs I cared about.
- 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/tsharkJokes aside (sorry), it's an absolute godsend when trying to debug embedded systems.
Life saver when debugging even mundane web servers:
tshark -i eth0 -O http -Y http
More keyboard shortcuts always makes me happy. Less usage of that tiny little touchpad on my laptop.
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.
So if they already stick with native UIs, let them use Qt.
And it's not like GTK+ or Qt are immune from having security vulnerabilities. They're rarer than the general class of browser vulnerabilities, but they exist (e.g. Qt had a few image decoder vulnerabilities earlier this year). I'd guess they're about as frequent as the specific subset of browser vulnerabilities when viewing a trusted website.
If it's a helpful analogy, this is roughly like how Java is a terrible platform for running untrusted applets, but a perfectly fine platform for running software and a very common one for security-sensitive servers. (Except the browsers themselves are way better than the Java plugin.)
If you are hiding the fact that you're browsing pages random page from the web in your native UI, then you have bigger problems than the update cycle.
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.
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.
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.
Though I will say that the inability to expose a go strict/object as a model is quite frustrating; there's lots of back and forth mapping your go objects to update your qml models. It would be much nicer if it was easy to implement as adhering to an interface or embedding an existing type :(
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.