Subject: Window managers.

From: German Jose Gomez Garcia <[email-masked]>
Date: Wed, 18 Nov 1998 23:22:07 +0100 (MET)

Well, after a little time of inactivity and some testing of
the new generation of window managers, as Enlightenment and
WindowMaker, I realize that we need to work hard if we want to make
something really usefull. Although Enlightenment is really huge and
not very usable (IMHO of course), WindowMaker seems really good, and
it's configuration program is the best I've seen around. So here are
some TODO thoughts to keep fvwm2 where it deserves!
    The following is always IMHO, so if you disagree, mail to the
list, so we all could know about it :)

	- We NEED a configurator program, something better than
FvwmConfig is definetely required if we want to have a chance. Looking 
at WPrefs (from WindowMaker) should provide enough ideas for a year of 
work :)
	- The discussion about syntax is futile, we already have some
politics on styles definitions, we have the Style command as a model.
I've already started changing the SetMenuStyle so it ressemble as much 
as posible to the Style command, for now I'm storing the styles
preparsed (just a linked list), I'm adding new capabilities, as
selecting the way items are marked, with rectangles, ovals, other
colors, other pixmaps, etc; and also setting the popups properties, 
triangle definitions,etc, no more fvwm, mwm, win, next or
anything else a sick mind as mine could think of :) 
	- I  need someone who  think of an intelligent way to make the
gradients, I think I did the best I could (with memory, not speed, in
mind) if someone knows of a better way to do it (without storing
prerendered pixmaps with the gradients) please email me, the routine I
use now isn't optimized at all. 
	- Someone should become Theme Manager for fvwm2, collecting
icons, textures, and .fvwm2rc, sorting them and making some original
art; what about a little update to our logo? any gimp artist here?
	- We should decide what modules are really important/usefull,
I know it is not a good idea to remove something if it works, but the
question is how much time are we going to spend in debugging modules
that nobody uses? 

	I know it is too much sutff and it is not easy, but window
managers world is going really fast, the war has blowed up.

    FVWM2 NEEDS YOU, JOIN THE ARMY (that is join the mailing list ;)

	Thats all (at least for today it's enough)

<>-------------------------------------+-----------------------------------<>
   One O.S. to rule them all,          |  German Gomez Garcia
      One O.S. to find them.           |  [email-masked]
   One O.S. to bring them all          |
      and in the darkness bind them.   |  "Wur Qanar Wur Stilor Wur Kas"
<>-------------------------------------+-----------------------------------<>

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Wed, 18 Nov 1998 15:38:07 -0800

> art; what about a little update to our logo? any gimp artist here?

There is fvwm.themes.org.  However, I prefer single .fvwm2rc files as
opposed to the fvwm.themes.org multifile format (that's just my taste
though, either way is fine really).  His logo is nice looking too...could
be made into fvwm logo I would think.

---

From: [email-masked]
Date: Thu, 19 Nov 1998 08:59:53 -0500 (EST)

For compatibility with past and/or future versions of FVWM's syntax
parser, would it be possible to support a new keyword:

    FvwmRCVersion	<release>

This would allow .fvwm2rc files to "advertise" the RC syntax that they
are using.  It would also allow somebody to write a helper program
(FvwmSetVer, perhaps?), that might be able to translate the differences
between the various versions.

A simple example of an RC change could be changing the "Style" command
to use a new syntax as follows:

    Old (2.0.0):	Style "Fvwm*" HandleWidth 0, WindowListSkip

    New (2.1.2):	Style [title="Fvwm*" resource="Fvwm*"] \ 			
			    HandleWidth 0, WindowListSkip

(Note that this is just an example, although such a syntax could easily
be used by the Next, Prev, Current, keywords as well!)

When reading the .fvwm2rc file, the parser could see the FvwmRCVersion
number (2.0.0), and if it is not the version number that it expects
(2.1.0), it could launch the FvwmSetVer program to attempt to convert
between the two RC file formats in order to properly process the file
(sort of like how fvwm2 currently can spawn m4 or cpp to pre-process
the image).  Thus, the fvwm2 parser only needs to parse the new syntax,
leaving the support of the older syntax to the helper program.

The drudgery of supporting older RC files is now relegated to that
simple helper program.  All the program needs to know is the version
number of the RC file (from the FvwmRCVersion keyword) and the version
number understood by the parser.  The helper program then either has an
internal filter that can do the parsing, or it tries to launch a
specialized script.

The actions of the helper program are very simple and could easily be
written in perl, awk, or any other language with good parsing ability.

This could help ease the burden on users when the syntax of the RC file
changes, as the change could be handled as transparently as possible. 
It also removes the complaint "Well, that sounds nice, but it would
break existing configuration files."

Comments?

-- 
Larry Gensch					      [email-masked]

               "May I have ten thousand marbles, please?"

---

From: Dan Espen <[email-masked]>
Date: Thu, 19 Nov 1998 09:30:27 -0500

> between the various versions.
...
> break existing configuration files."

Its not always easy to update the users config file.  There are reads,
and pipereads, and commands  coming in thru M4 and  CPP.  Better to do
our best to keep the command syntax compatible.

I take it you favor :

Style [title="Fvwm*" resource="Fvwm*"]

over

Style -title "Fvwm*" -resource "Fvwm*"

I do too.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Brad Giaccio <[email-masked]>
Date: Thu, 19 Nov 1998 10:18:34 -0500 (EST)

> Style -title "Fvwm*" -resource "Fvwm*"

I must have missed this one.  When did syntax become valid?

As for a processor.
There is a couple of problems
1. I'm assuming you want the RCVersion to be in the rc file itself, well
that could create some problems for older files where it doesn't exist, so
you'll need to figure out if the file is an old fvwm2 or an old fvwm1 file
I suppose.

2. I'm not sure would this be something that is run at each start up or is
it run once when you switch versions?
	-- if its everytime that could lead to problems if lines don't
parse quite right
	-- if its once then maybe we start doing some preprocssing on all
files,  if we ever get FvwmPreproc (M4 and CPP combined) we could tag
sections that are version specific 
		if (VERSION == fvwmxxx) this
		else that  -- which is what I do in my rc with M4 right
now.

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

---

From: Dan Espen <[email-masked]>
Date: Thu, 19 Nov 1998 10:26:06 -0500

Brad Giaccio <[email-masked]> writes:
> I must have missed this one.  When did this syntax become valid?

It is not valid  yet.  I recently proposed that  the style matching be
enhanced along these lines.  Ie. be able to  say what exactly you want
to  match on, instead   of matching on everything   and hoping for the
best.

I think we are close to settling on the command syntax.

---

From: [email-masked]
Date: Thu, 19 Nov 1998 11:00:53 -0500 (EST)

> you'll need to figure out if the file is an old fvwm2 or an old fvwm1 file 

Of course.  Actually, thinking a bit more, I think it should be
something like:

#FvwmRCVersion	2.0.0

(so previous versions of fvwm2 would ignore it as a comment)

Users can then add the lines to their RC files to allow newer version
of fvwm2 to process them correctly without modification.

> it run once when you switch versions?

Every time.

> 	-- if its everytime that could lead to problems if lines don't

Let's look at some things that COULD change:

1.  Adding a new "Keyword" into an RC file

    Older RC files will not have the keyword, so the helper program
    can simply ignore this situation.  However, it is possible that
    a user has a user-defined function with the same name.  The easy
    solution here is to have the helper program notice the "mis-used"
    keyword, and modify it to some other name, caching the name, and
    replacing the new name wherever the old function name is found.

2.  Deleting a "Keyword" from an RC file

    The helper program only needs to modify such keywords to NOP's.

3.  Changing a Keyword's syntax.

    Example:

	Old:	Style "Fvwm*" HandleWidth 0
	New:	Style [title="Fvwm*" resource="Fvwm*"] HandleWidth 0

    In this example, it is easy to represent the new syntax from the
    old format to the new format using a helper program.  Fvwm's
    parser only needs to process the new format.

Remember, the conversion is being done by a "helper program" and not
by fvwm itself.  The conversion programs should be conservative... if
they aren't perfect, the user is still able to modify the RC file to
the correct format.  The idea is to give the user "something that
works."

* * *

Finally.... the FvwmSetVer "helper program" -- while being useful -- is
NOT REALLY NECESSARY!!!

If fvwm were only to parse the FvwmRCVersion string and notice that it
is missing (probably an old configuration file), or not the expected
value, it can put up a warning message indicating that the RC file may
be out of date, and even give the user the option of continuing to
parse the file (all bets off), or to stop parsing immediately (giving
some minimal functionality).

Simply attempting to read an out-dated RC file and causing all sorts
of havoc and unexpected consequences causes a lot of confusion on the
user's end.

Another useful feature of this... I have seen some .fvwm2rc files
passed around on this and the main FVWM mailing list, as well as on
some web sites.  Having a version number in the RC file documents which
version of fvwm that it was written for.

Actually, I think such a feature should have been in fvwm ever since
the big RC file format change that lead to the first version 2.x
release.

---

From: "Eddy J. Gurney" <[email-masked]>
Date: Thu, 19 Nov 1998 11:13:47 -0500

,--
| 	- Someone should become Theme Manager for fvwm2, collecting
| icons, textures, and .fvwm2rc, sorting them and making some original
| art...
`--
Just as a thought... I was thinking last night that there is an
abundance of very nice, well thought-out, attractive "schemes" for a
Macintosh program called "Kaleidoscope". It would be terrific if
we could add support to fvwm2 to transparently "use" (some parts of)
a "Kaleidoscope Scheme" file. Take a look at some of the designs at:

 http://kaleidoscope.net/schemes/

While I realize a lot of Kaleidoscope deals with changing the "widgets"
(checkboxes, buttons, scroll bars, etc. which we can't "override" in
fvwm2 [bummer]), it also deals with color selection, title bar styles,
title bar button shape, etc.

The default Macintosh title bar has three buttons (for those that
don't know). From left to right, they are "close", "maximize" and
"window shade".

This would be an easy way for people to customize FVWM's "apperance"
if we could take advantage of existing "designs" like the hundreds
of thousands of Kaleidoscope schemes. Some of the schemes get pretty
far-out, and give "Enlightenment" a run for its money (see the "New
Schemes" section in the above link, and scroll down to the "Mackintosh",
"XLR Power" and "IZA Blue Metal" schemes, for example...)

Being an avid Mac user/programmer, I can offer assistance to decoding
the Kaleidoscope themes, etc. if anybody thinks looking in to this
functionality would be worthwhile. Personally, I think it would be an
awesome extension to fvwm2...

Eddy

---

From: Jay <[email-masked]>
Date: Thu, 19 Nov 1998 15:55:05 -0500 (EST)

> a "Kaleidoscope Scheme" file. Take a look at some of the designs at:

   I was thinking about a very similar thing.  How about someone work out
a 'theme' module... Something that could read different types of themes...
say from windowmaker, kaleidoscope, etc... and configure you 
accordingly.  It could support our own 'native' format, of course, but it
would lend nicely to our Favorite/Flexible virtual window manager to be
able to use other systems themes.  It shouldn't be too difficult to
convert 'themes' to fvwm configuration commands... 

Anyone else think this is a good Idea?  I'd be willing to work on it...

(though I can tell you that I do have alot on my plate so anyone 
 interested in working on it too is more than welcome... )

Thoughts?

Jay

---

From: Todd Larason <[email-masked]>
Date: Thu, 19 Nov 1998 13:01:04 -0800

This is one of my back-burner projects for scwm.  I have code written (and
checked into the scwm cvs server, in a not-quite-working state) to read
MacBinary, AppleSingle and AppleDouble files, to find the resource fork, and
to fetch resource data by type and ID.

I have written, but not checked in, code to convert some of the icons (the
ics#, ics4, ics8, ICN#, icl4, icl8) to xpm format.

There's still a lot of work to do, but this might be a helpful place to
start.  The code is GPL, with an exception that allows its use in other
twm-derived WMs.

The big 'infrastructure' requirement left is to be able to read StuffIt Deluxe 
files.  Has anybody seen ANY information about the compression technique, or
have the time & expertise to reverse engineer it?
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Maciej Stachowiak <[email-masked]>
Date: Thu, 19 Nov 1998 16:02:39 EST

> Anyone else think this is a good Idea?  I'd be willing to work on it...

It would take a lot of hacking for fvwm to be able to actually look
like the window managers and other GUIs you mention. Anything
requiring shaped windows, widely different borders, etc, would require
a lot of changes to fvwm. This is made harder by the fact that the
current fvwm2 decoration code is a mess (and no, this is not meant to
be hostile, we haven't cleaned it up that much in scwm yet either,
though we have made a few things more flexible).

 - Maciej

---

From: Jay <[email-masked]>
Date: Thu, 19 Nov 1998 16:34:26 -0500 (EST)

> though we have made a few things more flexible).

Understandable.  I'm not saying lets hack the decoration code...  I just
would like to see a 'themes' thing for Fvwm.  Some type of config that is
relatively simple to produce that can be used for decoration information.
That's why I suggested a themes module.  It could transparently do the
conversion of the 'theme' file to fvwm configure commands.  If it could
try to interpret other themes, so much the better.  Either way, whether we
build it for only it's native format or if it can read others (and use at
least some of the decorations) I am willing to work on it.

Jay