Subject: conditional styles

From: Dominik Vogt <[email-masked]>
Date: Tue, 18 Dec 2001 14:54:23 +0100

In my eyes, implementing contitional styles breaks up into three
things: features, performance and design of the code.  Here are my
thoughts.

 1) Possible features

     - Regular expression matching in styles.
     - Tell fvwm to only match by name or by icon name or by
       resource or by class.
     - Styles tied to window ids (some kind of enhanced window
       state); destroy when the window dies.
     - Styles depending on window state, e.g. styles that are
       applied to maximized or sicky windows.  This offers much
       more flexibility for individual windows.
     - ...

 2) Performance

     - State dependent styles may cause serious performance
       problems since the window's style has to be checked
       whenever its state changes.  Perhaps it's possible to give
       each window a flags structure that marks which states do
       not use the default style?

 3) Design of the code

     - Clean and easy to understand.  I'd prefer to keep only a
       single list of styles.
     - There must be some way to find out which parts of the
       window style have to be changed when the window state
       changes.  Otherwise, state changes would become visually
       unpleasant (the whole window is redecorated).

Any comments, more features, states, etc.?

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked]
Date: Tue, 18 Dec 2001 09:20:00 -0500 (EST)

> things: features, performance and design of the code.  Here are my

I made a stab at some sort of syntactical suggestion for this kind of
feature right after 2.4 was released (ie, when fvwm2 was no longer in
"feature freeze").  In fact, I had started writing some code to
implement it.

I received zero responses from my message (sent on 7-Aug-2001), so I
figured that there was no interest in this at the current time, so I
abandoned the work that I had started.

I hope Dominick fares better.

In case you were wondering, I include my original message below.

> Date: Tue, 7 Aug 2001 08:24:15 -0400 (EDT)
> From: Larry Gensch <[email-masked]>
> Reply-To: Larry Gensch <[email-masked]>
> Subject: While we are discussing new features...!
> To: fvwm-workers <[email-masked]>
> MIME-Version: 1.0
> Content-Type: TEXT/plain; charset=us-ascii
> X-Status: 
> X-Keywords:                 
> Status: RO

> I've had a desire for some time for an improved syntax for matching
> windows using the Style, Next, Current, etc. commands.

> Right now, I can say:

> 	Next ("xterm") Focus

> I can even use wildcards:

> 	Next ("*term*") Focus

> This is all well and good when your terminal windows all have "term"
> somewhere in their name/iconname/class/resource.

> However, I have a few applications that give terminal windows:

> 	Powershell
> 	Konsole
> 	xterm
> 	gnome-terminal

> There isn't one wildcard expression that will capture all of those.

> Add to this the ability of some applications to change their window
> title due to state (xterm has an escape sequence that most terminal
> windows accept, Netscape is another application that comes to mind
> that does this), and it gets difficult to map a "hot key" that will
> traverse through a related set of windows.

> Do you think it might be a good time now to add some functionality to
> the window matching feature to allow for alternates and/or more
> specific matching?

> My thought is that we could create "conditions" in a way similar to
> that of Functions, Menus, Decors, etc:

> 	DestroyCondition	"ConditionName"
> 	AddToCondition		"ConditionName"
> 	+	ConditionTerm	ConditionPhrase
> 	+	ConditionTerm	ConditionPhrase

> Each condition line is parsed one at a time.  At first, the condition
> will select no windows, and each successive line will narrow or widen
> the windows selected.

> ConditionTerm may be:

>     All			Select all windows

>     Widen Term		Add to the selected windows those that match
> 			the Term (boolean OR)

>     Narrow Term		Restrict the currently selected windows to
> 			those that match the ConditionPhrase (boolean
> 			AND)

> Term may be one of the following:

>     WindowName="xxx"	Wildcard match on window name
>     IconName="xxx"	Wildcard match on icon name
>     Resource="xxx"	Wildcard match on resource name
>     Class="xxx"		Wildcard match on window class
>     Match="xxx"		Wildcard match on title, icon, resource, or class

>     CirculateHit	Override CirculateSkip Style attribute
>     CirculateHitIcon	Override CirculateSkipIcon Style attribute
>     CirculateHitShaded	Override CirculateSkipshaded Style attribute
>     CurrentDesk		All windows on current desktop
>     CurrentPage		All windows on current page and desktop
>     CurrentPageAnyDesk	All windows on current page on any desktop
>     Iconic		All windows that are iconified
>     Layer[=n]		All windows on layer "n" (defaults to layer of 
>     			currently focused window)
>     Maximized		All maximized windows
>     PlacedByButton3	True if last interative move ended with button 3
>     Raised		All windows that are raised
>     Shaded		All shaded windows
>     Sticky		All sticky windows
>     Transient		All transient windows
>     Visible		All windows that are visible

> Any Term can be negated by prefixing with "!":

>     + Narrow	!WindowName="*Netscape*"

> This would narrow the selection to windows that do NOT have "Netscape"
> within their window names.

> The Syntax to use these conditions could be something like:

>     DestroyCondition "Terminal"
>     AddToCondition	"Terminal"
>     +		Widen	Resource="XTerm"		# xterm
>     +		Widen	Resource="Powershell"		# powershell
>     +		Widen	Resource="Konsole"		# konsole
>     +		Widen	Resource="Terminal"		# gnome-terminal

>     DestroyFunc	"CycleTerminals"
>     AddToFunc	"CycleTerminals" \
>       "I"	Next (Condition=Terminal)	Focus
>     + "I"	None (Condition=Terminal)	Exec powershell

> This example would cycle through all my terminal windows or, if no
> terminal window was found, would spawn a new powershell.

>     DestroyFunc	"IconifyTerminals"
>     AddToFunc	"IconifyTerminals" \
>       "I"	All (Condition=Terminal)	Iconify 1

> This example also seems to be able to produce the If/Then/Else logic
> that has been discussed on this list (although there may be hidden
> caveats here!).

> Not only is this useful for cycling through windows, but it can be
> used to group Style attributes to a common set of windows:

>     Style Condition=Terminal	some-special-styles-for-term-windows

> I've been sitting on this idea for a while (ever since 2.3 was
> originally announced to be in "feature freeze" quite a while ago), and
> figured that this might be a good time to make this suggestion.

-- 
Larry Gensch                                          [email-masked]

            Working for COMPAQ for over a twentieth of a century

---

From: Tim Phipps <[email-masked]>
Date: Tue, 18 Dec 2001 15:20:15 +0000

Is it time for a rethink of the style system? It seems that the style
command and a few builtin commands manipulate a windows appearance and
behaviour but they don't do a complete job. We could generalize them and
provide a means to do more selective control with some additional commands.

Commands like Stick alter the windows sticky behaviour. Style <pattern>
Sticky does the same thing for a set of windows and also maintains a
list of patterns to apply to newly created windows.

A lot of style types do not have matching builtin commands.

How about a new command: WindowStyle? It would apply to the current
window or could be used as part of a selective command e.g.
WindowStyle Sticky
All (*Buttons*) WindowStyle Layer 5
WindowId ??? WindowStyle Iconic

The simple built-ins like Stick could be aliases e.g.
Stick On = WindowStyle Sticky
Stick Off = WindowStyle Slippery

The Style command could be aliased also e.g.
Style <pattern> ResizeOpaque = All (<pattern>) WindowStyle ResizeOpaque
Style <pattern> <style-args> = All (<pattern>) WindowStyle <style-args>

plus the pattern to apply to new windows could be written as a function
AddToFunc StyleFunction I WindowId $0 (<pattern>) WindowStyle ResizeOpaque

The StyleFunction function would be called with the newly-created
window's id as the first parameter.

Additional style commands would just add to StyleFunction in
a similar way to the way the style list build up. I think we may be able
to remove the style list altogether with this. The only problem being
the DestroyStyle command which would have to selectively remove parts of
StyleFunction! DestroyStyle * would be the same a
DestroyFunc StyleFunction.

Doing this would require moving most of the style parsing code from the
Style command to the new WindowStyle command and rewriting the simple
commands like Stick.

Benefits:
* possible to control every style on a per window basis
* extending the conditions for Next/All also extends the ability to set
   styles e.g.
   `All (class=*Fvwm*) WindowStyle Sticky' is better than `style *Fvwm* 
Sticky'
* possible to obsolete commands like Stick in the future
* Larrys suggestion for conditions would work with this e.g.
   `Style (Condition=Terminal) Colorset 2' is aliased to
   `All (Condition=Terminal) WindowStyle Colorset 2'

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Tue, 18 Dec 2001 11:14:32 -0500

> Any comments, more features, states, etc.?

I don't understand the motivation for some of the more elaborate
solutions.

Starting with a simple:

Style [Class=XTerm,Name=dumbo*] ...

would handle 99% of the need.

I don't see how the performance would be any different than
the current wildcard matching to 3 possible names.  I know theres
additional logic, I just don't think it amounts to anything we have
to worry about.  In some cases, there is less matching, I know thats
the way I intend to use it,  Ie. just supply the class as a backup
for my xterms that I don't match by name.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 18 Dec 2001 18:11:19 +0100

> > things: features, performance and design of the code.  Here are my
[snip]
> >        not use the default style?
[snip]
> would handle 99% of the need.

One of the most requested features is to be able to control the
looks of sticky windows.  This could easily be done with something
like this:

  Style [State=Sticky] ...

> the current wildcard matching to 3 possible names.

It's performance critical because the style of a window might
change every time it changes its state.

> I know theres

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 18 Dec 2001 18:15:10 +0100

>    `All (Condition=Terminal) WindowStyle Colorset 2'

I like that idea.  The only thing I can't imagine is:  how can we
begin to implement such a monster of a feature?  Yes, it would
simplify a *lot* of code.  But to me it looks like a much greater
challenge than the infamous GSFR (Great Style Flag Rewrite)
several years ago.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 19 Dec 2001 21:50:23 +0000

On 18 Dec 2001 15:20:15 +0000, Tim Phipps wrote:
[a nice suggestion for WindowStyle command skipped]

> DestroyFunc StyleFunction.

This is not the only problem. Here are related ones.

Currently Style list is always optimized. It is not obvious how to do this
with this new StyleFunction. The function functionality just does not
allow to do everything we may want to do with StyleFunction.

Examples. I want a solution for these two problems.

1) Being able to switch normal icons on and off. Currently the only
solution is to issue "Style * NoIcon" to switch it off and hundreds of
"Style pattern Icon image" to switch them on again. Of course, the
solution to this is to add aditional Style flag HasIcon/NoIcon, so Icon is
stored for a window even it has NoIcon. But you may get the point. If
currently switching icons on and off two times is the same as doing this
10 times (because there is merging), with StyleFunction thousand of
new lines would be added, unless there is a way to optimize a function.
In this case it will not be a function in a normal sence.

2) It would be nice to have a way to do and undo style changes. This may
be useful for Style GUIs with ability to try/cancel style options. Or if
someone wants to enter to some temporary mode, i.e. to remember the way a
window (or windows) start now, apply some changes (say, iconify all new
windows) and then return to the previous state (with only some windows
started iconified). I see two possible solutions to this. First:
StartStyleGroup, EndStyleGroup, DeleteStyleGroup commands and disable
merging with styles inside the group. Second: DumpStyle / RestoreStyle.
In any case, to implement this, more operations over StyleFunction needed.

Just my thoughts.

Regards,
Mikhael.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 21 Dec 2001 12:51:51 +0000

[email-masked] wrote:

 > I like that idea.  The only thing I can't imagine is:  how can we begin
 >  to implement such a monster of a feature?  Yes, it would simplify
 > a *lot* of code.  But to me it looks like a much greater challenge
 > than the infamous GSFR (Great Style Flag Rewrite) several years ago.

Well, the GSFR was a great success! maybe a trial is on order:

* Write a WindowStyle command that just understands Sticky/Slippery,
   copy/paste from the Style command.
* Write a NewStyle command that manipulates the StyleFunction function,
   don't worry about DestroyStyle and optimizing the function yet.
* Write a wrapper for Style that strips out any Sticky/Slippery options
   and passes them to a NewStyle command, Pass the other options to the
   old style command (this may be quite hard and will be thrown away
   later so maybe just a really simple version would be OK e.g. only pass
   to NewStyle if the command is just "Style <pattern> Sticky")
* Add the dynamic update of Sticky/Slipppery to the NewStyle command.

This should result in the Style commands with Sticky/Slippery bahaving
exactly as the old way. If nothing unexpected turns up then we can
proceed as follows:

* Add all the other style flags to the WindowStyle command.
* Add multiple comma-seperated options to the WindowStyle command.
* Remove the old Style command.
* Remove the Style wrapper and rename NewStyle to Style.
* Work out a method for DestroyStyle.
* Use the above method to optimize the StyleFunction.
* Test it to bits.

I'm sure I've missed out something important, hopefully doing a simple
trial will make it obvious.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 21 Dec 2001 13:24:44 +0000

> allow to do everything we may want to do with StyleFunction.

I just replied to Dominik with an idea for implementing this. Optimizing
the StyleFucntion would be part of the plan and would require some
way of deleting lines from a function.  Is this optimization sufficient?

For each style flag given to the Style command {
   For each line of StyleFunction {
     Delete any line with a matching pattern that sets/clears that flag
   }
   Add the pattern and style flags to the end of the StyleFunction
}

This would result in the StyleFunction being quite simple e.g.

Style Fvwm* Sticky, Layer 4

gives a StyleFunctions that looks like

+ I WindowId $0 (Fvwm*) WindowStyle Sticky
+ I WindowId $0 (Fvwm*) WindowStyle Layer 4

Maybe it could use a simplified version of WindowStyle that only works
on one style flag and doesn't actually do any visual updates until the end
( like the style function does ).

The matching patterns to delete is not just a straight string match but 
a match
of any subset e.g. F* would delete any Fvwm* patterns. I don't know how
hard that would be.

> In this case it will not be a function in a normal sence.

You're right, it would not be a normal function. There may be no point 
in exposing
it to users so maybe a hidden one would be better. But it would use the same
function creation routines we already have plus a special line-deletion 
routine.
Line deletion from functions may be useful anyway so maybe

DeleteFromFunction StyleFunction "I WindowId \$0 (Fvwm*) Sticky"
DeleteFromFunction StyleFunction "I WIndowId \$0 (Fvwm*) Slippery"

would be the way to go.

> In any case, to implement this, more operations over StyleFunction needed.

A really nice way to do this would be for the GUI to embed an XNest 
window and have it
run a captive fvwm inside with a couple of example windows (term, 
mozilla, transients etc.)

Dumping any function contents would be useful for debug anyway and 
dumping StyleFunction
would give the equivalent of DumpStyle, Restore Style would be a read of 
the file.

Cheers,
Tim.

Off for Christmas, See you In Jan.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 31 Dec 2001 18:05:02 +0100

> trial will make it obvious.

One thing comes to my mind.  The current style code is optimized
not to do everything at once but to wait until no other input is
pending.  It may be difficult to do the same with commands that
manipulate window state directly.  This might lead to a lot of
unpleasant viasual effects like multiple redraws, resizing etc.

I suggest we put a draft for this into CVS where everyone can add
comments so that we don't have to dig through a dozen email
threads each time.  Tim, can you put together an initial draft
with your ideas?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]