Subject: WindowStyle in functions

From: Grzegorz Nieweglowski <[email-masked]>
Date: Wed, 30 Jul 2003 11:50:03 +0200

I have some troubles with WindowStyle/fvwm functions.

This sample code:

	DestroyFunc FSMax
	AddToFunc FSMax
	+ I WindowStyle !Borders, !Title
	+ I Maximize true

should, according to my knowledge of fvwm:
a. remove the title and borders from a window
b. and then maximize it

but strangely, it seems to:
a. maximize the window first
b. and then remove the decorations

could someone verify this?

--
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: Wed, 30 Jul 2003 17:02:09 +0200

> b. and then remove the decorations

The man page is your friend :-)  It's documented behaviour.
Window styles are only applied when fvwm has nothing else to do
(for performance reasons).  To apply them immediately inside a
function use the RefreshStyle command.

P.S.:  Please keep in mind that the first thing I'll do if 2.6 is
ever released is to remove the WindowStyle command.

Bye

Dominik ^_^  ^_^

---

From: Grzegorz <[email-masked]>
Date: Wed, 30 Jul 2003 20:13:42 +0200

> function use the RefreshStyle command.

[FVWM][__execute_function]: <<ERROR>> No such command 'RefreshStyle'

;)

Well, I stand corrected. Again.

> ever released is to remove the WindowStyle command.

Really? Then I'll need to prepare a patch and add it "at home".
WindowStyle adds an incredible amount of new functionality to fvwm
- it's just what the doctor ordered.

-- 
\hoppke
(Grzegorz Niewęgłowski)
http://lubuska.zapto.org/~hoppke/

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 30 Jul 2003 22:34:43 +0300

On 30 Jul 2003 20:13:42 +0200, Grzegorz wrote:
> 
> Dominik Vogt nawypisowywa?(a):

It is called UpdateStyles (RefreshWindow is ok too). Should be executed
after Style, FocusStyle, WindowStyle, TitleStyle, Colorset if needed.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 31 Jul 2003 11:30:02 +0200

> Well, I stand corrected. Again.

Okay, it's named UpdateStyle.  As I said, the man page is your
friend.  I'm no walking man page myself.

> - it's just what the doctor ordered.

All I said was that you should keep that in mind.  In 3.0, I want
to clean up all the misdesigned features.

Bye

Dominik ^_^  ^_^

---

From: Grzegorz <[email-masked]>
Date: Thu, 31 Jul 2003 13:35:26 +0200

> friend.  I'm no walking man page myself.

Maybe UpdateStyles and UpdateDecor should be renamed to RefreshStyles
and RefreshDecor? It would look better next to Refresh and
RefreshWindow.

> All I said was that you should keep that in mind.

And I'll keep that in mind - I'll have to create a diff to get
WindowStyle back :) BTW, why won't you accept WindowStyle as
a "temporary solution"?  According to "todo-3.0" the whole Style system
will get rewritten anyhow. And even if WindowStyle is "misdesigned"
- it's still better than nothing.

> In 3.0, I want to clean up all the misdesigned features.

As an end-user (not fvwm-hacker, so I'm not "tainted") I can say that
the biggest "misdesign" in current FVWM code is the scripting engine. It
has this "I'm a never ending hack" look&feel. A true overflowing
bucket'o'patches.  Employing a true scripting language (python maybe?)
would make fvwm much easier to understand and script. It would also be
a great opportunity to reduce the number of commands and clean it up.

FVWM is now very complex, there are tons of different commands but the
scripting interface is incredibly primitive. If only fvwm would resemble
Sawfish in this aspect...  the level of "power" is about the same in
FVWM and in Sawfish, but scripting Sawfish is much easier, even if their
chosen language is a lisp variation (not the best choice for a WM, but
still better than fvwm scripts).

Yeah, I know it would be a hell of a job to repair it now. But it would
improve fvwm's usability by a tremendous ammount, and if you really
intend to remove/fix fvwm's biggest flaws - well, that's my Misdesign#1
(it wasn't so bad ever since - it's just that fvwm grew bigger,
and bigger, and more complex... and the scripting "base" got "out of
sync")
--
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: Thu, 31 Jul 2003 21:08:56 +0200

> - it's still better than nothing.

Everybody is entitled to his opinion.

> bucket'o'patches.

Sure, you must know it.  I guess you have spent weeks studying it.
Apart from its lousy speed and some problems with quoting, the
scripting engine isn't *that* bad.

> Employing a true scripting language (python maybe?)
> would make fvwm much easier to understand and script.

Actually, it would make it much harder to script for the
non-(insert scripting language of your choice)-junkie.

> It would also be

Funny, a couple of lines further up you complain about exactly
this:  that I want to remove superfluous commands like
WindowStyle.

> still better than fvwm scripts).

I disagree.  Lisp allows only hardcore programmers to do anything.

Bye

Dominik ^_^  ^_^

---

From: Grzegorz <[email-masked]>
Date: Thu, 31 Jul 2003 23:45:34 +0200

> Sure, you must know it.  I guess you have spent weeks studying it.

That's the point. I don't study it - I just came, compiled it and
started to use it.

> scripting engine isn't *that* bad.

I wanted a "QuakeTerm" once (a xterm window sliding from top of the
screen and hiding) - a toggle function actually, very simple, move the
window from desk 666 to current, bring it to the front and unshade. Then
shade it and move it back to 666. In the end I needed to split the code
into 3 functions just to keep it sane with all those Cond and CondCases.

Quoting is very bad, those ugly hacks with PipeRead just to get
something expanded right. But the real problems are (IMO) the way to many
commands, functions which can't really return useful results, no
internal data structures (only env. vars).

You say it's not bad because you have been sitting in its code for such
a long time you've got the Blessings of Immunity :)

> non-(insert scripting language of your choice)-junkie.

And right now it's hard to script for _everyone_ but fvwm-junkies. It's
unlike any other language. Choosing a widely-used scripting language
makes it _easier_ for some people, but not harder for anybody else. Do
you think that if fvwm would use perl natively I would have bigger
trouble learning it (I'm no perl junkie, so according to your words
switching to Perl would mean trouble for me)?

I mentioned Python because it has a reputation for an "easy to learn
language" with clear and well-thought syntax. If you don't know it, you
have to learn it. If its fvwm or python, doesn't matter. With Python (or
perl, or scheme, or lisp, or ruby) there is simply the possibility that
some users will already know it and that there will be good books on the
topic.

>> It would also be a great opportunity to reduce the number of commands
>> and clean it up.
> 
> Funny, a couple of lines further up you complain about exactly this:
> that I want to remove superfluous commands like WindowStyle.

What I was thinking about: if fvwm had true programming abilities, you
know, loops, data structures, conditional blocks etc. you could
represent windows, keybindings and the likes as ordered structures of
properties (or groups of variables, if you like). A window could be
represented by an object with a set of keys (properties). You could
alter these properties by assigning values to them. Like change the name
of a decor assigned to a window by changing a "decor" property.  Or
check if a window is maximized by checking the value of the "maximized"
key.

Keybindings could be represented as a table, with pairs of
key-context-function. This table could be searched or altered just as
you do it with variables - by using simple assignements.  Styles could
be represented by a list similar to the "managed window list", with the
twist that windows in the "styles" list would serve as masks altering
the properties of matching windows. It's hard for me to explain, I'm no
programmer. But maybe you understand what I mean.

The simplicity lies in the reduced amount of commands. You no longer
need the Style command - you just change a group of objects, defining
their properties. You don't need the WindowStyle command - you operate
directly on the list of managed windows. Arrange the internals in a neat
and clean way, show them through an API to the user and that's all.
Instead of a "All" or "Any" command the user could loop over the list of
managed windows and test some keys. Deleting styles would be possible.
A couple of lines of code and you could remove all defined bindings for
the "R" context. Silly examples, but they show how flexible it is.

And adding new features means mostly "adding new properties" to objects.
Once you've done it, there's no more work. For instance now in fvwm you
can test only certain conditions, those that were predestined by the
coders. For instance it is impossible to select all windows of the same
decor or all of a certain size. Because no-one thought that it could be
usefull and added a link between such properties and arguments to
Current/All/Any.  Now fvwm is doing the "a function for every occasion"
thing. That's nice, but for simple programs and spawns problems as the
whole code gets overly complex and hard to understand in its
interdependencies.

If, however, you would choose to simply show all the props of objects to
the user, those functions could be implemented as scripting functions
- easy to redefine or customize. Adding a new property to a window
wouldn't require changing anything else - for instance the ability to
have titles at left implies the existence of a property
"title-placement".  And if it exists it could get values assigned or
tested in conditionals.  So you don't need to add new Style options
"TitleAtLeft, ..." or new Conditions to reflect the changes.

That's what I was really thinking about. Anybody that ever Sawfish-ed
will know what I mean. I'm just trying to show an approach that could
really simplify things in fvwm. Of course it comes with high initial
costs - dumping the current model and quite an amount of code, backwards
compatibility gets lost, but it's more, how do you say it, "ready for
what the future brings". Sorry for making it that long and boring.

>> scripting Sawfish is much easier, even if their chosen language is
>> a lisp variation (not the best choice for a WM, but still better than
>> fvwm scripts).
> 

I was able write some simple extensions to Sawfish on my own (random
background changer, desk title popup after desktop switch, center window
on screen, functions like FvwmBacker, popup-clock-and-date etc.) but
I don't consider myself a hardcore programmer. Sawfish comes with good
Info documentation, even regarding the basics of sawfish-lisp (no wonder
since it's a dialect), so I quickly knew how to write simple loops,
conditional blocks or manipulate lists. :) There are things in fvwm that
are IMO way more difficult to understand than the basics of Lisp, like
the ItemFormat option of MenuStyle.

---

From: Dan Espen <[email-masked]>
Date: Thu, 31 Jul 2003 17:57:48 -0400

Grzegorz <[email-masked]> writes:
> the biggest "misdesign" in current FVWM code is the scripting engine. =
> It

Please, constructive comments only.

> a great opportunity to reduce the number of commands and clean it up.

Feel free to use any language you want.

FvwmCPP
FvwmM4
FvwmPerl
PipeRead
FvwmCommand

Except when playing pysol, I don't have the python interpreter in
memory.  I wouldn't be happy with a window manager that pulled
an interpreter into memory.

-- 
Dan Espen                           E-mail: [email-masked]