Bug 244879 - qt4: Configuration panel is in desktop preferences menu
qt4: Configuration panel is in desktop preferences menu
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: FutureFeature, Reopened
: 533139 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-06-19 13:10 EDT by Jonathan Blandford
Modified: 2013-04-02 00:21 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-04-27 03:37:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Havoc Pennington 2007-06-19 13:10:50 EDT
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

In any case, deleting this .desktop entirely is better than the status quo, if
no ideal fixes are forthcoming.
Comment 1 Rex Dieter 2007-06-19 14:00:43 EDT
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?
Comment 2 Havoc Pennington 2007-06-19 14:37:20 EDT
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.
Comment 3 Rex Dieter 2007-08-10 08:31:35 EDT
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)?
Comment 5 Ngo Than 2008-01-31 08:47:06 EST
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.
Comment 6 Rex Dieter 2008-01-31 09:01:35 EST
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
solution, while still not ideal, sucks less than any other option I can think of.
Comment 7 Rex Dieter 2008-01-31 10:54:18 EST
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.
Comment 8 Kevin Kofler 2008-05-02 12:32:33 EDT
I don't think we should hide qtconfig, it contains useful settings.
Comment 9 Rex Dieter 2008-05-07 13:10:33 EDT
fixed in qt-4.4.0 in rawhide (F10).
Comment 10 Michel Alexandre Salim 2008-08-21 16:03:01 EDT
For consistency, should not this be applied to qt3 (the qt3-config subpackage) as well?
Comment 11 Kevin Kofler 2008-08-21 17:36:04 EDT
I still don't think hiding qtconfig was a good idea in the first place.
Comment 12 Michel Alexandre Salim 2008-08-23 03:10:20 EDT
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.
Comment 13 Michel Alexandre Salim 2008-09-25 20:29:01 EDT
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.
Comment 14 Bug Zapper 2008-11-25 20:55:27 EST
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:
Comment 15 Rex Dieter 2009-11-05 08:48:31 EST
*** Bug 533139 has been marked as a duplicate of this bug. ***
Comment 16 Bug Zapper 2009-11-18 07:19:40 EST
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: 
Comment 17 Rex Dieter 2009-11-18 08:41:55 EST
Rebasing to rawhide

Note You need to log in before you can comment on or make changes to this bug.