2

Dear all,

This idea originated in a discussion over at Aurélien Gâteau's Gwenview blog: http://agateau.com/2012/12/04/changes-in-gwenview-for-kde-sc-4.10/

My original description of the problem concerns image select in Gwenview, but this workflow issue would probably benefit from a general solution that would work across KDE and associated Qt applications, including konqueror, Dolphin and digiKam.

Problem:

Often when I select a subset of images to say drag-and-drop or upload somewhere, I Ctrl-click them in Browse mode to build a selection until I come to images where I need to pick one image among several similar candidates. To be able to pick the best one though, I often need to check them in the View mode but double-clicking one of those candidates or switching to that mode also deselects all the ones I've previously selected...

I would like a selection mode that is persistent until I either click some deselect button or close the program. Similarly, it would be nice to select (or perhaps rather, mark) an image while in View-mode and have it already persistent-selected as one switches over to the browse mode.

Solution:

I think the tagging system is powerful enough to support this. What is needed is a UI implementation that makes it convenient to use it for "disposable" temporary tags. In addition to persistent-select and deselect buttons or similar UI elements, it would be nice with something like a key+mouse button binding, like Ctrl+middle or Ctrl+Shift+left or something, along with perhaps a different selection color highlighting the selected items.

That idea is simply awesome! Thanks!

This feature makes sense in so many situations. Not only that you can 'pause' your selection handling and do something else inbetween, you can also propagate a selection between different applications! This clearly makes sense and should not be too difficult to implement.

However I disagree with your suggestion to implement this based on an extension to the tagging system. To me these are two separate things. And whilst it might be possible to extend the tagging subsystem withwould like to propose a different approach these features it rarely is a good idea in the long run to integrate such different features. The tagging subsystem will be target of multiple changes in future anyway, since tagging will get more and more important for daily usage.

I would like to propose a different approach to implement your great suggestion:
A separate 'shelf' for selections: something like the clipboard history, but for selections, not content. Let's call it a 'selection board' for now.
If you have a selection there is an action offered: "remember selection". When chosen the selection gets stored as a set inside the proposed 'selection board'. So that boad acts like a heap and accepts simple sets (arrays). The 'selection board' stores selections in a persistent manner. Later on, or from within another application, you can call an action 'fetch selection', so chose an existing selection from the board and have it replayed to the list of objects in focus.
Each set simply consists of references to selected objects, an object being represented by a combination of type, location and id of the object. So for example ['file',<path>,<name>].. or [text,<path>,<cursor position>]. Primary actions are 'push to clipboard', 'fetch from clipboard', secondary actions probably are 'merge with' and things like 'remove from'.
Conflicts may arise and have to be handled. For example files may have been deleted meanwhile. So replaying a selection should result not only in the objects being selected, but also in a message about the success of the action. Here it would make sense to point out that one or more files could not be selected again due to whatever reason.

The framework would have to be offered by a core component. That component acts like a deamon, or better service. A graphical representation is welcome, but keeping that separate might make sense. The glue between applications and board is an API. Applications can implement the API, thus offering to store selections and/or fetch selections from the board. Most likely using DBUS makes sense for this (though this again introduces problems for KDE on MS-Windows platforms where there is no DBUS).
This way a smooth introduction period would be possible: once the framework is implemented, each application can be ported separately one by one.

---
More suggestions? Better ideas? Want to get started?

Actually, the more I think about the feature, the more I come to the conviction that this could be implemented based on the current clipboard.

In fact klipper (the clipboard history application) already stored selections of files. Have a try: select a few files inside the dolphin file manager and hit CTRL-C ("copy"). Then open klipper: there is a new entry holding the urls of the selected files.

I see two things missing:
1.) a better representation inside klipper indicating the size of the selection
2.) a way to replay the selections

Currently step 2 is possible inside a terminal: obviously when you type kate and click with the middle mouse button the clipboard entry is pasted, so kate gets handed over a list of urls pointing to files. But only close, actually the elements of the selections are separated by line breaks (whyever), so what appeared intuitive does not really work. And obviously a usage apart from a terminal would be preferred: some way to replay the selection into dolphin or a any file based dialog.