[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggest A debian-style menu system for guix
From: |
Feng Shu |
Subject: |
Re: Suggest A debian-style menu system for guix |
Date: |
Mon, 24 Apr 2017 20:48:47 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
ng0 <address@hidden> writes:
> Feng Shu transcribed 1.5K bytes:
>> ng0 <address@hidden> 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.
--