Including the name of a non-user-visible programming tool (like "Qt4") in a menu item name is always a very bad sign, unless it's in the Programming menu. I don't think there's a way to just rename this - "control panel with a variety of settings duplicating other settings you already set, but which may not have applied to certain apps" is not a good name either. I would either delete this .desktop file or move it to Applications->Programming if it is useful for developers. The real fix of course (which I would have thought we already had!) is to make the theme control panel also control the Qt4 theme, the font control panel also control the Qt4 font, and so forth. Surely under KDE this is already the case at least. In any case, deleting this .desktop entirely is better than the status quo, if no ideal fixes are forthcoming.
I assume you're talking about "Qt4 Config" here? Included "Qt4" only to differentiate it from the qt3 equivalent (both qt3 and qt4 include a qtconfig tool to set prefs, look-n-feel, etc...). If qtconfig is packaged, I'm uncomfortable not installing a .desktop file for it (maybe NoDisplay=True, but I'm not too keen on that either). A better name for it is certainly warranted, regardless. The window Title for this app is "Qt Configuration", would that be more acceptable?
IMO unless it's a developers-only thing in Programming, the visibility of this program is just a bug; there is no way it makes sense for users to configure Qt4 fonts, themes, etc. somewhere other than in the control panels labeled "Font" and "Theme" (or KDE equivalents, under KDE). Even if (and this is a huge "if") Qt4 needed separate config from the global settings, said separate config should be somewhere in the Font and Theme and so on control panels, not in a Qt4 control panel. Renaming "Qt Configuration" doesn't help - the point is that "uses Qt/Qt3/Qt4" is a developers-only categorization of apps, with no meaning to someone just trying to use the desktop. "Qt" is technical jargon, as is "GTK" or "Tk" or whatever else. We banned toolkit names from the menus (other than Programming submenu) many years ago. I think a fine fix would be to just drop the .desktop file, second choice would be to relocate it to Programming. Maybe others have better ideas. Of course, if Qt4 really does not honor the global settings in the normal control panels, that is a larger problem that will need fixing as well.
Than, do you have an opinion on how best to treat qt-config's .desktop file and appearance/placement in the menus (the same can be asked of qt v3)?
IMO moving qt-config into Programming catagorie isn't correct, becuase it's a setting tool. We should add OnlyShowIn=KDE in qt-config.desktop file. So it only appears in kde desktop. I think it's the best option.
I really really dislike OnlyShowIn. Why? imo, it's not a solution, but a band-aid, either all users (in all desktops) should be able to see/use this config tool, or they shouldn't. Havoc's right, of cousre, qt uses (should!) global/desktop settings, and use of this tool is pretty much useful only for power users or developers (at best). With that in mind, the more I think about it, the more I tend to think a NoDisplay=True solution, while still not ideal, sucks less than any other option I can think of.
Than and I discussed it, and we agreed to remove qtconfig from the menus (via NoDisplay=true), but to wait to implement it until qt-4.4 lands.
I don't think we should hide qtconfig, it contains useful settings.
fixed in qt-4.4.0 in rawhide (F10).
For consistency, should not this be applied to qt3 (the qt3-config subpackage) as well?
I still don't think hiding qtconfig was a good idea in the first place.
FWIW, I don't think it should be hidden either. How about making qt{3,4}-config desktop entries be under "Settings;DesktopSettings;" categories? That will make them appear under System->Preferences->Look and Feel, together with Appearance and Desktop Effects.
Reopening -- Rex, per comment #12, could qt4-config be made to appear in Settings;DesktopSettings? We can then ask Than to do the same for qt3.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 533139 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Rebasing to rawhide