[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-29 21:06:34
Message-ID: 20110929230634.7abf6d38 () gmail ! com
[Download RAW message or body]

Am Thu, 29 Sep 2011 15:05:12 -0400
schrieb Pablo Sanchez <pablo@blueoakdb.com>:

>    Rules are evaluated in the order listed in the GUI.  Many rules may
>    match a particular window.  The first matching rule, for a given
>    window attribute, takes precedence over subsequent rules.
> 
>    For example, if `rule #3' sets the `Size' for a window and
>    `rule #5' would also set the `Size', `rule #3' is used.
Correct.
 
> btw, has there been any performance tests done?
I don't think so, but don't know.
Meditating about it - most rules affect cold functions (ie. walking
across 100 items is no big deal for today (or even yesterday) CPUs when
eg. a window is activated)
The only rules affecting "hot" functions are the geometry related
(min/max/size, position, etc.)
However, as long as they're not set in a rule the rule's just stepped
over (even no matching is tried)
So the only critical occasion would be a long list of rules, all
affecting the geometry and the last one hits your window. In that case
you'd certainly notice some higher CPU usage when moving/resizing
windows.

> we know the story about maximum memory on a computer.  :)
=)

This is however a little different since the human would turn out to be
the limiting factor managing all those rules.
And CPUs would naturally become faster as well.

> > Partially bugs, feel free to file them ;-)
> 
> Will do!
Err... not here, please. More like on bugs.kde.org ;-)

> Looks like 4.7.1 fixed a KOrganizer bug I'd have filed.
in case, don't forget to close it if it's not already.

> I agree with you.  As I see it, I can see RE's being employed for
> generic rule writing.
Yes, this way you can perhaps shorten 100 rules to one ;-) 
For the casual "fix-a-buggy-client" usage, they're rather not required.

> @Q:  It just occurred to me that I failed to ask about the `Edit'
>      buttons.  I'm not sure what they do and when they're `on' - not
>      greyed out.
regexp editor - doesn't work.
There's a pending review request that will hide them (until we some day
have a regexp editor - or remove them entirely) 
http://git.reviewboard.kde.org/r/102711/

> I'm thinking to myself that perhaps this section shouldn't be too
> detailed.  I'm going to assume (incorrectly?) that a GUI developer
> understands `Window class', `Window roles', etc.
Unlikely, but you could refer to the icccm spec:
http://tronche.com/gui/x/icccm/sec-4.html (class)
http://tronche.com/gui/x/icccm/sec-5.html (role)

Also the rules do not target developers but end users.
To my experience they usually fail to understand the concept of a
window manager (and so did i ... quite some years ago ;-)

> For mere mortals like myself, we'll more than likely only use `Detect
> Window Properties' to backfill the `Window matching' parameters and
> potentially do some minor tweaking of values.
Ultimately - yes. But you'll still require an idea about the scope of
the match ("how precise" and "precise by what")
But of course one should not come with "window class" and "window role"
because that has no meaning to the end user.
=> The confusing dialog after the detection needs a lot of love (best
for 4.8)
 
> Perhaps the label shouldn't be `Do Not Affect' but something like
> `Default Behavior' or `Reset to Default' 
Sounds reasonable to me. The current string derives out of the internal
value, where "if (DontAffect) skip();" of course makes sense.

> The reason I mentioned a Kiosk environment is I can envision a kiosk
> with only a browswer.  We want the browser to always be on top and
> fullscreen.
-> you don't want to run a window manager in this case at all ;-)
 
> It appears `Apply Now' only works the one-time:  when created.
> Subsequent new windows do not get the attribute set.  I tested using
> my best friend:  Konsole.  :)
Yes, but what i meant (and just confirmed by testing) is that this mode
acts as extension to the alt+f3 menu.
So if you call "special window setting" from the window menu, set "keep
above" to "apply now" and "yes", the apply the rule, the window is set
keepAbove BUT no new rule is created or shows up in the list - different
from when eg. selecting "force"

=> value makes sense as well.

> As an aside:  I think `Maximized horizontally' is broken because
> `Apply Now' doesn't affect an existing (`Konsole') window however
> using `Apply Now' with `Size' does affect the Window.
You mentioned such before, but it works here - this way or by a forcing
rule.
Does it work with other clients?

> Is it possible to use the antonym for the attribute?
Name them for "fullscreen", or "autogroup in foreground" - make a
mockup ;-)
You'd definitly loose structure

> For example:
> 
>      Radio button           Action:  (e.g. Force, etc)
>      ---------------     -----------------------------
>       v           v
>    Minimized Maximized   ___________
> 
> I'm not certain which attributes would qualify.  
a) Would possibly become a little messy?!
b) "Minimized" may be the antonym (i'm no native english speaker) of
maximized, but not what the checkbox means and certain no equivalent to
"yes/no" ;-)

> Some like `Fullscreen' do not have a proper antonym but `Not' would
> work:
aha.
 
>     x Not Fullscreen  Force 
>     =====
> 
> If `Not' is not checked, it remains greyed out.
The problem here is visually:
[ ] Not [ ] Fullscreen   (Force)

Also I actually wanted to do such with the last revamp, but it turned
out to become quite ugly to code and ... a visual mess ;-)

Also it may not work in all languages this way (don't think of german
or latin ones but rather asian etc. - where i would not even know about
such pitfalls) - even in english you'd require a "Do not" for verbs
("Keep above") - or turn the verbs into adjectives.

However, the unexplained checkbox sucked, the yes/no is probably better
but unlikely perfect.

> I tried creating a simple rule with only `Autogroup in foreground >
> Force > Yes' using `xterm's and I couldn't see the rule working.
Describe "couldn't see the rule working", ie. what did you expect that
did not happen?

> By the same token, when I did similar with `Autogruop with identical',
> I saw the tabbing/grouping.
Err, i guess th rule depends on either other autogroup rule being in
use (at least sounds like this)


> > Do you use window tiling at all?
> No, I'm not a fan of tiling.  :)
Then it doesn't have any effect for you.

> So `Floating' is the opposite of `Tiling'?
Yes. "Floating" refers to the usual concept (many windows which can be
freely positioned stacked up and down etc.) while a tiling WM sorts
the windows on one layer filling the screen.

The rule allows you to except windows from being tiled (eg. some
dialogs, calculator, runner, etc.)
 
> Is this a GSoC *sigh*?
GSoC is "googles summer of code".

> I'm hoping I'm not asking too many dumb questions.
Nope, this kind of interview resulting in a documentation is actually
probably some kind of really good idea.

> > > 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
> 
> Yes, the `edit' button does nothing for me.
Will do with the patch mentioned above, unfortunately not in 4.7.2

> In my particular case, I have focus-follows-mouse set, focus stealing
> set to `Low' and `Click raises active window' unchecked.
You should definitely point stress that because FFM is not too common
these days,

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]