On 03/09/2012 05:05 PM, Rodolfo kix Garcia wrote: > I don't have time to do a full check but only three questions: > I fear, a minimum of time is needed to get a worthwhile overall picture about the whole mechanism. And there really is no need to hurry.
> 1. The .menu folder and your scripts are automatically copied in the > user folder? Yes? How? And... what's happend with new users? > If they are present in /etc/skel, like i have solved it for Window Maker Live, then they will be copied to any new users home directory. But in our context, at least for the moment, this is a separate issue. > 2. The file wmaker-debian-menu-edit uses "mousepad"? What's happend if > mousepad is not installed? and gxmessage? > Like i wrote in my initial announcement, along with gnome-terminal, both mousepad and gxmessage are a prerequisite to have it all work out of the box, in order to test everything without unexpected surprises. In accordance with Debian policy i could have prepared a version, which only relies on the most basic, desktop environment agnostic programs like xterm, xedit, and xmessage, but in terms of usability and functionality this would rather have been several steps backwards. We really do want some progress on the usability level, instead of just preserving technically correct, but user hostile policies and outdated traditions, in order to have Window Maker take advantage of its full potential, don't we? > 3. What's happend with new applications? And if one application is > removed from Debian? We should maintain the .menu files? > When update-menus is run in Debian, it only updates menu entries for those packages, which provide a menu file in the system controlled /usr/share/menu folder. But if there additionally is a menu file of the same name present in /etc/menu, which is maintained by the local system administrator, then this one takes precedence over the system wide installed menu file. This is a very powerful means to remodel the final resulting applications menu. Any menu file still present in /etc/menu for any uninstalled packages will be ignored for any subsequent update-menus run. This way the local system admin can either easily keep his menu customizations, or he can provide a means (e.g. via a script in /etc/dpkg/dpkg.cfg.d/) to have them also removed during package removal. But this is only the system point of view, and what we are trying to accomplish, is to give any normal user control over the menu layout. Therefore we shamelessly take advantage of the possibilities of the update-menus command, and have included an autostart scriptlet for the user's private Window Maker configuration, which runs update-menus during login, creating his very own private ~/GNUstep/Library/WindowMaker/menu.hook file. For comparison purposes, this private menu has been included in the ~/GNUstep/Defaults/WMRootMenu proposal as the second top level sub menu, in parallel to the first top level sub menu which references the system wide menu.hook file. Now what happens when a normal user runs update-menus is, that this command looks for the user's ~/.menu entries, instead in /etc/menu, and therefore takes precedence even over the local sysadmin's entries, to finally override the system defaults. If a package is not installed or is uninstalled, these private menu files are not touched in any way. They will be ignored for any subsequent update-menus runs, since there is no equivalent in the system wide /usr/share/menu folder. Furthermore, if there is a user created menu file whose name entry within the file starts with "?package(local.", any non Debian delivered random program can be added to the menu (see the provided ~/.menu/firefox and ~/.menu/thunderbird as examples). This way even a private menu can be easily kept up to date and suitably expanded with external entries. As we can see, any normal user is enabled to take control over the layout and content of his very own private menu.hook file. While this might still be too technical for any normal user, it is much more accessible than any system only configuration mechanism. Furthermore, the base ~/GNUstep/Defaults/WMRootMenu is in the WPrefs compatible proplist format right from the start, so nothing will frustrate any normal user if he tries to edit his very own root menu with it. > IMO, if you want to solve this problem, then think how to WindowMaker > should manage the root menu file. > Already done, see above. > For example, if wmaker knows how to > read the WMRootMenu, why cannot edit it? Because to read, wmaker read > the file WMRootMenu, it finds "menu.hook", search the file "menu.hook" > and then, show the menu. > While Window maker itself is easily capable of reading and displaying different menu formats, the WPrefs menu editor apparently can only handle menus in the proplist format. Therefore it simply fails if the base ~/GNUstep/Defaults/WMRootMenu is in any other format then the only supported proplist menu format. For Debian, the system wide base /etc/GNUstep/Defaults/WMRootMenu menu should at least contain the reference to menu.hook in proplist format, in order to not just fail when it is opened by the WPrefs menu editor. > For edit, wmaker could read WMRootMenu, search > the "menu.hook" file, copy it to $home/GNUstep/Defaults/WMRootMenu, and > then offer edit to the user. Of course, WPrefs should show a message to > the user with something like "If you edit the menu, the menu won't be > refreshed with new applications,...". When you found a new solution, > then, write it and upload it to the git. > Before i try to get acquainted with the complicated git usage (i only used it to checkout things up until now), i'd rather suggest to first evaluate my proposals, before finally deciding upon any action. In the meantime, i will try to get up to speed with git. The proper bare minimum entry for /etc/GNUstep/Defaults/WMRootMenu should be at least this here: (WindowMaker, (Debian, OPEN_MENU, "/etc/GNUstep/Defaults/menu.hook")) Obviously, it should additionally also contain some more entries, e.g. for a terminal, WPrefs, Exit, etc., something like this as a rather primitive bare bones example (easily to adapt as needed with WPrefs): ( WindowMaker, (Debian, OPEN_MENU, "/etc/GNUstep/Defaults/menu.hook"), (Terminal, EXEC, "xterm -sl 500 -fn fixed"), (Execute..., EXEC, "%A(Execute...,Type command to execute,execute)"), (WPrefs.app, EXEC, "/usr/bin/WPrefs"), (Exit, EXIT) ) Naturally, i would rather prefer to provide a much more advanced base menu, for example a variation of the one i have provided in my proposal archive, which is available from the http://sourceforge.net/projects/wmlive/files/ download area. My proposal is not carved in stone but, as is the nature of any basic proposal, is open for being adjusted as required or wished for. In any case, whatever a base WMRootMenu menu finally consists of, the main point is that it should *always* be in the proplist format, which is the only WPrefs menu editor compatible way to allow any user to easily modify it without deeper technical knowledge. This is the kind of advanced usability Window Maker is capable of, and which should be provided to any Debian user right from the beginning. > PS. The files (normally) in .menu includes this text. The upstream loves > you too :-* > > # This file is deliberately empty, and serves only to get > # rid of the slightly unfortunate upstream menu layout. > No, just 20 of the 113 provided modified menu files contain this as an entry. It serves to completely disable any menu entry for the affected package (mainly irrelevant command line utilities). I could have just emptied them, or commented out the entries, which would have the same effect, but a bit of explanation is much preferable. The remaining menu files are modified versions of the originals, in order to move their position within the resulting menu or give them a more meaningful descriptive name. The important thing is that the original package provided menu file in the /usr/share/menu folder is never needed to be touched, and always stays available as a means to reverse one's own modifications. So far, it looks like only two people downloaded the wmlive-wmaker-env_20120308.tar.gz archive. So it was kix and then someone else, most probably from this list? It would be really great if more interested people would evaluate my proposal and give some feedback here. Thanks a lot in advance! Best regards, Paul -- To unsubscribe, send mail to [email protected].
