Description of problem: On fedora 16 x86_64, installed from the TC2 Beta DVD and updated to install lots of devel packages and wot-not. I am running a gnome 3 session, never having logged in to a KDE session since the install. I build my "kewpie" program, which is written in the Qt toolkit and available here: http://home.comcast.net/~tomhorsley/software/kewpie/kewpie.html I try to run it, and the "config printer" dialog is totally non responsive. Even the "Cancel" button won't work. I try logging out and back into a KDE session, and run the same executable, and the config printer dialog works fine. I run "save config", and I get the annoying KDE file dialog I always incorrectly double click in. Something seems to have tied the Qt developement libs to KDE. This is totally broken, especially the part about them not working unless you are logged into a KDE session. I develop software in Qt for a lot of reasons, but none of those reasons include making it impossible to use my software without also using the rest of KDE. Make it stop! Version-Release number of selected component (if applicable): qt-devel-4.8.0-0.9.beta1.fc16.x86_64 How reproducible: every time Steps to Reproduce: 1.see above 2. 3. Actual results: impossible to run Qt program outside of KDE Expected results: able to run my program Additional info:
The qt4 package has been obsolete for years (ever since Qt 4 has become the default version of Qt), bugs must be filed against qt instead. Reassigning.
So to address your actual issue: First of all, nobody is "tying Qt to KDE". (In fact, even kdelibs apps are supposed to work just fine outside of the KDE Plasma workspaces. But Qt also doesn't require kdelibs.) Your concrete issue appears to be with the "config printer" dialog hanging up. So please report that as the bug it is. Vague complaints like "Qt has become impossible to use outside of KDE" are NOT helpful. (And FYI, the workspace is not called just "KDE" anymore, but "KDE Plasma workspaces" or specifically the "KDE Plasma Desktop workspace".)
Actually, they are tying Qt to KDE. I also get the KDE file browser when I try to load or save, and it is also non-functional unless I'm in a KDE Plasma Desktop workspace session :-). If I just got the native Qt file browser (which I always have had in fedora releases through f15), then the file browser would work fine. I have no idea how many other standard dialogs also don't work in a gnome session.
> I also get the KDE file browser when I try to load or save, That's another bug. > and it is also non-functional unless I'm in a KDE Plasma Desktop workspace > session :-). And that's yet another bug, unless what you're seeing is a general bug affecting ALL Qt dialogs. (The KDE libraries don't provide their own print dialog, so the print dialog is part of Qt, which means the only thing it has in common with the KDE file dialog in kdelibs is pretty much that it is a QDialog. And FWIW, the KDE file dialog is actually a KDialog, which is a subclass of QDialog.)
Looks like this is just a special case of bug #742658. *** This bug has been marked as a duplicate of bug 742658 ***