On 6 April 2010 17:16, Zachary Klein wrote:
> I noticed that _no one_ has yet addressed the issue of why we already have
> a context menu on the device listings, with three entries, only one (Hide
> Device) even pertaining to the device management (the others are "unlock
> Widgets"(?) and something I can't recall -don't have an y devices with me
> atm!). I understand the concept of wanting to limit context menus (though I
> wonder at the wisdom of witholding features from desktop users because
> hypothetical touchscreen KDE/Plasma users don't have a right-click... like
> Dotan said, they don't have "hover" either, and Plasma uses hover liberally).

Touchscreens do have some kind of hover; it's just the same gesture
that drag'n'drop. If you drag on a draggable object it begins a drag
action. If it's not draggable, the screen enters a mode where moving
the stylus triggers the mouseover events (and the initial click of the
stylus is cancelled).

The only major problem with hover in touchscreens is for web browsers,
because the screen background of a webpage is always draggable and the
hover mode can't be activated.


> However, if the *context* menu is there  already, what exactly is the issue of
> adding a *contextual* entry?

The only problem would be having too many entries in the context menu.
Since this is not the case here, I support adding the Eject command to
the context menu (even if it's already in a button) and removing from
it the existing non-contextual actions which are already accessible at
the main plasmoid context menu.

I don't think having the same function twice is problematic, specially
when the primary way to activate it is with a non-standard widget. The
context menu has the advantage of being always available and having a
well-known behaviour, so it's easier for users with some training to
discover those functions.
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability