[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    [KDE Usability] HIG for mouse button Events
From:       Rick Stockton <rickstockton () reno-computerhelp ! com>
Date:       2013-02-26 19:32:31
Message-ID: 512D0DCF.3070001 () reno-computerhelp ! com
[Download RAW message or body]

Hi, everyone.

This is a forward-looking request for HIG regarding mouse Button Events.
As you know already, from my previous posts to other KDE and Qt Lists,
Qt 5.x (specifically 5..0.2+) provides two new capabilities, for which
we might want to create HIG for Application Developers.
Please Ref https://bugs.kde.org/show_bug.cgi?id=96431. The capabilities are:

(A) more mouse buttons (as many as 31; but 16 is a more reasonable
maximum for HIG on XCB and Wayland platforms.) and

(B) correct tracking of button State ("Up","Not Held" versus
"Down","Held") for ALL possible buttons.

Even though Xi 1.x only provides a button mask of Left-Right-Middle,
(plus the fairly useless "State" of Wheel up and Wheel down), the mask
of Qt::MouseButtons Flags is now intended to be accurate for the entire
width of Platform and hardware-supported buttons.
- - - - -

Some preliminary thoughts, which I will number for convenient reference
in replies:

#1: KDE Applications have limited, inconsistent support of even
Qt::BackButton/Qt::ForwardButton, which are pretty well defined.

But, many mouse devices include have 4-way wheels without, while not
offering any "side" buttons at all. Should we recommend that Scroll-Left
and Scroll-Right perform "Back" and "Forward" functionality, unless some
new "mouse/wheel shortcuts" KCM is written to allow global choices of
Scroll versus Button "Back" and "Forward"?

#1A: And if so, should we default BOTH the buttons and Left/Right wheel
to do the same functionality, until configured otherwise? (Users could
be confused by KDE Apps defaulting the "Back Button" to a function
_other_ than "Back".)

#2: What about all those "higher" buttons? Should we define a "default
KDE Application Function" for Extra Button above Qt::BackButton?

#3: What about the definition of multi-button sequences? Perhaps the UI
of a KCM "button shortcuts" module would be better done with checkboxes
for the "held buttons", and a picklist for primary button Click versus
DoubleClick - because the number of alternatives is now very, very
large. Showing actual alternatives via checkbox and picklist, rather
than inviting the user to "Click or Double-Click in the box, with
various other buttons and modifier keys held simultaneously"?


Please note that such "shortcuts' will be probably not be recognized as
as "MouseSequences" or "MouseShortcuts" in Qt itself - because there are
no focus-related problems which make a low-level stack of new Classes
necessary. (Pointer Events are automatically propagated upwards and
"back", and I imagine that this can be done in at the top level of the
GUI ... the QMainWindow object checking mouse event signatures against
certain a list of "current Shortcut signatures", resulting in Signals to
invoke the corresponding behavior.)

I don't know how KDE shortcuts actually work, so that last bit is only a
guess. But I think that the entire feature implementation should begin
from an attempt to create some HIG for these "higher" mouse buttons and
multi-button combinations. How do we create such a mini-project?

Thanks for reading.
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]