> On May 2, 2013, 10:15 a.m., Heiko Tietze wrote: > > Of course the changes do improve the menu and I believe your proposal would > > be helpful. > > > > But I would like to discuss the following points: > > > > * Adding a header to menus is not commonly used. And I'm not sure why I > > need to know where I have clicked right now. Relating to design: icons with > > varying indent make visual noise. > > * 'Hide' is applied per checkbox, i.e. the action will be executed later > > (or in respect to the "Show all" checkbox). Strange behaviour. > > * 'Edit...': Do I edit the label (usually a rename action via F2), or do I > > edit the reference/link (trash://), or do I edit the appearance of the > > item? And the dots (aka ellipsis) points to additional input that will get > > requested from the user in a dialog shown after click on the item. Strange > > again because it's easier to remove a bookmark and add it again. Managing > > bookmarks relates to sorting, grouping, naming, etc. > > * "Add entry..." Same problem with ellipsis. > > * Placing the generic items at the end is a good idea. But do novices or > > even non-experts know how where to find those important information? > > > > What we need is a styleguide that applies to all KDE applications. It > > defines not only how menus look like but as well when items are disabled or > > hidden, for instance, how to deal with standard functions, and how to label > > stuff - all in general. And we need to have specific guidelines for the > > application itself. That means which function is provided and why, who uses > > it and in which situation, how does it fit into general look and feel, and > > so on. For instance: "The panel Places provides bookmarks for fast access > > to user defined folders. Users can add bookmarks either per drag and drop > > or per menu. Items can be removed, renamed, and resorted. The list of > > bookmarks follow the visual guideline of lists with medium length." > > (incomplete example, just for illustration of the idea) > > > > Following this, either 'trash' and 'removable media' should be moved into a > > different panel unless user copy the item into the Places panel (which > > makes the actual dropdown menu very simple) or the requirements need > > overhaul. > > Kai Uwe Broulik wrote: > > * Adding a header to menus is not commonly used. > I know, but now the item name is no longer thrown at your face but you > have to actually remember where you clicked. And the menu looks like a neat > solution for that, and the menu doesn't look so tiny then, also. It's done > for toolbar items context menus as well. > > > * 'Hide' is applied per checkbox, i.e. the action will be executed > later > I dislike toggle actions, that change their name, ie. "Hide" and then it > will become "Show". A checkbox imho is a totally valid thing for this. When I > uncheck the "Show Toolbar" or "Show Menu" actions, they're also applied > immediately and say "Show" all the time. And this is a common component/part > in all of KDE > > > * 'Edit...': Do I edit the label […] or […] reference/link […] or […] > appearance of the item? > Umm … really? … They only thing I could expect is it showing the actual > target's properties (ie. the folder it is pointing to itself) but the other > things are not something I would expect. > > > * 'Add entry...' umm, the application indeed wants further input from > me, the place name, URL and icon, that is. > > > * Placing the generic items at the end is a good idea. > Nothing I've done on purpose, just happened incidentally. > > > What we need is a styleguide that applies to all KDE applications. > Yup, every major OS/UI (Win, OS X, Gnome, …) have a huge illustrated > styling guide with lots of Do's and Dont's > > > Following this, either 'trash' and 'removable media' should be moved > into a different panel > Umm … Trash is something that's hard to access otherwise because it's not > a really "physical" folder. Have you had a look at Dolphin's Places bar? > There is a clear separation between Places (directories) and Devices > (Bluetooth devices, removable media, …)
How about having an extra "Add entry" button at the bottom of the list? That's what would be most intuitive for me (and the easiest to use, too). Right-clicking an existing entry to add a new one... I don't know. Not incredibly obvious from my perspective. - Sven ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110266/#review31877 ----------------------------------------------------------- On May 2, 2013, 8:05 a.m., Kai Uwe Broulik wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110266/ > ----------------------------------------------------------- > > (Updated May 2, 2013, 8:05 a.m.) > > > Review request for kdelibs, KDE Usability, Aaron J. Seigo, and Frank > Reininghaus. > > > Description > ------- > > This is a follow-up review request for Review 109015 which does the same for > Dolphin. > > This patch cleans up the places panel context menu by: > - Removing the term "Entry" and the entry name in every single item. To > still have easy context, I added a menu title instead. > - General actions such as "Show all" and "Add Entry" are removed from item > context menus (they're not related to the item) > > See screenshot for direct comparison of old and new. > > You can still add an entry, even if the list is full, by scrolling to the > bottom of the list where there is always an empty spot to click on. To me it > sounds logical to add an entry at the end anyway. (Dolphin doesn't directly > have this problem since you can always click the group titles (Devices, > Places, Search For, …) which are not considered an item and thus spawn the > general context menu) > > For Frameworks 5 it would of course be great to merge Dolphin's places panel > duplication back into kdelibs to provide a unified user experience and reduce > maintenance cost. (Or write a new one based on QML, :P) > > > Diffs > ----- > > kfile/kfileplacesmodel.cpp a73274c > kfile/kfileplacesview.cpp 117a9ed > > Diff: http://git.reviewboard.kde.org/r/110266/diff/ > > > Testing > ------- > > Tested in the Open File dialog of Kolourpaint. Looks nice, works. > > > File Attachments > ---------------- > > Comparison (left old, right new) > > http://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibsplaces.png > > > Thanks, > > Kai Uwe Broulik > >
