Difference between revisions of "KWin/Screen Edges"

Jump to: navigation, search
(Update to current situation in KWin)
Line 11: Line 11:
 
* KWin would then manage a collection of reservations for entire or partial sides; as long as there is at least one reservation for a given side, that border is activated. When the pointer moves into the area (or that area is otherwise triggered, e.g. by a keyboard shortcut?), then all reservations that span the entire area or which contain the location due to their offset/length will get notified.
 
* KWin would then manage a collection of reservations for entire or partial sides; as long as there is at least one reservation for a given side, that border is activated. When the pointer moves into the area (or that area is otherwise triggered, e.g. by a keyboard shortcut?), then all reservations that span the entire area or which contain the location due to their offset/length will get notified.
 
* Two glows (separated by color?) would be offered on mouse proximity. One for windows with edge triggers, and one for effects. This glow would become part of the KWin effects stack and use an input window.
 
* Two glows (separated by color?) would be offered on mouse proximity. One for windows with edge triggers, and one for effects. This glow would become part of the KWin effects stack and use an input window.
* Window reservations should not be triggered even on full screen applications; in fact, it may be worthwhile to _not_ raise the input only windows over full screen apps if only window reservations are made for that edge.
+
* Window reservations should not be triggered on full screen applications; in fact, it may be worthwhile to _not_ raise the input only windows over full screen apps if only window reservations are made for that edge.
 
* When a window reservation is triggered, KWin should set an XAtom on the window notifying it of such. Windows would remain responsible for their own actions, however, as KWin can not know what specific action to take or if the application needs to do some preparation before taking action (e.g. loading content in a window prior to displaying it).
 
* When a window reservation is triggered, KWin should set an XAtom on the window notifying it of such. Windows would remain responsible for their own actions, however, as KWin can not know what specific action to take or if the application needs to do some preparation before taking action (e.g. loading content in a window prior to displaying it).
 +
 +
== Implementation ==
 +
=== Visual Feedback ===
 +
* Add an approach window to each screen edge which is click through and only reacts on enter and leave events
 +
* When the approach window is entered a KWin effect is informed about the enter event (startScreenEdgeApproaching)
 +
* The effect enables mouse polling and renders the appropriate overlay
 +
* When the screen edge is triggered the effect stopps the rendering
 +
* When the approach window is left the effect is informed and stops the rendering (stopScreenEdgeApproaching)
 +
 +
=== Window Communication ===
 +
TODO

Revision as of 10:42, 16 June 2012

KWin's screen edge handling is defined in KWin::ScreenEdge (screenedge.(h|cpp)). There are through the enum ElectricBorder (kwinglobals.h) eight borders defined: one for each side and one for each corner.

The electric borders are windows kept above all other windows. KWin watches for EnterNotify and ClientMessage XEvents on the electric border windows in the global event handler Workspace::workspaceEvent (events.cpp:228) which calls Workspace::electricBorderEvent (workspace.cpp:2621). EnterNotify is used to test whether the mouse entered a border, ClientMessage is used for the D&D case, though this is mostly broken (e.g. using D&D to Present Windows does not work/crashes the application you drag from).

ElectricBorders need to be reserved and unreserved. This can be done from a KWin Effect or KWin Script, though it does not have any information about which KWin effect reserves the border. Several effects could reserve the border. Some electric borders are reserved cause of some settings to e.g. lock screen or activate dashboard.

Seigo's Proposal

  • Setting a ElectricBorder XAtom on a window would cause KWin to register a watch on the requests area for that window. When the window clears the atom or the window is deleted, then the area is unregistered. These would be called "window reservations" (as opposed to "effects" or "internal" reservations).
  • The ElectricBorder XAtom should consist of a screen #, a screen location (specific edge or corner), optional offset and length (except for corners, for which this is meaningless)
  • KWin would then manage a collection of reservations for entire or partial sides; as long as there is at least one reservation for a given side, that border is activated. When the pointer moves into the area (or that area is otherwise triggered, e.g. by a keyboard shortcut?), then all reservations that span the entire area or which contain the location due to their offset/length will get notified.
  • Two glows (separated by color?) would be offered on mouse proximity. One for windows with edge triggers, and one for effects. This glow would become part of the KWin effects stack and use an input window.
  • Window reservations should not be triggered on full screen applications; in fact, it may be worthwhile to _not_ raise the input only windows over full screen apps if only window reservations are made for that edge.
  • When a window reservation is triggered, KWin should set an XAtom on the window notifying it of such. Windows would remain responsible for their own actions, however, as KWin can not know what specific action to take or if the application needs to do some preparation before taking action (e.g. loading content in a window prior to displaying it).

Implementation

Visual Feedback

  • Add an approach window to each screen edge which is click through and only reacts on enter and leave events
  • When the approach window is entered a KWin effect is informed about the enter event (startScreenEdgeApproaching)
  • The effect enables mouse polling and renders the appropriate overlay
  • When the screen edge is triggered the effect stopps the rendering
  • When the approach window is left the effect is informed and stops the rendering (stopScreenEdgeApproaching)

Window Communication

TODO


Content is available under Creative Commons License SA 4.0 unless otherwise noted.