FACORAT Fabrice posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 09 Oct 2003 17:44:16 +0000:
> Le jeu 09/10/2003 � 12:50, Duncan a �crit : >> Svetoslav Slavtchev posted <[EMAIL PROTECTED]>, excerpted >> > it could be in a sub menu "install more software", >> > which uses the menu structure of the main menu, >> > has nice icons, and a good description >> >> I like this idea. Have one entry on the menu that leads to another copy >> of the menu, as suggested. > > beurk ! > In all usability test you will see that you should avoid more than 3 > level in menu. Another sub menu could put 4 level and even 5 level ! > tooo much. > And you will decide which apps to put ? The additional levels would only be activated if someone is attempting to (un)install something. On the regular menu, there'd be one single entry that would then pop up as a submenu the entire menu, with all possible menu entries there, installed and uninstalled. If someone were to wish to change installed programs, then, they'd use this menu entry, which would then become effectively the top level menu for installation. If one still insists on the usability limit of X levels of menu, simple! Just create an app that has only two entries, an exit, and a copy of the normal menu, but with all possible menu entries displayed, installed or uninstalled. >> However, having as one entry a nested copy of the main menu layout, >> with all possible entries on it, for (un)installation, would be >> manageable using the current interface. All it would require would be >> some more text format .mnu files under /usr/lib/menu, and perhaps >> loading a few more icons, tho not many as many of them are used >> multiple times as is. > > 1�/ disk space Hardly an issue. Pretty much everything is already there. The files in question are *.mnu files, comparatively small text files. If block usage is a problem, simply use the menudrake solution and put all entries in a single file. Take a look at /usr/lib/menu, and /etc/menu, for what's currently there. The other thing would be the icons for the menu entries, but as I said, many/most of them are already there as well. There would be very little additional space used. Maybe for one more app/package, that's it. Of course, the screenshots package would be bigger, but that'd be separate and optional. > 2�/ complexity when parsing this Again, it would use the existing solution, so would be no more complex than the existing solution. > 3�/ menu bloat Not a problem. As originally proposed, everything would be under one submenu entry. Don't activate it when you aren't installing/uninstalling. In the modified application proposal above, even that would disappear, as everything would be in the menus as displayed in the install/uninstall app. > 4�/ time/cpu consuming when need to update menu ( as you need to > reparse everything, etc ... ) It's already done when installing packages or whatever. Yes, this would add a bit of additional time, but it would only happen during application install/uninstall, when there's some time taken anyway. >> Item entries on this new menu would call up a tool that would see if it >> was installed already or not. If so, it would offer the user the >> option of uninstalling it. If not, it would offer the user the option >> of installing it. > > this features exist before ( normal click and not right click ) and mdk > remove it as this was too buggy. It uses the same system as currently used, so how could it be to buggy, unless the current system is to buggy? >> Alternatively, packages could be modified to change this menu entry >> upon installation, and change it back upon uninstall. In this way, the >> entry could display say an x if uninstalled, or a plus if installed, >> making it immediately obvious what was installed from the installer >> menu, without having to take a trip back out to the main menu to look >> again, if in doubt. > > How are you going to manage this ? The same way new menu entry additions are already processed, when a new program is installed or uninstalled. Only, instead of one entry being processed, there'd be two, one changing the operational menu as is currently done, the other toggling the install menu entry between install and uninstall, a simply change of two parameters in an otherwise identical entry, most likely, one changing the installed indicator in the title from say "x" to "+" (or the reverse), the other toggling the parameter sent to the installer similarly. IMO, this remains one of the better solutions, because it works with what's already there and tested, requiring only small changes and a different urpmi front-end, to implement the new functionality. Given the low cost of implementation, both in space and programming, and the leap in intuitive installation management functionality, it sounds like a no-brainer, to me, as there simply isn't a whole lot of additional programming to do, therefore, not much that could be buggy, except where current implementations remain buggy. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
