On 03/08/2012 08:46 PM, Rodolfo kix Garcia wrote: > I will try to explain how the menu is implemented in Debian. I spent a > lot of time to understand it. > Thanks, there is no need for any explanation, i am aware about how it works. I just chose to use the menu system in a much different way than the current standard implementation of the Debian packages works, more or less, since ever. I know this because i use the Debian Window Maker package since even before Marcelo E. Magallon started maintaining it in 1997 (you will even find an entry from 2005 in the Debian changelog mentioning my name).
While you did some worthwhile modifications to Debian wmaker packages recently, it is in my humble opinion still far away from being user friendly. This is where my efforts are mainly concentrated on, and what i suggest for your consideration as official Debian maintainer. Did you try out and use my menu implementation for some reasonable time to actually understand how it reuses the wmaker menu-method generated Debian menus? Please do and try to understand what i actually try to accomplish from, and this is important here, a human interface design point of view. > 1. When the user run wmaker the fist time, the wmaker script copy the > configuration to $HOME/GNUstep. One ot these files is WMRootMenu, and > this file only contains one line: "menu.hook". > Which is fundamentally wrong, for a start, because it is not even remotely manageable with the WPrefs menu editor. Try it, and you will be confronted with an error message and the choice to switch to another standard menu, which is in no way related to Debian. In my (not so) humble opinion, this is the exact opposite of user friendliness. This effectively means that the Debian menu implementation of the wmaker package is not really well integrated with the actual Window Maker possibilities provided via WPrefs. While the reverse might hold true, having made wmaker fit to Debian, it unfortunately cripples the true and full potential Window Maker is actually able to provide. > 2. When the wmaker script launch the wmaker binary, WindowMaker opens > WMRootMenu, and find the line "menu.hook". Then, search this file in the > configuration paths (/usr/share/WindowMaker, /etc/GNUstep/Defaults,..). > Then, the menu.hook file is found. > > 3. wmaker reads the menu.hook file and creates the Root Menu. > And the user has no direct control over its contents, but only indirect influence by manipulating his own private .menu/* sub directory. And this also only when creating and using his own private menu.hook file. And only a technical user like you and me would actually bother doing that, but not normal people without any technical background. Still not at all convincing as a viable user friendly menu setup for Window Maker. We can do much better, even very much better. > 1. When a new application is installed, it creates a new menu file under > /usr/share/menu/applicationname > > 2. The debian postinst script of the application runs /etc/menu-method/* > to refresh the menu files. One of the scripts in /etc/menu-method is > /etC/menu-methos/wmaker. This file refresh the file menu.hook, and > includes the new application. > In its raw primitive glory, the developer produced menu file entries ultimately constitute rather a chaos, because all of them together create a heterogeneous hodge podge of a menu, which definitely lacks an easily usable common sense layout. As an extreme but typical example, for the command line calculator 'bc', which no normal user would ever bother about, the standard Debian menu file create a nested menu section named 'Science > Mathematics > bc'. It consists of nothing more than just opening a terminal with this command line tool running in it. The same for utilities like 'dc', 'units' and 'wcalc'. Menu entries with such characteristics are typically elimininated from the Window Maker Live menus, since they don't merit an entry. Are these examples really worth an entry in a user oriented menu? Wouldn't someone who knows about and actually uses 'bc' (i do at times) rather type the command in a running terminal window? What about the much more common 'ssh' command? Wouldn't any sane user of any command line tool like ssh rather use an open terminal to run that program, if not only for catching an error message in case something inadvertedly goes wrong? Wouldn't a normal user not rather prefer to use a GUI application over ssh, like for example putty, which he already knows from that infamous other OS which he has to use at work? This definitely merits a menu entry. There are dozens of other sample cases like these for the Debian menu files, and nobody does anything about it. Ubuntu finally did, and became popular as the "Linux for human beings". And i think in the context of the customized Debian variant 'Window Maker Live' it makes lots of sense to get rid of all this accumulated user hostile cruft. > 3. If an application is removed, the postrm script removes the > /usr/share/menu/applicationname file and the /etc/menu-mehtod/wmaker > script creates a new menu.hook file > A very nice mechanism indeed, if these menu files only were not such an inhomogeneous chaos! From a technical point of view this is very well done, but from the perspective of good human interface design it is just unmodeled raw material which needs someone to properly shape it. This is what Ubuntu did finally right, and i don't think that Window Maker Live does any worse. But it would be much nicer if this would already be as well shaped already in the Debian Window Maker packages. > Then, the menu.hook file has always a list of the installed > applications, and the user don't need to edit the menu. If the user > wants to change their menu, can edit the WMRootMenu file (vim, emacs or > WPrefs :-) ). > With all due respect, but this is just yet another sample of a developers' narrow view of computer interaction. What might be a perfectly fine approach for users like you and me, is not a very attractive approach for users without any kind of informatics background, and should be avoided like the plague. Even technical people in the end get tired of doing such things over and over again, which could easily be solved once and for all. It is a pity that instead developers appear to be abandoning the ship before reaching the final destination. Normal people want to use their computer for their own purposes, and they definitely do not want to bother configuring any such low level aspects before they can even think about their own tasks. They'd rather switch to Ubuntu or buy a Mac instead. You also forget that with the Debian delivered standard root menu the fantastic WPrefs menu editor can't fulfill its promise, because it is not designed to work with it. In this regard the Debian created root menu is absolutely counter productive. This is not something a Window Maker user should be prepared to expect when trying the Debian packages. No wonder if people rather prefer one of the full blown desktop environments if the standard Debian Window Maker configuration is not even remotely cooperative right from the start. The promise and richness of Window Maker is a very user friendly user interface. But if it is not properly configured right from the start, like it currently still(!) isn't in Debian, than only more technical users will be able to somehow handle it. > IMO, it the best way to maintain a WindowMaker root menu for a system. > If the users wants a different file, they can copy the contents of > menu.root to their WMRootMenu file and edit it. > A normal non-technical user expects to be able to not have to bother about things called "menu.hook", but to just use the WPrefs menu editor to modify the existing menu without any hassle. It is not too hard to make this possible, as my menu implementation amply proves. > Other windowmanagers/desktop environments uses /etc/menu-methos to > generate their menus too. > My menu implementation also reuses the update-menus generated menu.hook file, but applying it as a customized (=user friendly) applications sub menu. This is a very good compromise. Try it out, try to understand what i am intending to accomplish, and think about it. NeXTSTEP was a milestone in usability during its time, and Window Maker definitely holds similar promise, but only if properly configured right from the beginning. If any distribution delivered package is not managing to fulfill the existing Window Maker potential, it does not only not serve its users as well as it actually could, but ultimately does a disservice to its upstream developers efforts. Think about it! Thanks Paul -- http://wmlive.sourceforge.net -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
