[Top][All Lists]

[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 
>> >> ( 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.
>>  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.
>> -- 
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]