LXDE and Calculate Snub GNOME 3
A little GUI toolkit news, courtesy of some links from a reader…
PCMan has created what looks like a qt fork of PCManFM, and there are some indications there and elsewhere that other LXDE components may be moving in that direction.
PCMan does great work in the lightweight FM area – you can thank him for SpaceFM, as it was built from the legacy PCManFM as a base. However, it should be noted that the current incarnation of PCManFM is based on gvfs/udisks, with all their incumbent issues and GNOME dependencies. This is something which PCMan never liked, and likes even less now that he sees how they perform, so I wonder what he has in store. I know he’s already working on a fuse-based udisks replacement. Yet the rewrite probably got the code in better shape for a qt transition. Will be interesting to see what comes out of that camp.
Also, the Gentoo-derived Calculate distro has announced for their latest 13.4 release:
GNOME3 is no longer supported, as CLDG now features GNOME 2. We’ll not be supporting Gnome in next versions.
This seems like a mass lightweight (if I may combine those) migration away from GNOME3/GTK3, which is clearly being developed in a corporate/hostile-to-free way these days (background). Good for them! Hopefully this spells longer-range support or a viable fork of GNOME2 & GTK2. I’m of the opinion that GNOME3 should have been a fork, not a new major release version of GNOME, as they covered a great public park with concrete.
I’m personally watching these GUI toolkit directions carefully. qt doesn’t excite me much more than GTK3, but its probably somewhat better than what Red Hat has planned. I’ve been toying with the idea of a flexible GUI engine of sorts, perhaps to gradually and eventually replace SpaceFM’s GUI, and take it to the next level. But I’ve been stopped because I don’t like the toolkits available, and things seems so volatile. (It’s not pleasant to invest hundreds of hours on a toolkit, and base software on it, only to have it turn to sand under you.) Perhaps at this point a multiple toolkit framework is best, but that still represents an investment in a particular API.
Linux is really hurting in this area – hard to develop anything decent without wasting your time rewriting the GUI every other day. I’m glad I did SpaceFM as a prototype rather than investing a full design in GTK, but in some areas it’s ready for some new components to allow it to grow, yet I’ve been hesitant to write them in GTK. Overall I would like to break away from Red Hat/GNOME now that they’re poisoning the GTK well, but not sure that qt is for me either.
36 Comments
Sorry, the comment form is closed at this time.
IgnorantGuru's Blog 
Some Reddit discussion of qt vs GTK. Interesting though I think it’s more a Windows-friendly crowd that likes qt. Cross platform sounds nice but what results is that the code gets commanded and poisoned by the Windows/corporate desires. So it appears similar to Red Hat controlling GTK. And C++ has its costs.
What about wxWidgets?
First, wxWidgets is just a wrapper. It’s still using GTK+ under the hood if you’re on Linux.
Second, it’s based on C++ but, unless it’s had a major rework since I last used it, it has an API much more awkward than Qt.
Third, more often than not, it takes the same approach as Java’s ATK and you end up getting a feature set limited to what all the desktops have in common, rather than what is most useful for actually getting things done.
Finally, it’s been my experience that Qt and un-wrapped GTK+ both do a better job of helping you to write an application which feels native to the platform you’re on. wxWidgets makes it easier to overlook something you don’t have enough experience with to notice.
You’re not really avoiding GTK (and its issues) that way, as wxWidgets is like a front-end. It’s yet another layer to deal with – mainly geared to cross-platform and easy-to-use bindings, which isn’t a priority to me (running a Linux file manager on Windows has bigger problems than the GUI). Plus for the performance required in a fast file manager, native is good – you don’t really want more layers in there. And it’s also good to get close the native GUI tools to have better control for purposes of a customizable UI like SpaceFM has.
wxWidgets seems to have some positives. And Tk has fans too. There are various solutions, but there are tradeoffs with each that make the overall options more limited than it first appears. The corporate solutions (eg qt, gtk) are more highly developed and modern looking, but they are bloated and aligned with the usual corporate technologies, and they’re moving toward dumbed down tablet-type interfaces. Plus they’re not really developed in a pro-user environment, as you well know. The more free solutions lack the modern look and themeability, and don’t have the resources, often kind of stagnated, yet functional. Although something less rapidly changing would be nice from a dev perspective, it does limit what tools are available to implement interfaces, and users miss the modern aspects, not all of which are merely bells and whistles.
Software like SpaceFM really needs a GUI toolkit with high level performance that is very complete and capable. It’s hard to avoid the qt or gtk two-choice menu. But I’d like to research the options more.
I’d wait and see what the LXDE guys do.
My three main reasons for preferring Qt for future development are:
1. The Qt developers are close enough friends with the concept of API stability that I’m told it’s feasible to support both Qt4 and Qt5 using IFDEFs.
2. QGtkStyle is part of the officially-supported Qt distribution and works very well, so theming choices aren’t unreasonably constrained. (I use both to fit in with LXDE and to force GNOME/OSX-style dialog button ordering on Qt since it’s provably superior and most Qt themes lock it at Windows/KDE-style.)
3. There is an in-development effort to provide QML API wrappers for the native widgets and the current target is to have something, complete or not, suitable for merging into Qt 5.1. (I’ve also heard rumblings about efforts to get KDE’s Plasma and various Qt-based smartphone widget sets using the same QML API but I don’t know how that’s going.)
However, the LXDE guys do plan to look into how much work is required to make gtk-engines-qt fit their needs, which would just leave the question of whether anyone in the larger 2.x-using community will have the time, skill, and wherewithal to take maintainership of GTK+ 2.x.
As for other widget toolkits, theming is going to be your biggest problem by far.
The two posts on my blog about getting Tk to fit in with GTK+ are the 9th and 12th most popular posts overall based on unique visits for the last 30 days (and both are old enough to have stabilized), and not all visitors follow the links from one to the other so the combined popularity is almost guaranteed to bump it up to at least 8th. (I don’t have the tooling to easily count how many visits touch one or the other without double-counting ones that touch both)
Keep in mind that some of the things higher on the list are stuff like “Downloading YouTube Subtitles”, “Getting your way with setxkbmap”, “Modernizing XTerm’s Paste”, and a post about Fat-Free Framework that’s linked from its website so competition is stiff.
Wow, only yesterday I was thinking why isn’t there a decent lightweight qt based file-manager and why you haven’t moved spacefm away from gtk. And today you bring this great news (I use pcmanfm, mainly midnight commander, but pcmanfm for some tasks).
Unfortunately, though I like qt from a user’s point of view (I am no developer), its corporate roots and uncertainity about its future trouble me. Maybe kde will take over qt, if there is trouble in the future.
For some applications, switching to Qt for a more cross-platform approach seams logical, but for a filemanager in linux…
Unfortunately, given how much many users (myself included) value having a consistent and “not Motif” look to their applications, GTK+ and Qt are the only real options. They’re looking into Qt because nobody with more free time than them has volunteered to take GTK+ 2.x off life-support and the direction GTK+ 3.x is going is anything but logical.
Here’s a recent quote from the PCManFM mailing list:
The other reason is that, if they move to Qt rather than something else, they might be able to merge LXDE with Razor-Qt and spend less time duplicating effort.
Someone must make all those mish-mash qt apps in a proper desktop. Is openbox being ported to wayland?
Yes. They talked about those points on the mailing list too.
The reason they’re considering Qt is because it’s starting to look like doing all the work necessary to move to Qt would be easier in the long-term than maintaining GTK+ 2.x or dancing to GTK+ 3.x’s puppet-strings.
Thanks for the info. My logic is looking something like this: I don’t see a good enough reason to change to qt, so I’m inclined to stay with GTK and avoid the moving expenses until I’m more excited about and confident in a new destination.
Both GTK and qt have significant issues and uncertainty at this point, so it’s hard to choose a ‘winner’ – it’s a gamble. Many of the plusses for qt don’t effect me, and many of the minuses of GTK are still merely omens of things likely to come – for now it still works. Were I starting everything from scratch at this point, I might be more inclined to pick qt. But I am very familiar with the G universe and C at this point, not just GTK, but glib, etc. I know the tools and can use them to do what I want. Plus I have an app that is heavily G invested throughout.
If I move to qt/C++, I’ll be spending quite a bit of resources just coming up to speed and getting to know the tools. That’s a lot of time. Plus I won’t be able to easily combine the two, so it basically involves a deep rewrite of a large and complex app just to get started anew.
I have some ideas I would like to play with in UI design, and the particular widget varieties aren’t critical – a button is a button. I would much rather spend my time exploring my ideas, using the tools, than learning and replacing the tools.
Down the road, it should be more clear if qt or GTK become more or less friendly to my purposes, or if something else shows up to replace them both – then I can consider investing in a move. Toward that, any newly designed modules will leave the GUI stuff well encapsulated so I can later change the ‘skin’, maybe add a qt build. Basically I’ll use my own internal bindings to make any later transition to qt or other less messy.
While GTK’s directions lately do make me uncomfortable, I still find GTK, even 3, usable. I don’t find it particularly buggy – it runs well. Most bugs are caused by their 3rd party theme breakage. There has been a lot of wanton API breakage lately, and I think this is malicious to some extent – Red Hat trying to make it unfeasible for others to use their work. But (with BwackNinja’s help) I have been able to make SpaceFM GTK2/GTK3 and maintain it as dual-build, and it’s not that difficult. Even most of their API breakage amounts to trivial function and type redefinitions, so SpaceFM can currently be built all the way back to GTK 2.18. Overall keeping up with their API changes does incur a little overhead, but it’s manageable and doesn’t compare to the investment a switch to qt would involve.
As long as I maintain GTK2 compatibility in my work, if GTK3 gets too out of hand, I can simply drop it and stick with GTK2. It seems the GNOME2/GTK2 universe will be around for awhile, even if not actively developed, and the differences from the user’s perspective are not huge. And GTK2 might fork into something truly interesting.
So I’d rather use up my GTK tokens – get some use out of my knowledge and experience exploring my own ideas – before buying all new tokens. Plus this can make any transformation of SpaceFM gradual and modular, rather than restarting from the ground up, which is important for a small dev team. But I will definitely be anticipating a later change of toolkit in any new code, making that job easier for when/if it comes.
I’m somewhat surprised by PCMan’s choice, as he has invested a lot in the G universe too. But I don’t always like his choices – for example I never liked his idea of moving PCManFM to gvfs, and he later regretted it. He’s quicker to move into new investments than I, and thus spends a lot of his time accomodating those moves.
For the needs of LXDE, qt may indeed be a wise investment at this point, but they have much more to maintain than I, and a different purpose. My app is more experimental and is a single app, and I don’t mix much with the DE, etc. So it’s more self-contained.
Makes perfect sense. Even if nothing else, GObject and Qt both have their own approaches to reference counting and signals which would mean a lot of annoying drudge-work to translate.
In case you decide to poke around in Qt at some point in the future, here’s a guide that PCMan has started based on his experience porting PCManFM:
Migrate from GTK+ to Qt – LXDE.org
Thanks – it looks like PCMan has invested quite a bit in this direction. I see there he is combining use of glib and qt – didn’t know that was possible. That’s reassuring, as giving up glib would be tough, both in terms of what I know and in terms of so much code that uses glib functions.
It looks like his app now spans both universes, using glib and gio along with qt. This is certainly a boon in terms of changing – allows for a degree of gradual change. Yet mixing C and C++ gets messy. And by spanning both, you end up dealing with a large set of dependencies, and all the issues both sides incur, plus any issues involving their combination. I wonder how comfortable he will find that as time goes on. But he seems very motivated to dump GTK.
He may just move increasingly into C++ and non-glib, but he’s heavily invested there. I haven’t looked at the newer pcmanfm code since he moved to gvfs, but removing all the glib functions sure doesn’t look easy. I suspect he will be tied to glib and perhaps gvfs for some time.
What a load of bull. There is no uncertainty about Qt. The roadmap is clear, the development healthy. The fact that you didn’t even know that using glib in Qt applications is possible since ages shows clearly how less clue you’ve got.
By “uncertainty”, I think he was referring to how the major thrust of Qt development seems to be Qt Quick these days but the bindings for using native widgets from QML (rather than making your own or using the QML library provided by a smartphone OS) are still in development and may be ready in time for Qt 5.1.
There’s nothing uncertain. QML/QtQuick has the development focus and traditional widgets are in maintenance mode for Qt 5.x.
What will be part of Qt 5.1 can be seen in the current alpha release.
You once complained of theme API breakage and their lack if interest for themers and that let to a considerable discussions and some promises were made on increasing communication btw GTK maintainers and theme developers.Do you have any update on this front?Are things better,worse or just about the same?
I haven’t followed whatever transpired – I don’t consider it worth my time because I expect so little from them. This is the latest comment I’ve seen on it from a week ago, which indicates nothing has changed.
How about Elementary (EFL), FLTK toolkits to replace GTK 2?
Thank you for your answer! :)
FLTK has three problems I can think of:
It’s explicitly only a GUI toolkit, which means the developer is forced to track down their own lightweight libraries for everything else. (And there’s always the possibility that a library will expect a mainloop FLTK doesn’t support.)
UTF-8 support is listed as one of the enhancements in 1.3.x, which is still the development branch. (Which makes it closer to GTK 1.2.x than GTK 2.x)
As far as I know, it has no theming support whatsoever, making it no better than Motif for attracting and keeping today’s users.
As for EFL, I’ve been meaning to try out E17 for a while but I haven’t gotten around to it. It definitely looks impressive but I couldn’t find any evidence that Edje (the theming system) has a proxy for delegating theming to a Qt or GTK+ theme. I also couldn’t find a single EFL/E17/Edje theme using a few simple queries intermediate users are likely to make.
…so it’d be a viable option for 2003, assuming that you can find a GTK+ or Qt theme that resembles one of the available EFL themes, but it’s not going to impress users in 2013 unless you can either write such a proxy theme (difficult to do without bugs, if gtk-engines-qt is any indication) or do as KDE used to do (with only partial success) and write a viable EFL-based replacement for every GTK+ and Qt app people are likely to want.
…and now I know that WordPress.com doesn’t support UL/LI in comments the default comment system in standalone WordPress installations does.
the way the default comment system does.
You’d think that, if they’re using an AJAXy comment system, they’d at least give you a minute or two to make corrections. *sigh*
For FLTK themes (schemes):
– http://ergoeclectic.com/projects/fltk-gleam.html
– http://forum.tinycorelinux.net/index.php/topic,7853.msg42034.html#msg42034
For the rest, I understand you point of view.
I stand corrected and I’ve bookmarked those links.
Still, not exactly ideal to have a GUI toolkit where, to install a new theme, you have to patch and recompile the library and, given how it’s designed to be statically linked, probably your applications too.
Is that “GTK+” theme actually a “let GTK+ 2.x theme it” option or just something which tries to fit in with typical GTK+ themes of the period in which it was written, similar to the Clearlooks themes for Qt and Tk?
If I understand well your ask, GTK+ scheme is the original GTK 1 appearance.
In the name of keeping everyone informed, here’s PCMan’s answer regarding other toolkits, which answers your question:
http://article.gmane.org/gmane.linux.ubuntu.lubuntu.user/3776
Also, here’s the Wiki page he made with a comparison table:
http://wiki.lxde.org/en/GUI_Toolkit_Comparison
I read it in the https://groups.google.com/forum/?fromgroups=#!topic/razor-qt/aRfqM_W_ODQ discussion. :)
Is LibreOffice’s toolkit (vcl) and method (hooking up into GTK or QT) unpractical?
Sorry, a silly question! Why hook up into GTK if it’s going to die with GTK3 eventually?
Must say I’m deeply disturbed by this blog post. Half the reason we use SpaceFM is GTK.
Our rigs are Openbox/GTK as far as possible. (Every distro drags in a few GNOME and fewer KDE/Qt things, but we try.) Openbox/GTK is a huge win in our book. The performance and stability beat anything big boys offer.
Next, I have personally studied GUI kits for ages. Too bad nobody can afford QNX. Must say I could never stand how KDE/Qt stuff always crashed. And Qt is not vanilla C++ but C++ with “special sauce” preprocessing. To me it is brittle like cold glass. I always got better stability with plain GTK. And I really dislike how KDE/Qt folks try to treat GTK and GNOME as contagions. Chakra even has some weird bundling isolation trick.
If you are really truly serious about the latest hotness, go web young man. It has full-feature i18n, CSS theming galore, and jQuery (among many others) gives widgets in profusion. It is clearly THE main event these days.
HTML5 is displacing even Adobe Flash (YouTube has a beta). Some demo sites offer first-person shooter games in HTML5. Essentially a web page is a scriptable GUI interface with styling and layout. The gigantic Mathematica is built on Qt but is going web. They call the web interface “computable documents” or some marketing claptrap. You may want to see about Mozilla’s XUL toolkit, though I’m not clear what it is, exactly. The Thunderbird mail client is written in XUL. Yet I imagine you could pick any web-rendering library you please, just wrap some app loop around it, and call it a file manager. At that point you are basically doing web design within a custom web browser.
To me however the whole SpaceFM GUI discussion here is ridiculous. SpaceFM is a fantastic, lightweight, GTK file manager. I see no reason to change it. What it needs is more TLC and basic features. I really like your overall philosophy and design choices. I view this blog post as an aberration! Stop daydreaming and get back to work!
Best
Comparing this discussion to HTML5 apps is kind of insulting.
(To me, if you’re using in-browser apps and the alternative didn”t involve reinventing the browser’s network stack or HTML renderer, you’re doing something tantamount to buying a big, heavy scrap Pentium 4 for $100 at the refurbisher just to bit-bang the parallel port because you don’t feel like learning to use an Arduino.
Web apps that implement frontends for IRC/IMAP/NNTP/etc., LaTeX/LyX replacements, eBook readers, etc. in the browser? Good. Anything else? It’s like those pictures we laugh at where you see someone using their SUV to walk the dog.)
The problem is as follows:
The GTK+3 developers are behaving in a manner hostile to users who don’t want “the full GNOME stack” and, as far as API stability goes, treating it more like an internal GNOME component than a shared library.
Nobody has stepped up and announced they’re going to do more for GTK+ 2.x than just “life-support” patching.
This post is talking about what PCMan did. PCMan is Taiwanese, which means he cares highly about proper support for internationalization and Unicode. That rules out toolkits like FLTK where the i18n support is at a level akin to writing your GUI in raw X11 calls.
Most of today’s users want a consistent theming experience (myself included) and aren’t willing to set all their Qt and GTK+ apps to mimic one ornery application, which basically means that GTK+ 2.x, GTK+ 3.x, and Qt are the only choices. (Unless someone steps up and writes a proxy theme akin to QGtkStyle or gtk-engines-qt so that EFL can share a look with the existing big toolkits.)
IgnorantGuru is saying that he’d prefer to just stay on GTK+ 2.x and he’s hoping someone will take up maintainership of it but he’s keeping an eye on the situation so SpaceFM doesn’t get stuck in a dead end.
> SpaceFM is a fantastic, lightweight, GTK file manager. I see no reason to change it.
SpaceFM is always changing. Part of managing a project like this effectively involves keeping an eye on what’s going to be happening down the road, especially in terms of dependencies. eg What directions are the dependencies going in? Where will they drag SpaceFM in terms of usability, breakage, stability, compatibility, features, etc?
For example, I dumped udisks and the whole policykit/consolekit connections (another Red Hat creation), creating udevil to replace it in SpaceFM (and also allowing simple pmount to replace it), and the results have been great – problem reports related to devices and mounting have virtually disappeared, whereas they used to be a continous energy sink. Likewise, I never took SpaceFM in the gvfs direction that PCManFM took, developing it’s own VFS instead and thereby keeping GNOME dependencies to a minimum. gvfs is the source of crashes and problems in many file managers, including PCManFM (PCMan has often spoken of how much trouble gvfs has caused since he moved to it). Being free of gvfs means they can’t break SpaceFM with every bug they introduce to that dependency of other file managers. Same for udisks. Simply put, it’s great to be rid of Red Hat’s erractic support.
Developing for GTK+ in C is a time-consuming process – it represents large investments. If I am to continue developing for GTK+, I want to feel reasonably sure that my newer work has a future. As Stephan Sokolow related, there have been large changes happening in the GTK dev scene. You seem to be lacking some of the back story on this, so you might want to review this post and its comments, and other recent ones on this blog. Namely Red Hat devs have taken GNOME3 (and other Linux components they maintain) in radically new directions, are poorly maintaining and documenting their changes, are breaking the APIs in ways that cause developers many wasted hours changing code and rewriting themes, etc. This behavior is obnoxious, and more than one kernel developer has stated that they feel Red Hat is actually sabotaging some of these projects. At the very least, they are changing GTK in ways that serve and give attention to only their work in GNOME and their corporate customers, ignoring input from other projects that use GTK. GNOME and GTK are no longer the community-developed projects they once were – they are controlled by a billion dollar corporation with apparent ties to Google. As such, Red Hat’s maintenance and control of GTK development has become a liability and risk to developers using it. Many are refusing to support GTK3 at all as a result, and are sticking to GTK2 for now. Only a fool would ignore all this when planning work in GTK, and I’m no fool.
SpaceFM underwent a GTK3 port recently, which also made it dual-build – it’s one of the few programs that has opted to support both GTK2 and GTK3 for now. This was a bit of work to accomplish, and adds continuous light work to maintain it this way. But I feel it gives users the best options, and avoids the version breakage that GTK created.
Thus far, GTK3 runs well (which speaks highly of the devs), except that they are breaking 3rd party themes with each release, which is disasterous for theme developers (has them spitting mad at GTK devs), and causes serious bugs for users whose themes are out of date – memory leaks, etc. Hopefully GTK development will settle down once GTK3 matures, but rapid, poorly supported and documented changes is the Red Hat way. I expect little else.
Yet as you pointed out, qt also has its share of problems, and it too undergoes rapid changes which is likely overhead for those using it. As I stated above, in my latest review of the situation and options, I’ve decided it’s most reasonable to keep using GTK for now (in SpaceFM’s case), and simply deal with what Red Hat/GNOME throws at us. As a failsafe, since GTK2 support is intact in SpaceFM, if GTK3 becomes unreasonable to support, it could be dropped, reverting to GTK2.
So mostly these are discussions of long term changes and long term planning, which is vital if you want to see SpaceFM maintain quality, and NOT undergo wild changes. I have no plans to suddenly change SpaceFM into something radically different, and backwards compatibility for existing plugins and configurations is always a very high priority – SpaceFM aims to give the user a consistent experience across updates (unlike eg GNOME, which removes features at will, etc). Yet I’m always thinking very far ahead when it comes to SpaceFM development, so new work is efficient and fits into upcoming work.
At any rate, you can rest assured, because it looks like for now SpaceFM will be using GTK into the longer term, with an eye toward possible changes later if they become necessary. I am not eager to drop GTK as I have a lot invested in it, but I’m also not going to follow GNOME over a cliff. So I’ll be watching, and seeing how GTK3 performs for SpaceFM users.
Trends should be observed here. When KDE went to version 4, a great emphasis was placed on making it (and qt) work well in Windows – cross-platform. Likewise, GNOME3’s release has also been very cross-platform heavy, and the only theme developers they work with at all are their corporate customers (Windows and Apple).
While all of this cross-platform development in Linux toolkits may sound great, it has high costs. For one, Windows and Apple have much more gravity – they suck attention from projects, and the projects tend to start changing in ways that cater to their needs (an example being DRM support and other anti-user tech) (another example being dumbed-down interfaces). This in turn drags large corporations into the development process of these projects, with all their big money, guns for hire (paid development teams), and hostile corporate practices (driving competing projects into the ground, sabotaging their work, making it impossible to keep up with continuous changes (remember Internet Explorer vs Netscape)).
So I see GTK and qt in much the same way – they are both corporate sell-outs at this point – assimilated Borg – and I suspect their use in free, capable, pro-user projects will become increasingly difficult. One reason is their rapid, low quality changes which cause anyone using the projects to continuously update and revise existing code, themes, etc. This is very expensive for small dev teams, or teams of unpaid developers.
This means devs spend most of their time writing and rewriting basic GUI functionality, instead of incrementally evolving their software into high-quality, capable programs. Look how PCMan was recently sidetracked converting to qt – many hours wasted, aimed at basically just maintaining a maintainable status-quo, which could have been spent on much more interesting evolution of the actual functionality. Instead, it was all wasted replacing GTK buttons with qt buttons. It’s hard for any software to evolve in such a hostile environment.
What about tk? I really like the concept of Unixy DSL with graphical shell for GUI.
The GTK+ and Qt proxy themes for Ttk are basically unmaintained, I never figured out how to get them to compile against modern toolkits, and I think I remember hearing that they’ve got bugs, but they do exist so it is a possibility, I suppose.
However, I have no idea how they compare for things like internationalization since, when I first started learning GUI programming, un-themed Tk was the only option and I steered clear of it. They could be in the same “similar to using raw X11 for graphics” situation as toolkits like FLTK.
OpenShot switches from GTK+ to Qt