--8bBEDOJVaa9YlTAt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 02, 2003 at 02:47:25PM +0100, Daniele Pighin wrote: > david> I can imagine that some people would want to david> have their > plugin available in a single right-click I hope my poor english will > be enough to explain this concept, which is quite complex :) I think > that a developer (team) shouldn't be allowed to undo (or mess up) the > job of those providing him the infrastructure he's working with. Yes! 100% ACK. Please read my reply in this thread. I vote for removable service entries and submenus instead of too many top-level entries. For example the "open in new tab" feature could be put into a submenu. I'd also ask KDE (or Qt!) developer to have a look at IceWM. IceWM copied a concept from OS/2 (which got it from neXT I think) which I call 'conditional submenus': Usually when you select a submenu it expands. Conditional submenus have a 'default' choice: if you select the menu entry this will default choice will be executed. IF you select the expansion arrow on the right side though, the menu will expand - and (optionally) remember the (non-default) entry you click on as the next time's default. The arrows had a border in OS/2 and still have in IceWM (I think) to differentiate them from the non-conditional submenus. ("[->]" instead of "->") With this feature you could make menus easier to navigate without forcing people to click twice for almost everything they want done. For example, some people prefer the trashcan while others delete files at once. Others like to overwrite files for security. For now we have two or three context menu entries: | ... | | Delete | | Move to trash | | Overwrite (safe delete) | | ... | This could be abbreviated to | ... | | Remove (Delete) [->] | | ... | When the user clicks on the text, the files will be deleted (default action). When the user clicks on the arrow, the menu will expand=20 | ... |------------------. | Remove (Delete) [->] | Delete (default) | | ... | Move to trash | | Overwrite | | ... | Let's say the user chooses "Move to trash": The next time a file's context menu is selected the menu will show | Remove (Move to trash) [->] | and if expanded | ... |-------------------------. | Remove (Move to trash) [->] | Delete | | ... | Move to trash (default) | | Overwrite | | ... | The same thing could be done with the "Open" functions: | ... | | Open in new ... (Tab) [->] | | ... | expands to | ... |----------------------. | Open in new ... (Tab) [->] | Tab (default) | | ... | Tab in background | | Window | | Window in background | | ... | Or with compression software: You mark several files and then select | ... |----------------------. | Create Archive (.tar.gz) [->] | .tar.gz (Default) | | ... | .tar.bz2 | | .zip | | .rar | | .zip | | ... | Or with graphics software:=20 "Convert to ... (PNG)" -> (PNG, GIF, JPG, ...) And every time, there's just _one_ mouse click required for the selection you use most often. The others are still available, but they don't clutter your menus. And please remove the "Add to bookmarks" context entry, it's really useless _unless_ it is made a submenu where you can select any bookmark sub-folder (like Netscape's "File bookmark..."). Nobody puts all his bookmarks in the top-level. > Moreover, I would: > - provide a graphical interface to edit a user's own service-menus Yes. Any volunteers? ;) > - allow users to put the entries defined in their own user-defined > service-menus wherever they like, as if the users want to mess up > their menus it is their problem Perhaps. But if you do that please provide a kiosk mode option to lock them as well, because some users are too stupid and I don't want to be on helldesk duty when somebody toyed with his menus and messed it all up. =20 --=20 mfg, Jens Benecke=09 =20 http://www.hitchhikers.de: Europas Mitfahrzentrale seit 1998 Fahren Sie zusammen, sparen Sie Geld - unkompliziert und schnell! NEU: Jetzt mit kosteng=FCnstiger, umfassender Unfallversicherung! --8bBEDOJVaa9YlTAt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+PvxI153rQBa8U44RAsLIAJ9X81ub0oR2HHCYS8NXE4gXjsEgSgCfZDD1 WRi5vTmrxM75+DjA9HXFfAQ= =v1Ur -----END PGP SIGNATURE----- --8bBEDOJVaa9YlTAt-- _______________________________________________ kde-usability mailing list kde-usability@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-usability