<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/110266/">http://git.reviewboard.kde.org/r/110266/</a>
</td>
</tr>
</table>
<br />
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
<br />
<p>- Heiko</p>
<br />
<p>On May 2nd, 2013, 8:05 a.m. UTC, Kai Uwe Broulik wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for kdelibs, KDE Usability, Aaron J. Seigo, and Frank Reininghaus.</div>
<div>By Kai Uwe Broulik.</div>
<p style="color: grey;"><i>Updated May 2, 2013, 8:05 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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)</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Tested in the Open File dialog of Kolourpaint. Looks nice, works.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kfile/kfileplacesmodel.cpp <span style="color: grey">(a73274c)</span></li>
<li>kfile/kfileplacesview.cpp <span style="color: grey">(117a9ed)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/110266/diff/" style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">File Attachments </h1>
<ul>
<li><a href="http://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibsplaces.png">Comparison (left old, right new)</a></li>
</ul>
</td>
</tr>
</table>
</div>
</body>
</html>