Bug 309452

Summary: YaST control center shows empty section
Product: [openSUSE] openSUSE 10.3 Reporter: Jiri Srain <jsrain>
Component: YaST2Assignee: Thomas Göttlicher <tgoettlicher>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None CC: lslezak
Version: Beta 3   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Screenshot of Qt control center
patch

Description Jiri Srain 2007-09-11 10:44:31 UTC
The YaST control center shows the virtualization section even if I do not have any virtualization module installed, so it is empty. IMO such section should be hidden.

The behavior is the same in Qt and NCurses.
Comment 1 Stefan Hundhammer 2007-09-11 11:53:24 UTC
A new group gets opened if and only if there is a module with that group. I can't quite understand how there can be a new group if there is no modules that wants to be in it.
Comment 2 Jiri Srain 2007-09-11 13:23:44 UTC
Created attachment 163212 [details]
Screenshot of Qt control center

You can see, it's truth :-(

I have selected the Virtualization group.
Comment 3 Stefan Hundhammer 2007-09-11 13:43:11 UTC
Could you try to grep the .desktop files for "Virtualization" and paste one or some of those .desktop files here?

Can you try to click on the right panel?
It's just a very remote chance, but maybe there are items that have neither icons nor texts.
Comment 4 Jiri Srain 2007-09-11 14:15:02 UTC
There is not any in /usr/share/applications/YaST2

The only one is the one which defines the group: /usr/share/applications/YaST2/groups/virtualization.desktop
Comment 5 Stefan Hundhammer 2007-09-11 14:51:56 UTC
I was wrong.

Groups are created first according to the group .desktop files in /usr/share/applications/groups . Later, when .desktop files for modules are read, a new additional group is created if a module .desktop file refers to a nonexistent group.

So IMHO the control center(s) behave according to spec, and that virtualization.desktop file is out of place if there are no modules that belong to that group.

The question is: Is that spec still valid and useful, or should we change it? Was there a good reason to always create those groups first? (Maybe to show at least some groups if called as non-root so the window is not completely empty?)

A (clumsy) solution might be to go through all groups after reading all module .desktop files and delete those groups that don't have any module.
Comment 6 Stefan Hundhammer 2007-09-11 14:54:01 UTC
virtualization.desktop belongs to yast2-vm. CC'ing maintainer.
Comment 7 Jiri Srain 2007-09-11 15:14:03 UTC
In this particular case, it may be result of my system upgraded from bet to beta. However, user may uninstall eg. all hardware configuration module and you are in the very same situation without breaking packages.

IMO your suggested clumsy solution is the way we should go. How are the GNOME/KDE desktops dealing with this problem? According to the XDG spec, the base of the menu structure is defined as a standalone file (with extensions possible) and I doubt that no group is a leaf in the tree...
Comment 8 Thomas Göttlicher 2007-09-19 12:46:23 UTC
Created attachment 173325 [details]
patch
Comment 9 Thomas Göttlicher 2007-09-19 12:48:29 UTC
I will commit this patch to svn after 10.3.
Comment 10 Katarina Machalkova 2007-09-26 16:24:48 UTC
Fixed in ncurses CC (yast2-2.16.0)
Comment 11 Katarina Machalkova 2007-09-26 16:30:34 UTC
Btw, Thomas, your patch (comment #8) is not 100% correct

1) Please enclose 'printf' function into some #if DEBUG_MODE #endif, so that it normally prints nothing to stdout/stderr
2) removeEmptyGroups function does not filter out all groups with empty module set. See it for yourself, if you run CC as non-root user, some groups (e.g. Hardware, Security) are filtered out, while others (System, AppArmor) are not, although they contain no modules. 
Comment 12 Thomas Göttlicher 2007-10-24 12:22:48 UTC
Katarina, thanks for that hint.
I fixed that in svn r41539 and package submitted to STABLE.