Thunar could provide information about the current file selection and when it changes. This makes it possible for applications to provide context-sensitive actions in the broader sense. My usecase is integration with the launcher (on steroids) kupfer where access to a Selected File(s) objects enables the user to 1. Perform kupfer's actions directly in-context on the selected files in the file manager 2. Via the Triggers mechanism can even automate these actions, binding keybindings to complex actions like "Move selected files to ~/Archive" etc. Use The intended use is that as soon as the selection changes, an application can know what the user has now selected. Deselections are also important. Example: 1. User opens ~/Desktop, selects two files 2. User opens ~/Documents, selects three files 2. User deselects the files in ~/Documents At point (2) I would consider the current selection to be only the files in Documents. At point (3) I would consider the user to have an empty selection. This is supposed to be more intuitive for the user: You select a file in the front window, then you expect the context to be exactly that selection. Files appearing from selects in other (hidden?) windows will be surprising. This may be up to (third-party) application policy, by choosing how it keeps track of the selection. API Sketch FilesSelected: A signal. Carries arguments: (as selection, s display, u windowid) This assumes we pass the file information as URL strings in the first argument, selection. My personal preference would be an array of byte strings (aay), but this is probably inconsistent in Thunar. I assume here the signal should send a display value. The windowid parameter is just a token, if the application tracks selection in multiple windows. In my use case I envision always listening to only the latest signal and its list of files, including if the latest selection was empty -- a deselection. If performance is a concern, I think about sending the list of files with the signal even though perhaps no application is listening, A method GetSelectedFiles could be used to acquire the selection. The method could take the display and a windowid or similar token like before
I'd probably wrap this in a new D-Bus interface called org.xfce.FileSelector or org.xfce.FileSelection. Methods: - GetSelectedFiles (string array : uris, (u)int32 array : windowIDs) Signals: - FilesSelected (string array : uris, (u)int32 : windowID, uint64 : timestamp) - FilesDeselected (string array : uris, (u)int32 : windowID, uint64 : timestamp) The timestamps can be useful for startup notification of automatted actions. Not sure about the windowIDs array of GetSelectedFiles but it could be useful. FilesSelected/FilesDeselected could be merged into a single signal - SelectionChanged (string array : uris, (u)int32 : windowID, uint64 timestamp) that sends all files selected at the moment. FilesSelected would only contain newly selected files and the old selection might still be valid (just imagine there are three files A, B and C and the user first selects A, then selects B in addition. The result would be two FilesSelected signals, one with A and the other with B, while SelectionChanged would emit A first, then A and B). I need to think about what makes more sense a bit more. Opinions?
It sounds like a simple signal like your SelectionChanged works with almost everything. - SelectionChanged (string array : uris, (u)int32 : windowID, uint64 timestamp) Although I didn't forsee commands reacting directly on the selection event, only immediate knowledge of the event, it's an interesting suggestion. I think a single signal is better than a selection and a deselection signal. I also think it is better to send the full selection per window in each signal. That's all. I'm thrilled by your positive response to this request!
There is now a standard for this, so better to keep to it. Closing duplicate. *** This bug has been marked as a duplicate of bug 11024 ***