Suggest A debian-style menu system for guix

Suggest A debian-style menu system for guix

[tumashu]

[-- Attachment #1: Type: text/plain, Size: 156 bytes --]

Debian menu system (https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html) is a very useful tool,
is it possible develop a similar tool for guix?

[-- Attachment #2: Type: text/html, Size: 407 bytes --]

Re: Suggest A debian-style menu system for guix

[ng0]

tumashu transcribed 1.0K bytes:
> Debian menu system (https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html) is a very useful tool,
> is it possible develop a similar tool for guix?

Could you explain what this exactly does?

The manual page only documents the insides, not the description.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Suggest A debian-style menu system for guix

[Feng Shu]

ng0 <ng0@pragmatique.xyz> writes:

> tumashu transcribed 1.0K bytes:
>> Debian menu system (https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html) is a very useful tool,
>> is it possible develop a similar tool for guix?
>
> Could you explain what this exactly does?
>
> The manual page only documents the insides, not the description.

The below comment is from debian menu introduction.  if a package have a
debian menu file,  all window-manager's menu in debian will show this
package menu.

#+BEGIN_COMMENT
 Before the advent of update-menus, when the sysadmin installed a package onto a Debian system, they would need to edit various window manager config files to make the new program show up on, for example, fvwm's menus. The menus could easily become out of sync with what programs were actually available, with some menu items that didn't work, and other programs that lacked a menu entry. update-menus and Debian's menu package aim to solve this problem.

update-menus automatically generates menus of installed programs for window managers and other menu programs. It should be run whenever a menu file or menu-method file is changed. update-menus will be ran automatically when Debian packages that contain menu files are installed or removed from the system. Users themselves can add/delete menu items, and should then run update-menus as that user, thus creating window-manager startup files that are used in preference to the systemwide files. 
#+END_COMMENT

-- 

Re: Suggest A debian-style menu system for guix

[William Seddon]

On 24 April 2017 at 11:28, Feng Shu <tumashu@163.com> wrote:
> #+BEGIN_COMMENT
>  Before the advent of update-menus, when the sysadmin installed a package onto a Debian system, they would need to edit various window manager config files to make the new program show up on, for example, fvwm's menus. The menus could easily become out of sync with what programs were actually available, with some menu items that didn't work, and other programs that lacked a menu entry. update-menus and Debian's menu package aim to solve this problem.
>
> update-menus automatically generates menus of installed programs for window managers and other menu programs. It should be run whenever a menu file or menu-method file is changed. update-menus will be ran automatically when Debian packages that contain menu files are installed or removed from the system. Users themselves can add/delete menu items, and should then run update-menus as that user, thus creating window-manager startup files that are used in preference to the systemwide files.
> #+END_COMMENT
>

Don't most/all WMs use .desktop files for this sort of thing?
The .desktop files are, if I recall correctly, also used to build menus.
If this is the case then I don't fully understand the point of
Debian's update-menu, shouldn't the XDG standard be used?

There is an extra spec used for extending .desktop files for menu use:
https://specifications.freedesktop.org/menu-spec/menu-spec-latest.html

Re: Suggest A debian-style menu system for guix

[ng0]

Feng Shu transcribed 1.5K bytes:
> ng0 <ng0@pragmatique.xyz> writes:
> 
> > tumashu transcribed 1.0K bytes:
> >> Debian menu system (https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html) is a very useful tool,
> >> is it possible develop a similar tool for guix?
> >
> > Could you explain what this exactly does?
> >
> > The manual page only documents the insides, not the description.
> 
> The below comment is from debian menu introduction.  if a package have a
> debian menu file,  all window-manager's menu in debian will show this
> package menu.
> 
> #+BEGIN_COMMENT
>  Before the advent of update-menus, when the sysadmin installed a package onto a Debian system, they would need to edit various window manager config files to make the new program show up on, for example, fvwm's menus. The menus could easily become out of sync with what programs were actually available, with some menu items that didn't work, and other programs that lacked a menu entry. update-menus and Debian's menu package aim to solve this problem.
> 
> update-menus automatically generates menus of installed programs for window managers and other menu programs. It should be run whenever a menu file or menu-method file is changed. update-menus will be ran automatically when Debian packages that contain menu files are installed or removed from the system. Users themselves can add/delete menu items, and should then run update-menus as that user, thus creating window-manager startup files that are used in preference to the systemwide files. 
> #+END_COMMENT
> 
> -- 
> 
> 
Thanks.

So what's the difference to existing menu-generators specific to many
or only a subset of window-managers, such as obconf?

Option 1: we could do this in scheme somehow, associated to Guix.
Option 2: we make this a choice (opt-in, run it on your own), not
an opt-out as coming up with a way where user menus are touched
is from my perspective a no-go.
I would not want some automatic generator to touch my menus which
are slightly different from just generated ones.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Suggest A debian-style menu system for guix

[Feng Shu]

ng0 <ng0@pragmatique.xyz> writes:

> Feng Shu transcribed 1.5K bytes:
>> ng0 <ng0@pragmatique.xyz> writes:
>> 
>> > tumashu transcribed 1.0K bytes:
>> >> Debian menu system (https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html) is a very useful tool,
>> >> is it possible develop a similar tool for guix?
>> >
>> > Could you explain what this exactly does?
>> >
>> > The manual page only documents the insides, not the description.
>> 
>> The below comment is from debian menu introduction.  if a package have a
>> debian menu file,  all window-manager's menu in debian will show this
>> package menu.
>> 
>> #+BEGIN_COMMENT
>>  Before the advent of update-menus, when the sysadmin installed a
>> package onto a Debian system, they would need to edit various window
>> manager config files to make the new program show up on, for
>> example, fvwm's menus. The menus could easily become out of sync
>> with what programs were actually available, with some menu items
>> that didn't work, and other programs that lacked a menu
>> entry. update-menus and Debian's menu package aim to solve this
>> problem.
>> 
>> update-menus automatically generates menus of installed programs for
>> window managers and other menu programs. It should be run whenever a
>> menu file or menu-method file is changed. update-menus will be ran
>> automatically when Debian packages that contain menu files are
>> installed or removed from the system. Users themselves can
>> add/delete menu items, and should then run update-menus as that
>> user, thus creating window-manager startup files that are used in
>> preference to the systemwide files.
>> #+END_COMMENT
>> 
>> -- 
>> 
>> 
> Thanks.
>
> So what's the difference to existing menu-generators specific to many
> or only a subset of window-managers, such as obconf?
>
> Option 1: we could do this in scheme somehow, associated to Guix.
> Option 2: we make this a choice (opt-in, run it on your own), not
> an opt-out as coming up with a way where user menus are touched
> is from my perspective a no-go.
> I would not want some automatic generator to touch my menus which
> are slightly different from just generated ones.

All I want to say is that:  we *must* add menu info in "package define"
if users of this package *real need* a menu instead of waiting upstream
to write a .desktop.


-- 

Re: Suggest A debian-style menu system for guix

[Hartmut Goebel]

Am 24.04.2017 um 14:48 schrieb Feng Shu:
> All I want to say is that:  we *must* add menu info in "package define"
> if users of this package *real need* a menu instead of waiting upstream
> to write a .desktop.

Well, if there is no desktop file, wouldn't it be sufficient to add one?

-- 
▶︎Digitalcourage e.V., Hartmut Goebel, Marktstr. 18, D-33602 Bielefeld
Tel: +49-521-1639 1639 | Fax: 0521-61172 | mail@digitalcourage.de
https://digitalcourage.de | http://bigbrotherawards.de |
------------------------------------------------------------------
Für Bürgerrechte, Datenschutz und eine lebenswerte digitale Welt
-----------------------------------------------------------------
        Online spenden: https://digitalcourage.de/spende/

Vorratsdatenspeicherung? Nicht schon wieder! Unterstützen Sie
unsere Verfassungsbeschwerde: https://digitalcourage.de/weg-mit-vds

Re: Suggest A debian-style menu system for guix

[Adonay Felipe Nogueira]

Personally, I find .desktop files better suited for this. Place each of
them in "$HOME/.local/share/applications" directory.

More information about the FreeDesktop .desktop standard can be found
at:
[[https://specifications.freedesktop.org/desktop-entry-spec/latest/]].

As it evidences, GNOME has adapted a similar format, which can be read
at
[[https://developer.gnome.org/integration-guide/stable/desktop-files.html]].

Re: Suggest A debian-style menu system for guix

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

Adonay Felipe Nogueira <adfeno@openmailbox.org> writes:

> Personally, I find .desktop files better suited for this. Place each of
> them in "$HOME/.local/share/applications" directory.
>
> More information about the FreeDesktop .desktop standard can be found
> at:
> [[https://specifications.freedesktop.org/desktop-entry-spec/latest/]].
>
> As it evidences, GNOME has adapted a similar format, which can be read
> at
> [[https://developer.gnome.org/integration-guide/stable/desktop-files.html]].

If a software component comes with desktop files, what's the right place
to put them relative to the component's output path?

I would imagine that a lot of desktop applications packaged with Guix
will probably come with desktop files.  Or, if they do not, I imagine
that we could add desktop files for them as we package them.  Instead of
requiring users to create their own desktop files individually (I can
never remember how to do it), it would be neat if desktop applications
installed via Guix came with desktop files installed in the "right
place" by default.  That way, any software which understands the
FreeDesktop standard would find the installed software and populate the
right menus automatically.

I think we're doing this already for some Guix packages, but since my
knowledge of the FreeDesktop standard is limited, I'm not sure if it's
by accident or if it's intentional.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

XDG standard desktop entries - desktop-file-utils and gtk, and KDE: mechanism of desktop database generation in profiles

[Danny Milosavljevic]

>If a software component comes with desktop files, what's the right place to put them relative to the component's output path?

share/applications

> I think we're doing this already for some Guix packages, but since my
> knowledge of the FreeDesktop standard is limited, I'm not sure if it's
> by accident or if it's intentional.

It's intentional.  I'm actively filing bugs and fixing them if GUI programs don't have a desktop file - because that's just silly, having a program you can't (easily) run.

See guix/profiles.scm xdg-desktop-database for the profile hook that merges all the share/applications directories of the packages in the profile.
For the hook to be run, desktop-file-utils (of freedesktop) has to be an input of the package or some of its dependencies (i.e. it has to be available on the build side in the environment).

I think we should just make desktop-file-utils a propagated-input of gtk.

(In fact, even gio (part of glib) already supports desktop files: https://developer.gnome.org/gio/stable/gio-Desktop-file-based-GAppInfo.html . However, there are lots of non-GUI programs using glib.  For example, desktop-file-utils uses glib)

Disclaimer: I have no idea how KDE works - but desktop-file-utils seems to be missing entirely there.  Qt doesn't require it either.  Weird.

Similar stuff is done if GLIB is a dependency of a package, for xdg-mime-database.

Re: Suggest A debian-style menu system for guix

[Adonay Felipe Nogueira]

As some have noted, there are hooks to make FreeDesktop standard
.desktop files.

However, there is an important note: While this works well with GuixSD
users, it might make Guix users' host desktop not start correctly if,
for clarification, Guix advises the user to add the XDG_DATA_DIRS
variable to his "~/.profile" file as suggested by Guix, and if the user
follows the suggestion "to the teeth", see:
[[http://lists.gnu.org/archive/html/bug-guix/2017-03/msg00200.html]]
(and replies).

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: XDG standard desktop entries - desktop-file-utils and gtk, and KDE: mechanism of desktop database generation in profiles

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2676 bytes --]

Danny Milosavljevic <dannym@scratchpost.org> writes:

>>If a software component comes with desktop files, what's the right place to put them relative to the component's output path?
>
> share/applications
>
>> I think we're doing this already for some Guix packages, but since my
>> knowledge of the FreeDesktop standard is limited, I'm not sure if it's
>> by accident or if it's intentional.
>
> It's intentional.  I'm actively filing bugs and fixing them if GUI
> programs don't have a desktop file - because that's just silly, having
> a program you can't (easily) run.
>
> See guix/profiles.scm xdg-desktop-database for the profile hook that merges all the share/applications directories of the packages in the profile.
> For the hook to be run, desktop-file-utils (of freedesktop) has to be
> an input of the package or some of its dependencies (i.e. it has to be
> available on the build side in the environment).
>
> I think we should just make desktop-file-utils a propagated-input of gtk.
>
> (In fact, even gio (part of glib) already supports desktop files:
> https://developer.gnome.org/gio/stable/gio-Desktop-file-based-GAppInfo.html
> . However, there are lots of non-GUI programs using glib.  For
> example, desktop-file-utils uses glib)
>
> Disclaimer: I have no idea how KDE works - but desktop-file-utils seems to be missing entirely there.  Qt doesn't require it either.  Weird.
>
> Similar stuff is done if GLIB is a dependency of a package, for xdg-mime-database.

Is this supposed to work "out of the box" on foreign distros?

I've noticed that when I install an application (e.g.,
"cool-retro-term"), the application shows up via the "Search" feature of
the "Application Overview" in GNOME3 on GuixSD [1], but not in Ubuntu
via the Dash's search results [2].  In Ubuntu, I tried adding
$HOME/.guix-profile/share to the XDG_DATA_DIRS, but even after
rebooting, the Dash search still failed to find the application.

In Ubuntu, the application only showed up in the Dash search results
after I manually copied the desktop entry for the application out of the
store and put it into a well-known location, such as
~/.local/share/applications.  I might have also had to set the
executable bit [3]; I can't remember exactly, and I've since deleted the
file because I wasn't satisfied with this work-around.

[1] https://wiki.gnome.org/Gnome3CheatSheet#Activities_Overview

[2] https://help.ubuntu.com/stable/ubuntu-help/unity-dash-intro.html

[3]
https://askubuntu.com/questions/419610/permission-of-a-desktop-file
https://wiki.ubuntu.com/SecurityTeam/Policies#Execute-Permission_Bit_Required

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: XDG standard desktop entries - desktop-file-utils and gtk, and KDE: mechanism of desktop database generation in profiles

[Danny Milosavljevic]

Hi,

On Sun, 07 May 2017 17:35:46 -0700
Chris Marusich <cmmarusich@gmail.com> wrote:
> Is this supposed to work "out of the box" on foreign distros?

If you set the environment variables as documented yes - although some distros do weird things in their startup scripts if the environment variable is already set when they start up.

> I've noticed that when I install an application (e.g.,
> "cool-retro-term"), the application shows up via the "Search" feature of
> the "Application Overview" in GNOME3 on GuixSD [1], but not in Ubuntu
> via the Dash's search results [2].  In Ubuntu, I tried adding
> $HOME/.guix-profile/share to the XDG_DATA_DIRS, but even after
> rebooting, the Dash search still failed to find the application.

Strange.  I'd inspect /proc/<dash-pid>/environ whether it actually got the environment variable, and then attach via strace -p <dash-pid> to find out what desktop files it's reading...

> In Ubuntu, the application only showed up in the Dash search results
> after I manually copied the desktop entry for the application out of the
> store and put it into a well-known location, such as
> ~/.local/share/applications.

That should not be the case - sounds like a bug.  The question is where...