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.
This 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.
Interesting, I'm wondering how Qt types make porting more difficult? My experience has been that if I only used standard-C and Qt types, I had no issues in porting. A recent project I worked on only had a handful of platform checks (and all but one of them were in the project file), and compiled fine on all platforms. In fact, I developed it entirely on OSX first, and then simply adjusted the build to support the different OSes later, and didn't have a single problem.
Mind you, I -only- used Qt standard libraries (except QExtSerialPort which was the best option for serial access at the time I started the project).
I definitely agree with preferring Q-types to STL. Combined with Creator as an IDE, it's brain-dead simple and I spend my time on higher-level concerns. (FWIW, I wish Creator had more languages supported, I've never had such a wonderful experience in any other IDE. I want to shoot XCode every time I open it, mostly because Creator has spoiled me on how good auto-complete can be.)
If you already have a codebase that's littered with STL, you need to make a few changes here and there. I was thinking about "porting your codebase to Qt", which isn't quite a correct usage. Sorry, it was kind of late in the evening :(.
While 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.
std::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.
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.
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.
> 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
same think can happen with gtk or any framework (toolkit, actually, to be pedantic about it), and anyway, in an oo language especially, there are design patterns to cope with this.
Go look at GLib (which underpins GTK+), it has its own string type, its own boolean type, even its own object-oriented programming scheme emulating Java-style OOP.
Of course they have more of an excuse given that they wanted to stick with C instead of using C++ due to (at the time) poor language design and compiler support. But then again, that was Qt's excuse too! ;)
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.
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.
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!
Righto, I was off-by-one on that, thanks :). We're currently transitioning to Qt 5.2 which involved upstreaming lots of things we need in there, so it's become a mental habit to think of anything shiny we're using as being new in 5.2.
So far we consider Controls to be very promising, but there's plenty of gaps (no form layouts, incomplete QStyle support, some pathological performance problems, lacking automatic keyboard accelerator management, plain missing standard widgets, etc.) that don't quite make it stand up in comparison if you're serious about desktop use (which we are), so I think it best not to overpromise.
We're making quite an investment into the technology anyhow, though; it'll get there with time (and effort).
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.
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.
Depends. QML sits on top of technologies and API fashions that Qt debuted before QML came along, such as the QAbstractItemModel API contract and the QObject property sytem, as well as QMetaObject in general. Porting an app to Qt Quick Controls is significant work (and currently will get you lossy results as mentioned above), but there's a lot you can do to prepare while using QWidget, or quite possibly already did because it was compelling and useful to architect apps that way before already - so you can likely plain reuse a lot of your code. And the fact remains, there's no pressing need to port to Controls anyway.
This shows a complete lack of understanding of what's has already happened in the Qt project (notice the past tense).
Qt widgets will not see any improvements. They haven't see any improvement for the last 2 years. Here, answer these questions for me and decide for yourself:
1. What new APIs were added in Qt widgets in last 2 years?
2. What new widgets were added in the last 2 years?
3. Is the Qt team working on improving various look and feel aspects of widgets on the Mac and Windows 8?
First of all, Qt 5.2 is seeing plenty of new APIs and improvement for authors of QWidget-based applications. Here's a random smattering of concrete, technological examples:
* KDE upstreamed tons and tons of little widget features from its kdeui library into Qt, e.g. more complete keyboard navigation and title support for QMenu, tab bar hiding for QTabBar, default vs. active shortcuts in QAction, clear buttons in QLineEdit, URL drops in QComboBox, place holder texts in QTextEdit, ... there are several dozen improvements to widgets, I don't know where to stop. KPrintDialog features in QPrintDialog is pretty big. QColorDialog, QInputDialog, ...
* KDE upstreamed lots of things it used to do via KGlobalSettings and KStyle into QStyle and Qt's platform plugin system, which means pure-Qt QWidget apps now integrate a lot better with KDE and potentially other target platforms.
* KDE upstreamed its KStandardDirs APIs by adding and extending QStandardPaths, which allows applications authors to more easily deal in standard locations on various desktop platforms.
* KDE upstreamed lots of work on Qt's MIME type system.
* KDE upstreamed its X11 session management handling.
* Lots of stuff in QDesktopServices, QCommandLineParser, QLocale ...
So ok, that should put the "no improvements" spiel to rest; you're not really aware of what's been going on. But even if this wasn't so - why would QWidget be bad to use just because it's not making huge changes?
Let's be clear: Qt 5 swapped out the entire backend underneath QWidget by porting everything to QPA, and it just keeps working. That didn't take no effort. That's called commitment.
You can't add API into Qt 4, there are new additions only in Qt 5 and as someone already explained, a lot of stuff from KDE widgets is being upstreamed to Qt 5. New widgets and API are being added. There are no or just little changes simply for one reason: why change something that works? To change stuff just for the sake of change is not a justification and it would only make it more difficult for devs to port their apps from Qt 4 to Qt 5.
I don't see any significant risk there. QWidget has many large commercial as well as FOSS deployments that will see it stick around for many years to come, and Riverbank's PyQt Python bindings are likewise used by many large commercial and FOSS offerings, and very actively maintained, tracking upstream Qt quite closely. I've written some PyQt apps as well (alongside lots of C++ and Qt Quick) and I think it's a very nice way to use the toolkit (in fact I'm relieved C++11 added some of the things that made using PyQt so nice).
I've been a KDE developer for the last 8 years, and in that time I've seen Qt steadily improve as an open source project. When I started out using Qt, getting code into it was essentially impossible without becoming a Trolltech employee. Today it's quite open to its various stakeholders, who manage to collaborate constructively. My confidence in Qt's resilience has increased with our level of agency in making that resilience happen.
Aye, PyQt has recently also introduced some pretty interesting new Python integration bits with the new pyqt5qmlplugin that allow you to write QML extensions in pure Python without C++ boilerplate.
Completely misleading. Have you ported a Qt Widgets project to QML? Show me the code if you have done so and I would agree that I am wrong. They are completely different code bases.
You seem to be misunderstanding my argument, which is that there's no risk to writing a QWidget app because there's no need to stop using QWidget, as QWidget isn't going away. You've yet to produce any arguments for why this isn't correct.
I don't have a reply button anymore to sho_hn's comment. Take this as a reply to the adjacent comment :)
What I am saying is: if you have a new _native_ widget in a new OS release (layout spacing, new views, new controls, new features - there are so many), it won't be implemented in the Widget code base. The Qt project will tell you to use QML. How are you going to make your C++ Widget based app look modern now when all your code is QML based?
Answer: there is no answer. The Qt project has made it extremely difficult to decide for their existing users. For new users, it's a trivial task to choose QML but how many new desktop apps are being developed from scratch these days.
Several of the things you list are the duty of the platform plugin and the style engine plugin and don't actually require any changes to the core widgets. Yay layering.
Personally I think entirely new widget classes should be accepted into the QWidgets module, but you may be right that there's some resistance to that - but the bar for new widgets has always been fairly high actually, it was a rare occurence even before QML (neither Qt 3 or Qt 4 saw much in the way of new widgets during their respective lifetime). I think the case that a lot of the "new UI challenges" are better met by QML is also somewhat legitimate, in which case there's an incentive for porting to it.
OK, 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.
1) It can have new features - the are some upstreamed from KDE, and it's just about users coming with new proposals - nobody cames, no new features. Easy.
2) Why would you change something that needs no changing?
3) Lot of efort goes to QML, yes. Why not?
4) Maybe. Nothing prevents you from writing QWidget equivalent of the "cool" QML widget and upstreaming it.
Obsolete stuff is unmaintained. You can rest assured that QWidgets will be maintained and bugs will be fixed.
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.
Qt 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.
Qt 5.2 also adds Windows, Mac, and Android extras (platform-specific things for a native feel) [1]. For example, on Windows you can set the task bar progress, and on OS X you can use some native components, such as the toolbar. The OS X documentation is poor, but there is a GitHub repo/mirror for it [2]
The last time I built something on Qt was some 10 years ago, but it was the only time where I really enjoyed programming in C++. Underappreciated indeed.
That'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.
This was the approach that Transmission used, although it gets kind of weird at times. (The GTK and Qt interfaces can be used with the server/CLI bit built-in, or you can attach them over an HTTP/JSON RPC to a headless server; there is a CLI command (distinct from the server) that runs standalone, and there is a different CLI command that connects to a server over the HTTP/JSON RPC and controls it; some subset of the clients and the headless server come with a web interface that manipulates the "server" bits using HTTP/JSON etc.)
Assuming that you solve the CLI bits, using Qt is probably reasonable enough for all your GUI users that aren't running pure GNOME/GTK systems -- at one point in the past, Qt could even make itself look like the current GTK theme (although I'm not sure if that's still true now).
It's still true today. Qt bundles a style engine plugin that calls into the currently active GTK+ theme. Qt also has a concept of "platform plugins" that make it DE-aware and pick up various behaviors that go beyond looks.
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?
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.
"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."
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.
My 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.
> 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.
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.
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...
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?
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).
No 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.
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.
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.
> 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.
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
That also provides fast startup.
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.
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.
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?
I 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.
Is 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.
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.
Some (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.
The 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.
Yeah, 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.
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.
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.
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.
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.
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.
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...
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.
No, really swing is aweful. I had to use many years ago, and it was very slow then. I've liked SWT (native+java) from eclipse for a while, but wanted to use more on the native c/c++ but wasn't that straightforward...
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?
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.
Most 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).
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.
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.