[yast-devel] shell menu generation
GNOME uses the freedesktop menu and .desktop spec standards to generate all it's menus - the traditional menu, the application browser and the control center. This method uses a .menu file and the Category= line from .desktop files to determine which menu entry a .desktop file falls into. AFAIK KDE also uses this for it's main top level menu. As of sp1 we added the yast2 control center which also uses this method. I was not involved in the very start of this so I don't want to speak incorrectly but I think a .menu file was generated that simply contained all the menu categories that currently showed in the qt shell. Then it used the already existing Categories= lines in .desktop files like /usr/share/applications/YaST2/users.desktop Unfortunately, that means there is currently two ways to generate the yast2 menus - the yast2 specific way using the X-SuSE-YaST-Group key and the Category= way. Towards the end of SP1 we ran into some issues with this. Using the .menu/.desktop specs to generate the menus means we get common code shared between all the menus and we can use the standard gmenu library to parse all the relevant information from the .desktop files including supporting all the other tags such as OnlyShowIn, Hidden, ... Could we move to supporting the .menu/.desktop spec way of generating menus for the yast shells – given that almost all of the existing .desktop files contain some sort of “Categories=X-SuSE-YaST-*” line it appears something along that lines is already under way. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi Scott, code sharing is good. On Fri, Jun 15, 2007 at 03:33:00PM -0600, Scott Reeves wrote:
GNOME uses the freedesktop menu and .desktop spec standards to generate all it's menus - the traditional menu, the application browser and the control center. This method uses a .menu file and the Category= line from .desktop files to determine which menu entry a .desktop file falls into. AFAIK KDE also uses this for it's main top level menu.
These ones, right? http://www.freedesktop.org/wiki/Specifications/menu-spec http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
As of sp1 we added the yast2 control center which also uses this method. I was not involved in the very start of this so I don't want to speak incorrectly but I think a .menu file was generated that simply contained all the menu categories that currently showed in the qt shell. Then it used the already existing Categories= lines in .desktop files like /usr/share/applications/YaST2/users.desktop
This file? http://svn.opensuse.org/svn/yast/branches/SuSE-SLE-10-SP1-Branch/control-cen...
Unfortunately, that means there is currently two ways to generate the yast2 menus - the yast2 specific way using the X-SuSE-YaST-Group key and the Category= way. Towards the end of SP1 we ran into some issues with this.
Using the .menu/.desktop specs to generate the menus means we get common code shared between all the menus and we can use the standard gmenu library to parse all the relevant information from the .desktop files including supporting all the other tags such as OnlyShowIn, Hidden, ...
Could we move to supporting the .menu/.desktop spec way of generating menus for the yast shells – given that almost all of the existing .desktop files contain some sort of “Categories=X-SuSE-YaST-*” line it appears something along that lines is already under way.
I don't understand yet. For example this file http://svn.opensuse.org/svn/yast/branches/SuSE-SLE-10-SP1-Branch/nfs-client/... already has the appropriate Categories. Can you be more specific please? -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Dne pondělí 18 červen 2007 11:32 Martin Vidner napsal(a):
Hi Scott,
code sharing is good.
On Fri, Jun 15, 2007 at 03:33:00PM -0600, Scott Reeves wrote:
GNOME uses the freedesktop menu and .desktop spec standards to generate all it's menus - the traditional menu, the application browser and the control center. This method uses a .menu file and the Category= line from .desktop files to determine which menu entry a .desktop file falls into. AFAIK KDE also uses this for it's main top level menu.
These ones, right? http://www.freedesktop.org/wiki/Specifications/menu-spec http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
As of sp1 we added the yast2 control center which also uses this method. I was not involved in the very start of this so I don't want to speak incorrectly but I think a .menu file was generated that simply contained all the menu categories that currently showed in the qt shell. Then it used the already existing Categories= lines in .desktop files like /usr/share/applications/YaST2/users.desktop
This file? http://svn.opensuse.org/svn/yast/branches/SuSE-SLE-10-SP1-Branch/control-ce nter-gnome/etc/YaST-gnome.menu
Unfortunately, that means there is currently two ways to generate the yast2 menus - the yast2 specific way using the X-SuSE-YaST-Group key and the Category= way. Towards the end of SP1 we ran into some issues with this.
Using the .menu/.desktop specs to generate the menus means we get common code shared between all the menus and we can use the standard gmenu library to parse all the relevant information from the .desktop files including supporting all the other tags such as OnlyShowIn, Hidden, ...
Could we move to supporting the .menu/.desktop spec way of generating menus for the yast shells – given that almost all of the existing .desktop files contain some sort of “Categories=X-SuSE-YaST-*” line it appears something along that lines is already under way.
I don't understand yet. For example this file http://svn.opensuse.org/svn/yast/branches/SuSE-SLE-10-SP1-Branch/nfs-client /src/nfs.desktop already has the appropriate Categories. Can you be more specific please?
To my understanding, the problem is not in the way .desktop files for individual YaST modules are written. IIRC the problems were like missing group icon or similar. YaST for QT and NCurses uses .desktop files for both group and individual module, however, GTK uses .desktop files only for individual modules and for groups it uses .menu files. I quickly checked the spec and must admit that I didn't find where we violate it by using .desktop files even for groups. We already have all the infrastructure (eg. for translations) in place and it is proven to work properly. -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz
Jiri Srain <jsrain@suse.cz> 06/18/07 6:38 AM >>> Dne pondělí 18 červen 2007 11:32 Martin Vidner napsal(a): These ones, right? http://www.freedesktop.org/wiki/Specifications/menu-spec http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
This file? http://svn.opensuse.org/svn/yast/branches/SuSE-SLE-10-SP1-Branch/control-ce nter-gnome/etc/YaST-gnome.menu
Yes.
I don't understand yet. For example this file http://svn.opensuse.org/svn/yast/branches/SuSE-SLE-10-SP1-Branch/nfs-client /src/nfs.desktop already has the appropriate Categories. Can you be more specific please?
Yes that file has appropriate Categories= entry and so it worked great with our .menu file. The problem arose from .desktop files like the virtualization ones that did not have that entry and relied solely on the yast specific X-SuSE-YaST-Group key for menu placement. See bug#258600
To my understanding, the problem is not in the way .desktop files for individual YaST modules are written. IIRC the problems were like missing group icon or similar. YaST for QT and NCurses uses .desktop files for both group and individual module, however, GTK uses .desktop files only for individual modules and for groups it uses .menu files. I quickly checked the spec and must admit that I didn't find where we violate it by using .desktop files even for groups. We already have all the infrastructure (eg. for translations) in place and it is proven to work properly.
The root problem is that yast2-control-center-gnome uses the .menu spec to generate it's menus while yast2-control-center uses the yast specific method. What I am hoping for is to have the .menu spec method be an officially supported way of generating the menus. I agree it's hard to argue against something that is currently working but all the other menus in gnome (traditional menu, application browser, control-center) and the top level menu in KDE use the .menu spec. This allows common shared code between all menus and as mentioned also gives the ability to take advantage of other entries supported by the .menu spec such as OnlyShowIn ... It seems like the vast majority of yast module .desktop files already have the "Categories=" entry in them already. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi! Dne čtvrtek 05 červenec 2007 18:36 Scott Reeves napsal(a):
Jiri Srain <jsrain@suse.cz> 06/18/07 6:38 AM >>>
Dne pondělí 18 červen 2007 11:32 Martin Vidner napsal(a):
These ones, right? http://www.freedesktop.org/wiki/Specifications/menu-spec http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
This file? http://svn.opensuse.org/svn/yast/branches/SuSE-SLE-10-SP1-Branch/control -ce nter-gnome/etc/YaST-gnome.menu
Yes.
I don't understand yet. For example this file http://svn.opensuse.org/svn/yast/branches/SuSE-SLE-10-SP1-Branch/nfs-cli ent /src/nfs.desktop already has the appropriate Categories. Can you be more specific please?
Yes that file has appropriate Categories= entry and so it worked great with our .menu file. The problem arose from .desktop files like the virtualization ones that did not have that entry and relied solely on the yast specific X-SuSE-YaST-Group key for menu placement. See bug#258600
Changing how the group is being read from the .desktop file of an individual module should be the simple part.
To my understanding, the problem is not in the way .desktop files for individual YaST modules are written. IIRC the problems were like missing group icon or similar. YaST for QT and NCurses uses .desktop files for both group and individual module, however, GTK uses .desktop files only for individual modules and for groups it uses .menu files. I quickly checked the spec and must admit that I didn't find where we violate it by using .desktop files even for groups. We already have all the infrastructure (eg. for translations) in place and it is proven to work properly.
The root problem is that yast2-control-center-gnome uses the .menu spec to generate it's menus while yast2-control-center uses the yast specific method.
To make it more difficult, there are two yast control centers - one for Qt and the other one written in YCP (and thus able to work via NCurses). The both use the same way.
What I am hoping for is to have the .menu spec method be an officially supported way of generating the menus. I agree it's hard to argue against something that is currently working but all the other menus in gnome (traditional menu, application browser, control-center) and the top level menu in KDE use the .menu spec. This allows common shared code between all menus and as mentioned also gives the ability to take advantage of other entries supported by the .menu spec such as OnlyShowIn ... It seems like the vast majority of yast module .desktop files already have the "Categories=" entry in them already.
What I do not like on the YaST-gnome.menu file as it is in SVN is that it contains all possible groups. This cannot work for 3rd party modules. I hope that there is a way to workaround this, but it is not obvious to me (without reading the standard properly). Another problem (apart already mentioned translations handling) is that for YCP we do not have a XML parser which would be able parse the .desktop files. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz
Jiri Srain <jsrain@suse.cz> 07/09/07 2:57 AM >>> What I do not like on the YaST-gnome.menu file as it is in SVN is that it contains all possible groups. This cannot work for 3rd party modules. I hope that there is a way to workaround this, but it is not obvious to me (without reading the standard properly).
Yes, customization by additional modules (3rd party or system) is built into the .menu spec. To add to or modify <name>.menu file, modules install their own additional .menu files into <name>-merged directory. These menu files are then automatically merged into the top level menu.
Another problem (apart already mentioned translations handling)
is that for YCP we do not have a XML parser which would be able parse the .desktop files.
The translation handling is also built in the .menu spec and is handled the exact same way that translations are handled in .desktop files. hrmm, the YCP module is already parsing .desktop files today correct? , do you mean .menu files. Sorry for my lack of knowledge about how KDE generates it's top level menu but as it uses the .menu spec would it be possible to tie into the library it uses. Thanks. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Dne úterý 10 červenec 2007 22:55 Scott Reeves napsal(a):
Jiri Srain <jsrain@suse.cz> 07/09/07 2:57 AM >>>
What I do not like on the YaST-gnome.menu file as it is in SVN is that it contains all possible groups. This cannot work for 3rd party modules. I hope that there is a way to workaround this, but it is not obvious to me (without reading the standard properly).
Yes, customization by additional modules (3rd party or system) is built into the .menu spec. To add to or modify <name>.menu file, modules install their own additional .menu files into <name>-merged directory. These menu files are then automatically merged into the top level menu.
Another problem (apart already mentioned translations handling)
The translation handling is also built in the .menu spec and is handled the exact same way that translations are handled in .desktop files.
is that for YCP we do not have a XML parser which would be able parse the .desktop files.
hrmm, the YCP module is already parsing .desktop files today correct? , do
Sorry, yes, I meant the .menu files (or general XML). YaST's XML parser can parse only limited XML.
you mean .menu files. Sorry for my lack of knowledge about how KDE generates it's top level menu but as it uses the .menu spec would it be possible to tie into the library it uses.
This is possible for the Qt menu where the dependency on additional libraries (which are typicalyl instaleld anyway) does not hurt that much. But it is probably not acceptable for the NCurses menu for minimal instalaltion. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz
participants (3)
-
Jiri Srain -
Martin Vidner -
Scott Reeves