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

List:       kwin
Subject:    Re: KWin Rules documentation
From:       Thomas =?UTF-8?B?TMO8Ymtpbmc=?= <thomas.luebking () gmail ! com>
Date:       2011-09-24 18:27:30
Message-ID: 20110924202730.28814cf4 () gmail ! com
[Download RAW message or body]

Am Fri, 23 Sep 2011 22:08:47 -0400
schrieb Pablo Sanchez <pablo@blueoakdb.com>:

> Window Rules
> ============
> [...]
> Rules can be created to affect different
> sets of pop-ups within the same application.
a pop-up is probably seen as a popup aka QMenu (used to be QPopupMenu
in Qt3)
Those "popups" are not managed by kwin and not covered by the rules.
The general term would be "window" and kwin internally calls them
"clients"

> Rule Evaluation
> ---------------
> @Q:  In the `Configure - KDE Control Module' window, we are presented
>      with `Window Rules'  Reading the current `Help' (Revision KDE 4.5
>      2010-05-31), it states that rule order does not affect rule
>      evaluation. 
Plain wrong. First match evaluation (ie. if there's a matching rule that
forces windows eg. non-closable and a matching rule before (above in
the GUI) thas forces a window to be closable, it will be)

The move-up / move-down buttons are not pointless ;-)

>      Does this mean that for each window, on creation, each rule is
>      considered and only those rules which match are applied?
That is however correct. All rules are considered for every window. We
do not simply stop when we find a matching one but only if it has an
opinion about the relevant setting. (when kwin wants to know about a
size it steps across all rules until it finds a matching rule the does
say "use this geometry", otherwise behaves generic)

>      How do we handle rule conflicts? [...]
>      window has a geometry of 100x100 and the other rule has an
>      attribute of 25x25), which rule `wins'?
The upper one.

> Activating Rules
> ----------------
> Typically, when matching an application, the application must be
> restarted before rules take into effect.
No. This heavily depends on the particular rule.
Partially bugs, feel free to file them ;-)
Partially event driven adaption. (eg. In/Active opacity is applied when
the window is de/activated) 
And of course depends on the rule nature - oc. for "apply
initially" the window must show up, but not for eg. "force".
But since kwin manages windows and not processes, you should *never*
have to restart the application, re-showing (not unminimizing) the
window should always be enough.

> Window Matching
> ===============
> [...]
> Thus, identification can be specified in liberal terms to affect many
it's also possible to have a "blind" rule that applies to _all_
windows, iirc you'll however get a warning when doing so.

> Use the `0s delay' to identify windows which momentarily pop-up and
> when your mouse moves away, the pop-up disappears.  (I'm sorta making
> this Use Case up ... how wrong am I?  :)
Totally ;-)
When you click the detect button the cursor becomes a cross and you can
use it to pick an arbitrary client in sight.
The delay was added to be able to be able to trigger another window
afterwards (in particular: the firefox flash plugin - there's some
nasty issue about focus stealing with it)

> Regular Expression - `pablo, digest link provided by Thomas :)'
> ++++++++++++++++++
> To free you up, I'll look for some links and once we get the
> documentation set up, you'll have final say (like the Romans!  Thumbs
> up or down) on the link(s).  :)
I think it would be more important to have an idea about the general
use case and user of rules.
After all, writing a regexp if you've no idea about "a regular what???"
would be a major barrier (if required) while experienced egrep users
likely won't bother with that "click, drag, find, missed it" thing ;-)

However the editor seems unmaintained:
http://websvn.kde.org/trunk/playground/utils/kregexpeditor/


> Manual Rule Creation
> --------------------
> @Q:  When not using the `Detect Window Properties', how does one go
>      about entering criteria for the different `Window types:'?  I
>      wasn't able to do so.  Is this feature still in the works?
Bug, -just some missing signal/slot connections-  fixed in 4.7.2
(but i'm quite sure i didn't introduce that so there's been a looong
time w/o it being an issue ;-)

>      @Q:  I'm unclear on this option.  When I use `Konsole' as an
>           example, if I select `Use window class (whole application)',
>           I get `Konsole' for `Window class (application)'  
> 
>           On the other hand, if I use this option, I get `Konsole
>           (konsole Konsole)' instead as the value.  There's something
>           obviously important about the `(konsole Konsole)'
> portion.  :)
Ok, to be frank i just /really/ looked at this for the very first time
- it's extremely confusing.

1st: the ICCCM spec has several "wm_class" fields eg. FF has
'"Navigator", "Firefox"'
2nd: the radio list is just confusing.
   a) "special window" ./. "whole application" just brings in the window
type. Putting that in brackets seems a stupid idea because it's
orthogonal to the other option
   b) aside this you can pick the dominant class, all class fields or
   the dominant class and the window role - and the window title
=> needs some clarification in the UI


> @Q:  I don't understand the difference between an `Exact match' for
>      `Window class' and matching the /whole/ `Window class' 
match only one or all class fields - affects the lineedit as well as
the checkbox (see below)


> The labels are:
> 
>    Window class (application)  Exact Match ___________
>                         x Match whole window class
> 
> and I think the names are confusing me.  Not that I can offer a
> different label name, I just don't have a good understanding of the
> difference between the two.  :)
determines whether the string above reflects all class fields or just
one. Example:
Firefox sets two class entries "Navigator" and "Firefox", "Firefox" is
the "dominant" one.
Suppose you need to match both classes because some database chose to
rename from "Firebird" to "Firefox", the string in the lineedit will be
"Navigator Firefox"
Now if you uncheck the box only the "dominant" filed is matched (and
mails because it's "Firefox" and not "Navigator Firefox"

Maybe "whole window class" (i didn't pick) should be "all WM_CLASS
fields" but that's of course extremely "techy"

> Window role
> +++++++++++
> A specific instance of a Class.
No. Or maybe yes and your example is just bad ;-)
WM_WINDOW_ROLE is an *optional* "free" field in ICCCM to identify a
special window. FF (i'm just using it as non Qt lookup instance ;-) has
eg "browser" for the actual browser, "Manager" for the download manager
etc.
It's a more general match than the possibly varying or translated title
but one can really write there whatever you feel like.

>   @Q:  Do we have any examples of extra role values?  
"No", sidearm free field. Not seen used myself.
Looking up kwin it's not even implemented in the rules and i've no idea
what it's supposed to match. Could be part of some netwm dead end -
we'd have to ask Lubos - iff he can recall ;-)

> Do Not Affect
> +++++++++++++
> Functionally equivalent to not selecting the option.  Possibly
> available for backwards compatability.
Hehe - thinking about it: it's obviously to clear the setting for a
more specific match (application: in general not maximizable, but that
one window shall please be -> scratch that setting)

So it actually /does/ make sense. Just a bit confusing in the first and
only superfluous in the flat case.

> Apply Initially
> +++++++++++++++
> The application starts with this setting initially.  The end-user can
> override this setting.
"Setting remains changeable at runtime" - also by the application.
 
> Force
> +++++
> The attribute never be changed by the end-user nor the application.
> Potential use for this setting is in a kiosk environment.
lacks a "can" - no idea about kiosk acceptance but it's mostly relevant
to fix client bugs. (since this is the basic "i know better" override
key)

> Apply Now
> +++++++++
> This is an ephemeral setting.  It's only applied during the rule
> creation and /never/ re-applied.
Well, whenver the apply button is clicked - but i don't know whether
the rule is kept when added by the popup and has only such setting.
> 
> Author has discovered useful to during rule creation to `undo' an
> attribute.  :)
That's a valid usecase =)

> Yes/No
> ++++++
>      However, it didn't make a
>      difference when I set it for `Maximized horizontally' - the
>      window was always maximized horizontally.  Is this a possible
>      software defect?
sounds like a bug but works perfectly alongside "force" (window is
either always max'd hor' or cannot be ma'd hor' at all here)

> Force/Force Temporarily
> +++++++++++++++++++++++
> @Q:  To confirm, these two options, when only presented, are the same
>      as when presented above eh?  That is, when they're the only two
>      options, there's nothing special about them.
Yes, it only means that the other options are not implemented (maybe
because not considered useful/important)

> The lower left corner of your display is `0,0'
NO!
Qt != OpenGL - we start in the upper left =)

> To obtain a window's current placement, you can use `xwininfo' or
> configure KDE to display window geometry when moving or resizing:
The current geometry appears in those fields and is
updated with detection.
 
> Maximized horizontal
> ++++++++++++++++++++
> The window is started with a maximum horizontal size.  The window
                    ^^^^^^^
"force" will actuall fixate that (and all other) flag(s).

> Minimized
> +++++++++
> Start the window minimized.  This may be used for misbehaving error
> dialog boxes:  ignore them.
it's esp. useful to *prevent* buggy windows from starting minimized...
 
> Ignore requested geometry
> +++++++++++++++++++++++++
> @Q:  How is setting this attribute to `Force' different than setting
>      `Size' to `Force'? 
The geometry request is done by some clients and usually honored. The
placement strategy is that skipped and the window placed exactly where
it asked to be.

> Minimum size
> ++++++++++++
> The minimum width and height allowed for the window.
> 
> Maximum size
> ++++++++++++
> The maximum width and height allowed for the window.
> 
> Obey geometry restrictions
> ++++++++++++++++++++++++++
> @Q:  I'm unclear on this setting
Next to min & max size there's aspect ratio and baseincrement - this is
handled here.
The aspect ratio is eg. used by mplayer to match the video while the
gtk+ terminals as well as xterm use the base increment value (so they
can only grow by 1em in either direction)
Since this naturally prevents certain geometries (like eg. the exact
desktop size) it can be overridden here.
One should however be (slightly) careful - i cannot recall which one it
was, but I've once crashed a client in a SIGFPE (math error) by this
because it apparently relied on dimensions being multiples on specific
numbers.

For a general string change session i'd possibly bring in the aspect but
don't know how to sell the "base increment"

> Arrangement & Access
> --------------------
> 
> Keep above
> ++++++++++
> Window is started above all other windows.
                 ^^^^^^ see above

> Autogroup with identical
> ++++++++++++++++++++++++
> @Q:  I understand the term autogroup but I'm not clear how it's used
>      in this context.  :o
> 
>      How is `identical' determined?  By Window Class?
Yes - likely. I've few insight and little interest in the tabbing
code ;-P
Anything else would however make no sense to me.

> Autogroup in foreground
> ++++++++++++++++++++++++
> @Q:  Would autogroup'ing typically happen in the background?  Are
>      there any visual queues for the end-user when autogroup'ing is in
>      effect?
I guess by default the just stacked in client isn't selected - but i'd
have to look up the code myself.

> Autogruop by ID
> +++++++++++++++
> @Q:  How would one determine the `ID' value to enter?
See above, i have _no_ idea.
(The tabbing thing has been a diminished great experience with GSoC -
*sigh*)

> Tiling
> ++++++
> @Q:  I created a rule with only tiling set for `konsole' and I
>      couldn't tell the difference between `tiled' and `floating'
Do you use window tiling at all?
By this you should be able to prevent windows from entering the tile.
Never used myself, though.

> New windows can be set to start `tiled' (`kwin' will look for space on
> your desktop and fit the windows accordingly) or 
No. Tiling is orthogonal to normal placement strategies ... as well as
to tabbing it seems. *sigh* again.

> Shortcut
> ++++++++
> @Q:  Is this a keyboard shortcut to close/open/? the application.  How
>      are control/escape/? sequences entered.  :)
No, to activate it - seems the "edit" buttons got broken in the past
(there's even one for regexps as well) - this may even have happened at
the 3/4 break.
=> there needs to be a shortcut button just like in the alt+f3 dialog

> Moving/Resizing
> +++++++++++++++
> When the window is being moved/resized, should we make it `opaque' or
> `transparent'
> 
> @Q:  What opacity value do we use?  Empirically, I believe it's the
>      `active' value but I thought I'd ask.
This is meanwhile outdated because transparent move/resize has been
removed by Martin.
This is not about compositing etc. but whether the window or just an
empty frame is shown at this time.

> Accept focus
> ++++++++++++
> When set and `Yes' is selected, focus switches to the newly created
> window.  When `No' is selected, focus is disabled; any attempt at
> input will be discarded.
sidenote: the application can still set the focus to the window. Just
clicking it won't implicitly and if the application doesn't support it,
there's no way to get the keyboard focus on that window.

> Ignore global shortcuts
> +++++++++++++++++++++++
> Any global shortcuts which would normally affect this window are
> ignored. 
No. Means: As long as the window has the focus, global shortcuts will
still be delivered there instead to the system.

Makes eg. sense with emulators. Eg. SheepShaver (Apple emulator) maps
"alt" to "cmd", since alt is *the* WM modifier and cmd is a "pretty"
important button in MacOS it's a good idea to prevent global shortcuts
so you can still use the cmd key in SheepShaver for all kinds of
actions.
 
> Closeable
> +++++++++
> Determines whether to display a `close' option for the window.  If
> `No' is checked, no `close' option is displayed.
It also prevents closing by alt+f4 or the alt+f3 popup.

> Window type
> +++++++++++
> For older applications, force the window type to obtain those
> attributes.  For example, you can make any window treated as
> `Utility Type' - it will hide with its parent
yeah, my bad - unsharp expression ;-)
utility windows are by default (kwin option) hidden when it's parent
looses the focus.

> Block compositing
> +++++++++++++++++
> @Q:  I'm unclear on this attribute.
As long as this window is present, the compositor ("desktop effects") is
turned off for eg. better performance.

> Examples
> ========
> @Q:  Is there a way to specify a rule so a Window always pops up to
>      the top (similar to `Keep Above Others')?
No. There's no stacking rule at all.
You could perhaps achieve that with a combo of focus stealing & accept
focus (the stacking is often bound to the focus, setting that policy to
"none" while preventing the window from actually getting the focus
might do what you want)

> Examples
> o VirtualBox VM - do not raise window when clicking a window within
>   the VM.
could become hard, the raise happens alongside the click and there's no
rule for window clicking behaviour either. You'd have to keep it
above... ("kcmshell4 kwinoptions", "window actions" tab)

Cheers,
Thomas
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]