kupfer

Bug #786142
Comment #9

Comment 9 for bug 786142

Revision history for this message

David Schneider (dnschneid) wrote on 2011-05-21:

Actually, in X the clipboard is another type of selection, not the other way around, but it's really just an issue of semantics.

More importantly, Simon does have a point (although it is phrased a bit harshly), and we could always spend some more effort thinking of better ways to arrange the UI.

The Selected Text mechanism was actually moved into the Clipboard plugin at my request, as it has performance implications (selections are always realized and copied into Kupfer whether you'll be using them or not, which can especially suck if the program is run remotely) and interacts badly with some programs (bug 762607), and the user had no means of disabling it due to it being in the "core" plugin. The Clipboard plugin duplicated a bunch of its code, so it seemed natural from a development standpoint to move it in there; but as you said, it is strange for the user to enable a "Clipboard" plugin to have access to the current selection, especially since Kupfer gives no feedback as to why it is not working.

This also highlights a more general issue with the keyboard shortcut preferences pane--the shortcut is listed there whether the code backing it is active or not. I suggest one of two things:
1. Hide the shortcut entry entirely if the backing code isn't active. This avoids confusion, but impedes the user from discovering cool features.
2. When the user sets a shortcut's key config, and when they try to use it notify them if a requisite plugin is not enabled, and maybe offer to enable it or show the plugin config screen. One cool thing would be to generate and select an object in the kupfer window that is "Activate X Plugin" (and show a notification saying that the plugin isn't active for the keyboard shortcut), although that might require the "Kupfer Plugins" plugin to be enabled, which defeats the purpose.

As for selection itself, I see two options:
1. Split the selected text plugin into its own "Selected Text" plugin. We should probably do one of the two above if the plugin isn't active, although at least this is more sensible.
2. Keep it in Clipboard. This is only acceptable if one of the two above is done as well.

Thoughts?

Actually, in X the clipboard is another type of selection, not the other way around, but it's really just an issue of semantics.

More importantly, Simon does have a point (although it is phrased a bit harshly), and we could always spend some more effort thinking of better ways to arrange the UI.

The Selected Text mechanism was actually moved into the Clipboard plugin at my request, as it has performance implications (selections are always realized and copied into Kupfer whether you'll be using them or not, which can especially suck if the program is run remotely) and interacts badly with some programs (bug 762607), and the user had no means of disabling it due to it being in the "core" plugin.  The Clipboard plugin duplicated a bunch of its code, so it seemed natural from a development standpoint to move it in there; but as you said, it is strange for the user to enable a "Clipboard" plugin to have access to the current selection, especially since Kupfer gives no feedback as to why it is not working.

This also highlights a more general issue with the keyboard shortcut preferences pane--the shortcut is listed there whether the code backing it is active or not.  I suggest one of two things:
1. Hide the shortcut entry entirely if the backing code isn't active.  This avoids confusion, but impedes the user from discovering cool features.
2. When the user sets a shortcut's key config, and when they try to use it notify them if a requisite plugin is not enabled, and maybe offer to enable it or show the plugin config screen. One cool thing would be to generate and select an object in the kupfer window that is "Activate X Plugin" (and show a notification saying that the plugin isn't active for the keyboard shortcut), although that might require the "Kupfer Plugins" plugin to be enabled, which defeats the purpose.

As for selection itself, I see two options:
1. Split the selected text plugin into its own "Selected Text" plugin.  We should probably do one of the two above if the plugin isn't active, although at least this is more sensible.
2. Keep it in Clipboard.  This is only acceptable if one of the two above is done as well.

Thoughts?