Review Request 109015: Cleanup Places Panel context menus

[Kai Uwe Broulik]

> On April 30, 2013, 3:40 p.m., Aaron J. Seigo wrote:
> > code looks decent; the menus look much nicer.
> > 
> > this implies, of course, that one can *always* click in an empty area of the panel to get to the Add Item, etc. entries. hopefully this is the case?
> > 
> > also, i never understood why a manual Icon Sizes menu was put in there. it is actually a complete regression back to the "configure all the pixels!" approach of 3.x. the previous approach of simply picking a reasonable pixel size based on the # of entries and the width of the panel was easy and intuitive.
> > 
> > as for getting something like this into kdelibs .. it is indeed feature frozen, though inconsistency would be a bug imho. what would be truly fantastic in frameworks 5 is to implement the places panel in a way that it could be used by dolphin from kdelibs at that point. iow: why do we have two of them? :)
> 
> Frank Reininghaus wrote:
>     (a) About "the previous approach of simply picking a reasonable pixel size based on the # of entries and the width of the panel was easy and intuitive": but it was also a PITA more often than not for quite a few users, see the earlier comments in this request. The icon size changed suddenly not only when resizing the panel and/or window, but also, e.g., when devices were attached to/removed from the computer. Just the other day when I worked on a system that still had KDE 4.7, I noticed that the icons even resized when I enabled or disabled the terminal panel.
>     
>     When Peter rewrote the Places Panel for Dolphin 2.1/KDE 4.9, he made the icon size fixed, which is consistent with the "one places icon size fits all" approach of all other file managers that I know. But then there were so many complaints from the more vocal fraction of our user base that I thought that adding that "Icon Size" menu might be a reasonable compromise. There might be other solutions, please refer to the earlier comments here, in particular the discussion between Thomas and myself.
>     
>     (b) About "iow: why do we have two of them?": Peter decided to rewrite the Places panel for Dolphin 2.1/KDE 4.9 based on Dolphin's new view engine. It has a couple more features (like different groups for Places/Devices/etc., quick links to Nepomuk searches) and a few things less that some people considered nice, but which caused serious trouble for others (like the automatic resizing and the "free space" overlay that appeared when hovering a device).
>     
>     In the long term, having two "Places" implementations in KDE is obviously not a good idea. A new widget (probably QML-based) that could be used everywhere in the frameworks era would certainly be welcome :-)
>     
>     You might argue that forking/rewriting the Places widget for Dolphin was a bad idea in the first place, but then please discuss this with Peter. I had nothing to do with that decision, but I also don't feel in a position to simply undo all this and drop the new features.
>     
>
> 
> Kai Uwe Broulik wrote:
>     > this implies, of course, that one can *always* click in an empty area of the panel to get to the Add Item, etc. entries. hopefully this is the case?
>     
>     It is the case in Dolphin's view, if it is full you can still click on the category titles. Working on the kdelibs version I found that there, if it is full, it is really hard to get to the general context menu, so I am not sure how/if I should proceed there.
>

On the other hand, I found that in kdelibs places there is *always* an empty spot at the bottom and to me looks natural to scroll to the bottom and there add a place.


- Kai Uwe


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109015/#review31808
-----------------------------------------------------------


On Feb. 18, 2013, 6:43 p.m., Kai Uwe Broulik wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109015/
> -----------------------------------------------------------
> 
> (Updated Feb. 18, 2013, 6:43 p.m.)
> 
> 
> Review request for Dolphin, KDE Usability and Frank Reininghaus.
> 
> 
> Description
> -------
> 
> This patch cleans up the places panel context menus by:
>  - Removing the device name in all the entries, it just distracts and every … single … entry has them. (It is debateable whether that title is needed or fitting, I am not a huge fan of these)
>  - Moving "Open in a new tab" to the top like in most other places in KDE (Unmount and Empty Trash are always above because they're more important) 
>  - Moving Icon Size to the global context menu rather than the item context menu where it made no sense from a context perspective
>  - Removed "Unlock panels" from item context menu (also no "contextual" thing)
>  - Removed "Add Entry" from item context menu
>  - Removed "Show all entries" from item context menu
> 
> See screenshot for direct comparison between all changed context menus.
> Of course this makes Dolphin's places panel drift even further away from generic kdelibs places panel but they so different already …
> 
> 
> This addresses bug 310764.
>     http://bugs.kde.org/show_bug.cgi?id=310764
> 
> 
> Diffs
> -----
> 
>   dolphin/src/panels/places/placesitemmodel.cpp 1acbb57 
>   dolphin/src/panels/places/placespanel.cpp e23732c 
> 
> Diff: http://git.reviewboard.kde.org/r/109015/diff/
> 
> 
> Testing
> -------
> 
> Editing still works, hiding/showing items, showing all, changing icon size, emptying trash, mounting/unmounting.
> 
> 
> File Attachments
> ----------------
> 
> Comparison (left old, right new)
>   http://git.reviewboard.kde.org/media/uploaded/files/2013/02/18/cleanupplaces.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130502/bbc0d6af/attachment.htm>