> On Aug. 21, 2016, 9:08 a.m., Martin Gräßlin wrote:
> > As the maintainer of both klipper and kglobalaccel I'm strictly against
> > ading this shortcut by default! This was already stated by me in the bug
> > report by setting it to wontfix.
> >
> > At the moment this would result in a hidden default shortcut no user knows
> > about. This is bad, we should not add unexepected and unknown shortcuts.
> > And we should not needlessly steal shortcuts from applications. In doubt
> > don't set a shortcut by default. At the current time this would only result
> > in a degrated user experience: either an in-application shortcut, which we
> > don't know that it existed, started to break, or the user presses the
> > shortcut and gets hit by surprise what happens. It's totally unexpected
> > behavior to open this menu.
> >
> > Before we start to add new shortcuts, we need to rethink and implement
> > better ways of global shortcut handling:
> > 1. educating users about shortcuts
> > 2. ensuring that we don't steal shortcuts (e.g. by setting up a policy
> > about which modifier belongs to the DE)
> >
> > As long as these problems are not solved, I'm strictly against adding
> > shortcuts for hidden functionality. No matter how much we personally think
> > they are sensible.
>
> Andreas Kainz wrote:
> In General you are right and we work on aa shortcut strategy, but it need
> time and in the end everybody will say. Dont Change my shortcut workflow.
>
> Why There are two global shortcuts available in klipper. Arent They
> hidden functionality?
>
> What Is your user scenario for klipper?
>
> Martin Gräßlin wrote:
> > Why There are two global shortcuts available in klipper
>
> No idea. Legacy. Probably should be removed.
>
> > Arent They hidden functionality?
>
> Yes they are. But they still are if we expose the shortcut and nobody
> knows about it.
>
> > What Is your user scenario for klipper?
>
> If I'm totally honest I would love to kill most functionality of klipper.
> Because it's unmaintained and as you say hidden functionality. I don't know
> why there are things like the "Invoke action". Also the menu is something I'm
> not totally happy with as it requires a completely differnt code path. If I'm
> totally honest I don't want these features to be exposed to more users as I
> don't think they are in a good shape and we don't have developers working on
> klipper (haven't had for years, I only took over maintainership because it
> needs significant adjustment for Wayland).
>
> Andreas Kainz wrote:
> Its aAA default widget and it is aa usefull one in my workflow, but with
> the new shortcut it would improve the widget to a great feature. aa
>
> Thomas Pfeiffer wrote:
> Klipper does have very corner-case features which I suppose could be
> removed without much of a loss for most users ("invoke action" definitely
> being among them). Klipper is a KDE-typical case of just adding features
> because they're possible, without any product vision.
>
> Invoking Klipper at cursor position, on the other hand, is a useful
> feature, which can in fact make users more productive if they know about it.
>
> The shortcuts overlay is in the plans and will certainly happen, and it
> could expose that shortcut.
>
> As for the actual shortcut: It should be with Meta, following a scheme we
> want to establish where global shortcuts should by default be with meta in
> order not to conflict with any applicaiton shortcuts.
>
> Martin Gräßlin wrote:
> > but with the new shortcut it would improve the widget to a great feature
>
> Only if the shortcut is known to the user. Which it currently isn't. This
> turns the whole thing pointless.
>
> Let's first improve the infrastructure, then start adding new shortcuts.
> Also we need to evaluate very carefully which features to expose with a
> default shortcut. Every shortcut we have is a risk of breaking applications.
>
> If having the clipboard history open at the cursor position is an
> important feature, then we need to think about the best way to expose it. I'm
> not sure whether having a global shortcut by default improves this is any
> way. In fact I know about it and even have a global shortcut set, but I don't
> use it at all.
>
> I'm sure that there are better ways to include a clipboard history. It
> might need more code, but let's think at a good global experience and not
> just at the global shortcut. This must be possible with the existing
> interaction pattern using ctrl+v or right click.
>
> Andreas Kainz wrote:
> good points martin. In general I would say awesome ideas but on the other
> hand I know it's not on your todo list and your list is long. I know I can't
> do it.
>
> All I know is that I can review all the existing global shortcuts, with
> the new overlay stuff from thomas we can bring shortcuts to the user and I
> can change global shortcuts (in the code) by myself.
>
> So I can offer to work on the existing shortcut stuff and can improve it.
> I can't do all the really awesome stuff martin wrote. But if I work on the
> global shortcut stuff, I only will start when the developers think, global
> shortcuts are a good idea. Otherwise it's wasted time.
> I know it's not on your todo list and your list is long. I know I can't do
> it.
KDE is huge and I'm not the only dev. Let's not stop thinking big just because
one dev is busy.
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128726/#review98523
-----------------------------------------------------------
On Aug. 21, 2016, 2:47 a.m., Andreas Kainz wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128726/
> -----------------------------------------------------------
>
> (Updated Aug. 21, 2016, 2:47 a.m.)
>
>
> Review request for Plasma and KDE Usability.
>
>
> Repository: plasma-workspace
>
>
> Description
> -------
>
> add a default shortcut for open clipboard at mouse point (ctrl+alt+c)
>
> BUG 366690
>
>
> Diffs
> -----
>
> klipper/klipper.cpp 525ef87
>
> Diff: https://git.reviewboard.kde.org/r/128726/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Andreas Kainz
>
>
