[KDE Usability] Review Request 109015: Cleanup Places Panel context menus

Kai Uwe Broulik kde at privat.broulik.de
Thu May 2 08:34:57 BST 2013



> 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.
>     
>

> 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.


- 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/8b081333/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-usability mailing list
kde-usability at kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


More information about the kfm-devel mailing list