Bug 305758

Martin, should we just use the same old "WheelUp/WheelDown" for this, or maybe consider implementing Tilt support in KWin's KCM and events at the same time?

Or do both features, separate updates and bugs (this seems best to me).

I have no idea what tilt support is, but what I wanted is just another value 
with the correct slot in useractions.cpp

Martin, thanks for pointing me in the right direction!

Tilt-wheel support shall be a different Wishlist bug: Tilt-Wheel (X11 buttons #6 and #7, AKA "ScrollLeft" and "ScrollRight"), and support for BackButton and ForwardButton (X11 Buttons 8 and 9), is already available in Qt4.

But- it should be added in a manner which can easily extend to at least 16 buttons, plus the four directions of wheel scroll. The X11 "mouse" driver can support up to 31 buttons, and Qt5 defines them all -- but "mouse" is legacy, and the kernel evdev module seems capable of only 16 + 4. (Remember- wheel events are separated from the X11 "emulate as buttons" scheme in XCB, Wayland, and etc.).

I will work on this one first, of course. I have a LOT to learn about coding, and KDE design in general.

I just tried to implement this feature and realized that mouse wheeling windows to another activity is semantically wrong. Therefore: WONTFIX.

(In reply to comment #4)
> I just tried to implement this feature and realized that mouse wheeling
> windows to another activity is semantically wrong. Therefore: WONTFIX.

Martin, could you please explain, how this feature is wrong? I still think for people using activities and no vitrual desktops it would be quite a killer-feature... Thanks!

On Saturday 25 May 2013 14:40:13 you wrote:
> > I just tried to implement this feature and realized that mouse wheeling
> > windows to another activity is semantically wrong. Therefore: WONTFIX.
> 
> Martin, could you please explain, how this feature is wrong? I still think
> for people using activities and no vitrual desktops it would be quite a
> killer-feature... Thanks!
Virtual Desktops are a next/previous thing and a window is exactly on one 
virtual desktop. Activities are considered that a window can be on more than 
one. And here comes the problem: what's the next activity if a window is on 
e.g. all activities or on more than one activity?

Bjorn, can you explain to me (please) why a person would choose to run multiple Activites concurrently? Desktops I understand, and use as follows:

email is initially assigned to desktop 1
FF is initially assigned to desktop 2
Konversation is always on dekstop 6
Dolphin instances are initially assigned to Desktop 7 ... and so on.

But multiple Activities, on a Desktop device, I actually DON'T understand.

(In reply to comment #7)
> Bjorn, can you explain to me (please) why a person would choose to run
> multiple Activites concurrently? Desktops I understand, and use as follows:
> 
> email is initially assigned to desktop 1
> FF is initially assigned to desktop 2
> Konversation is always on dekstop 6
> Dolphin instances are initially assigned to Desktop 7 ... and so on.
> 
> But multiple Activities, on a Desktop device, I actually DON'T understand.

That's easy: An activity saves a working environment, e.g. files, folders, webpages etc. you need for doing one task. When you interrupt this activity, you can simply start it at exactly the same point again later on. Additionally, you can do changes to e.g. powersettings. So one of my favourite activities is the media activity, which does not turn of my screen so fast.

But to be honest: you still have to be quite enthusiastic to use activities, as there is noone actually polishing them. I still hope for work coming back from plasma active to the desktop though :)

(In reply to comment #6)

> Virtual Desktops are a next/previous thing and a window is exactly on one 
> virtual desktop. Activities are considered that a window can be on more than 
> one. And here comes the problem: what's the next activity if a window is on 
> e.g. all activities or on more than one activity?

Thanks, Martin! I actually think that it is a very rare case that the same window is used on different activities (currently it is possible though, I agree). So to solve the problems you mention, i could think of:

- When a window is on all activities, simply switch activities, when this action is done.
- When a window is on some activities, do not duplicate it, when it gets sent to a window where it already is, but if it gets (directly) sent to the next activity, simply leave the existing one where it is. To explain:

We have 4 activities: A, B, C, D
We have the same window on activity A and C

Now we move Window from A once - now the window is on B and C. We move it again once - now it is only on C. We move it again - now it is only on D.

Different situation: Window is on B and C and we move it reasonably fast twice. Now it is on C and D.

Perhaps we could discuss this in the Usability group as well - there might even be some better ideas?!?

I would still ove to see this - as far as I consider it - major improvement to activities!

> Now we move Window from A once - now the window is on B and C. We move it
> again once - now it is only on C. We move it again - now it is only on D.
The problem is that if it moved once the window is gone. One would have to 
switch the activity then to move again. That's why it just doesn't fit to mouse 
wheel on window decoration.

(In reply to comment #10)
> > Now we move Window from A once - now the window is on B and C. We move it
> > again once - now it is only on C. We move it again - now it is only on D.
> The problem is that if it moved once the window is gone. One would have to 
> switch the activity then to move again. That's why it just doesn't fit to
> mouse 
> wheel on window decoration.

Ah, ok. How about moving the window to next activity with mouse wheel and moving a copy of it, when using e.g. shift-mouse-wheel?

> Ah, ok. How about moving the window to next activity with mouse wheel and
> moving a copy of it, when using e.g. shift-mouse-wheel?
We don't have "copies" of windows and we don't support modifiers for window 
decoration mouse actions. While it would be possible to add support for 
modifiers it would be rather complex. Thinking about it impossible in the KDE 
4.x timeline.

I'm unsure about "clone" versus "move", and imagine that the feature needs both. Adding yet another "mouse shortcut" signature.) And I'm unsure about Application-level conflicts: Ctrl+Wheel Up/Wheel Down is widely used for zoom-in, zoom-out; is there perhaps a similar "UI Guideline" which already consumes Shift+ Wheel?

I agree with Martin's opinion regarding use of a Modifier Key within Kwin, it would be unique.

My own preference is to implement "Button + Modifier Key Support" together, with "held+clicked" and "held+double-clicked" mouse "Shortcuts and Actions" (footnote 1) at the same time. (And BTW, multiple "held buttons" would be possible.) I feel that this would be appropriate for a later (not first-out) Version of KF5-based Plasma and KWin. The entire UI of such "Mouse Shortcuts" settings module(s) would need  careful design, such that Applications (and not just KWin+Activites) can define them, re-define them, Signal such re-definitions, search for conflicts, ... and etc.

The biggest difference between modifiers alone and multiple held buttons (with or without modifiers) is a18n: a one handed person cannot handle keyboard AND mouse at the same time.
- - - - -
(1) "Shortcuts and Actions", of course, do not correspond to Qt Shortcuts and Actions - The Qt classes take only keyboard events (i.e., occurences of QKeySequence match). KWin currently inspects for a few mouse events explicitly - but a KF5-based design should provide for sharing among 'Application Level' mouse shortcuts as well.

Thanks for clarification. Perhaps we can have a little chat about this issue during Akademy. I would really like to see activities become more usable and this whole issue is one important part of it - so finding a reasonable solution would be of great value.