Subject: GSFR on main module essentially completed.

From: Dominik Vogt <[email-masked]>
Date: Fri, 09 Apr 1999 02:05:50 +0200

What remains is a bit clean up and debugging. I have noticed
three problems up to now:

  1) Modules have to be adapted to new style flags
     (e.g. the window background of the pager is black).
  2) The right title buttons are not displayed.
  3) 'Maximize grow' doesn't work.

Most of the code is in fvwm.h (all the important structs).
The window_flags struct has to be accesed with the macros in
gsfr.h. There are similar macros for the style_flags struct
in style.h.

I'm very tired now. Please, everybody should help fixing the
bugs and especially porting all modules. Look around the code
to get comfortable with the changes (I'll answer questions
tomorrow, but not now).

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]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 9 Apr 1999 02:37:37 +0200

>   3) 'Maximize grow' doesn't work.

In the meantime I noticed 2 and 3 are the same problem:
The MWM hints seem to be misinterpreted, so maximize,
iconify and windowshade are forbidden.

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Mon, 12 Apr 1999 22:50:59 -0400

> >   3) 'Maximize grow' doesn't work.

	Hi, folks. Sorry I've been out of touch the past 3 weeks - changes in
my work situation have had me preoccupied with other matters, and I've
barely been able to follow half the threads.

	I just did my first update in about 3 weeks this evening, and started
to attack the first module that failed to build (FvwmIconBox).

	Unless I've missed something in the past few days (not at all
unlikely), there's a fundamental incompatibility between the venerable
word-oriented module interface and the new flags. In module.c,
CONFIGARGS has had the old flags replaced by gsfr_flags, but the
packet-sending logic is expecting a list of long ints: gsfr_flags no
longer qualifies. No matter how the compiler aligns the bitfields, some
of them are going to get dropped on a 32-bit machine.

	Is somebody currently hacking away at a solution to this conundrum, or
should I continue looking into it? 

- Bob

---

From: Greg Badros <[email-masked]>
Date: 13 Apr 1999 00:35:31 -0700

> should I continue looking into it? 

You can look at window.c of Scwm where I've a bunch of functions that
convert from the bit fields to the old-style bit fields for module
support. See FlagsBitsFromSw.  If you don't feel like getting the whole
source to Scwm, you can access it via cvsweb at:

http://vicarious-existence.mit.edu/cgi-bin/cvsweb.new/~checkout~/scwm/window.c

Incidentally, I noticed that my author contribution snippet didn't make
it into fvwm2.2. I hope this was just an oversight (though based on Dan
Espen's response which he perhaps conveniently did *not* cc me on and I
just found now [see http://www.hpc.uh.edu/fvwm/archive/9902/msg00718.html 
and Dan's followup] I'm not sure --- my email of congratulations to this
group was sincere and meant as a peace offering in case of any hard
feelings from the Scwm/fvwm2 merge discussions; Dan, I hardly expected
this response given the significant contributions I made to fvwm2 while
development was otherwise stagnant for quite some time.  I wish fvwm2
developers and fvwm2 development well, and have continued to try to be
helpful here when I can -- search for my name in the mail logs if you
don't believe me).

In any case, here it is again-- I'd appreciate it if someone with CVS
write access could get this put in.

Greg J. Badros:
Substantial rewrite of fvwm2.0 menuing code to support arbitrary depth
menus, animated menus, Win95 look, better logically-based shortcut keys,
auto-splitting of long menus, check for re-used hot-keys, integrated
LEFT_MENUS option.  Added primitives: animated-moves, SetEnv, fix to
Echo. Improve modules: Make FvwmM4 pass args on to m4, font-related
seg-fault bug fix in FvwmButtons

Thanks, and keep up the good work!

Greg

---

From: Tim Phipps <[email-masked]>
Date: Tue, 13 Apr 1999 09:19:45 +0100

Bob Woodside wrote:
> No matter how the compiler aligns the bitfields, some

If we are going to pass al the flags over we have to be able to make the
M_CONFIGURE_WINDOW packet be of arbitrary size and have some common code
between fvwm and the modules for packing and unpacking the packet.  We
are going to break backward compatibility with modules not maintained by
us if we do this.

Is this possible/compilable?

union {
  struct {
    Bool flag1 : 1;
    Bool flag2 : 1;
    ...
  } style_flags
  unsigned long long_words[sizeof(style_flags)/sizeof(unsigned long)];
} flag_packet

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 13 Apr 1999 10:45:51 +0200

On Tue, Apr 13, 1999 at 12:35:31AM -0700, [email-masked] wrote:
> it into fvwm2.2. I hope this was just an oversight

Yes, sorry, I forgot to apply this. Will be done in a minute.

> (though based on Dan
> development was otherwise stagnant for quite some time.

Now I'm getting the impression you have hard feelings. I reread Dan's
reply and can't find anything but pure joy. If it's the sin of omission
not to have sent a personal reply to you I beg understanding in the
name of all fvwm developers. You must know yourself how hard it is to
keep everybody posting to the mailing lists happy and get some work
done at the same time.

> I wish fvwm2 developers and fvwm2 development well, and have continued
> to try to be helpful here when I can -- search for my name in the mail
> logs if you don't believe me).

I do believe you and I don't have to check the mail logs to remember
your help and I think highly of you for this since myself I don't
find the time to even look at other window managers.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [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]

---

From: Greg Badros <[email-masked]>
Date: 13 Apr 1999 02:07:41 -0700

> Yes, sorry, I forgot to apply this. Will be done in a minute.

Thanks!

> keep everybody posting to the mailing lists happy and get some work

Well, I was a bit annoyed that my author snippet wasn't put in and didn't know 
how to interpret it (plus was surprised that I wasn't cc'd by the
message following up);  I definitely think I over-reacted here, though--
my apologies -- especially to Dan!  Sorry Dan!  It's been a long day...

Reading the message w/o the context of my petty annoyance does make it
sound like pure joy! (And well-deserved joy!)

<snip>

> find the time to even look at other window managers.

Thanks-- it's silly not to be mutually helpful since code is still
shared between the projects.

Greg

---

From: Dan Espen <[email-masked]>
Date: Tue, 13 Apr 1999 08:34:31 -0400

> my apologies -- especially to Dan!  Sorry Dan!  It's been a long day...

Its been a long day for me too, and its only 8:30 AM.

I thought, for sure, you were on the workers list at the time.
Sorry the author update got missed, and that my thanks to you
for your comments and contributions didn't make it to you at the time.

--
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: [email-masked] (Paul D. Smith)
Date: 13 Apr 1999 09:52:21 -0400

%% Greg Badros <[email-masked]> writes:

  gb> Incidentally, I noticed that my author contribution snippet didn't
  gb> make it into fvwm2.2. I hope this was just an oversight (though

It was; I think because it was tucked at the bottom of the congrats
message (which was much appreciated!) it got lost.  A separate message
might have made more of an impact on our psyches--although at that
point, maybe not :).

  gb> based on Dan Espen's response which he perhaps conveniently did
  gb> *not* cc me on and I just found now

Others have responded re the intent of the message, but on a technical
level I'll just point out that many of us don't _ever_ CC the author
when messages are sent to fvwm-workers, unless it's obviously a bug
report from someone we've never heard of (or we forget to trim the
headers).  Your message didn't fall into either of those categories,
obviously :)

It's probably a poor assumption but generally we assume folks posting
here are subscribed to the list and we try to limit the number of copies
of a message people involved in the discussions see, by trimming out
everyone but the list address from the reply.  We'll have to be more
careful about this in the future.

Thx!

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Jason L Tibbitts III <[email-masked]>
Date: 13 Apr 1999 12:11:02 -0500

>>>>> "TP" == Tim Phipps <[email-masked]> writes:

TP> We are going to break backward compatibility with modules not
TP> maintained by us if we do this.

I thought that everyone realized that this would have to happen anyway as
part of the GSFR.  The question is: can it be done in such a way that it
doesn't have to break again?  Can it be done such that you don't have to
recompile the modules when new flags are added (i.e. send the flags as
strings or send a byte count before the flag bytes and never change the
order of any flags)?

 - J<

---

From: Matthias Clasen <[email-masked]>
Date: Wed, 14 Apr 1999 09:22:11 +0200

> From: Jason L Tibbitts III <[email-masked]>
> 

But the packets already contain a length field, don't they. After all,
we already have variable length packets (the name packets). Of course
the modules have to be educated that M_CONFIGURE is now a variable length
packet. This plus not changing the order of flags should be enough. 
Note that it would be enough to guarantee the order of the flags in the
packet to stay fixed, fvwm's internal order can be changed (not that
that would be a useful or fun thing to do).

Matthias
-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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, 14 Apr 1999 11:51:50 +0200

> that would be a useful or fun thing to do).

But if we don't want to change the order of flags we're using
#defined bits again. Compilers in general make no guarantees 
where and in which order bitfields are stored in a struct. I
believe with packed structs it will definitely happen that
this is not reliable.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 14 Apr 1999 11:12:44 +0100

> believe with packed structs it will definitely happen that

I think we have a choice to make:
1) keep backwards compatibilty and use Greg's code from Scwm to put
bitfields int fixed bits.
2) dump the bitfield over the wire and mandate that all modules are
recompiled using fvwm source for every release of fvwm.

We could do both by having the official fvwm modules use a different
M_CONFIGURE_WINDOW packet.  The existing M_CONFIGURE_WINDOW would be
constructed with Greg's code and be used by external modules, a new
packet would be used by all our modules.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 14 Apr 1999 23:24:07 +0200

> packet would be used by all our modules.

Hmm, why not. I suggest we make a configure option for this backwards
compatibility and remove it from the documentation or at least mark
it as obsolete and add a sentence that no work at all will be done here
if the integer overflows. This option should be off by default so
people realise that the module interface has changed.

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Thu, 15 Apr 1999 00:26:35 -0400

> people realise that the module interface has changed.

	Yikes! This is getting hairy. I hadn't really given much thought to the
issue of backward compatibility, since I looked on that as effectively
broken already by the GSFR. And what I had in mind was getting away from
the word array packet style, and moving to regular structures (suitably
mapped in some FVWM header file which the modules would have to
include). Of course, older packets that didn't need anything more
complicated would just continue to be composed of a sequence of long
ints - but with intelligible names to them, instead of something like
buffer[7] (oh, hell, was that the y position or the x width...???).

	This would make module code a lot easier to work with, but it doesn't
offer much help for Jason's idea of not needing to recompile modules.

	Let me play devil's advocate for a moment. Does anyone have a sense of
just how many 3rd-party modules are really floating around out there,
outside of the FVWM distribution? (Obviously, I don't.) Are we worrying
about a problem that doesn't really exist?

	As to backward compatibility - I think Jason's suggestion was for what
we might call "future backward compatibility": present backward
compatibility can't really happen because 1) the new flags have already
overflowed a long int on 32-bit machines, and 2) one of the old flags
(STAYSONTOP) no longer exists. So, at the very least, any module that
looks at the M_CONFIGURE_WINDOW packet will have to be modified.

	I think we can partially achieve binary compatibility - i.e., no
recompiles - by making every effort possible not to change the order of
the packet elements, always adding anything new at the end, and
prefixing anything that might be variable (like the flags struct) with a
length.

	This can never be 100% foolproof. As we've seen, flags can cease to
exist. 

	Hmm...there's also a potential gotcha if a module got compiled with a
different compiler from the one used for FVWM itself (bitfields could be
allocated in a different order). I think I'd prefer to document that the
module and FVWM must be compiled with the same compiler rather than
translate the flags to specific bit positions in ints and have modules
continuing to use the old "if (body[8] & STICKY)" style syntax.

- Bob

---

From: [email-masked] (Paul D. Smith)
Date: 15 Apr 1999 01:56:43 -0400

The only existing, relatively up-to-date 3rd party module I know of at
the moment is tkgoodstuff.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 15 Apr 1999 01:41:53 -0500

>>>>> "BW" == Bob Woodside <[email-masked]> writes:

BW> oes anyone have a sense of just how many 3rd-party modules are really
BW> floating around out there, outside of the FVWM distribution?

The Tk buttonbar replacement, the Perl and Python interface stuff (although
at least some of that is internalized now, I think), the CDE panel (though
I don't think it's being maintained any longer), various hacked versions of
the wharf and the windoze taskbar that people use.  Not a big list,
certainly.

BW> As to backward compatibility - I think Jason's suggestion was for
BW> what we might call "future backward compatibility": present backward
BW> compatibility can't really happen [...]

Well, it's only something that's nice to have.  Is it is possible to change
everything once such that changing it in the future doesn't require any
worry?  It's like converting a function taking positional parameters to
taking named parameters.  Adding parameters later becomes really simple,
but there's always a tradeoff (argument parsing is required and slows
things down).

 - J<

---

From: Bob Woodside <[email-masked]>
Date: Fri, 16 Apr 1999 09:29:20 -0400

Bob Woodside wrote:
>
> ...the M_CONFIGURE_WINDOW packet will have to be modified.

	Ok, I've sketched out a modification that I think will do minimal
violence to the existing packet logic. Barring any major interruptions,
I might even have a chance to try it out today.

	My idea is to create a make_new_vpacket function, which takes as its
args a list of lengths and variable pointers, and returns the aggregate
length of the resulting packet. I'm not suggesting we immediately try to
rewrite all the existing module packet logic, which doesn't need it.
I'll only change the M_CONFIGURE_WINDOW (well, and M_ADD_WINDOW, which
is the same thing with a different name) so it'll pick up the gsfr_flags
in their native form, allowing modules to use Dominik's gsfr macros just
like the main code.

	If this works (hey, why wouldn't it? - it compiles!), then I'll start
attacking the half dozen or so modules that don't grok gsfr.

	Tim, I haven't done an update since earlier this morning, but I see
you're doing some stuff with M_OLD_CONFIGURE_WINDOW, etc. Are you in the
process of rewriting the logic also? Are we about to trip over each
other?

- Bob

---

From: Tim Phipps <[email-masked]>
Date: Fri, 16 Apr 1999 15:37:24 +0100

> process of rewriting the logic also? Are we about to trip over each
I'm done (he who commits first gets away with it). M_CONFIGURE_WINDOW
has a new number but that shouldn't affect you.  I have added some stuff
to SendConfig() and BroadcastCinfig() which might give you conflicts
when you update.  Save your module.c into a backup before you update.
All my changes are bounded by #ifndef DISABLE_MBC blocks.

Cheers,
Tim.

---

From: Bob Woodside <[email-masked]>
Date: Fri, 16 Apr 1999 10:18:03 -0400

Tim Phipps wrote:
> 
> I'm done (he who commits first gets away with it). 

	Heh-heh.

	It doesn't look like anything you've done gets in the way of my change
(which is still in one of my "play" directories, not in my CVS, so no
problems there).

	Are you using this code with some modules compiled pre-GSFR? If so,
how's it working?

	Does my approach for new-style packet building seem reasonable? (I just
had a couple of interruptions, so I haven't had a chance to try it yet.)

- Bob

---

From: Tim Phipps <[email-masked]>
Date: Fri, 16 Apr 1999 16:40:23 +0100

>         Are you using this code with some modules compiled pre-GSFR? If so,

Much better, the pager seems OK, but I think FvwmWinList isn't getting
the winlistskip correct, could be a bug in my packet generation or in
the flag setting.

> had a couple of interruptions, so I haven't had a chance to try it yet.)

Sounds good, Do you put the variable length stuff at the end of the
packet? Have you got a method for modules to unpack the data?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 16 Apr 1999 17:57:51 +0200

> attacking the half dozen or so modules that don't grok gsfr.

That reminds me of my (terribly incompetent) predecessor at my job:
He once said (months before his work was done):

  "It compiles already, now there are only minor changes left."

Needless to say that I was still making these 'minor changes'
when he was gone for half a year :-)

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Fri, 16 Apr 1999 14:21:01 -0400

Success! My Pager immediately cored out because, now that both words of
the gsfr_flags are going through, everything's out of alignment.

hippo>  Sounds good, Do you put the variable length stuff at the end of
hippo>  the packet? 

	Hmm...I hadn't thought about it yet, but I suppose the gsfr_flags need
to be moved to the end, since they're now potentially variable. After we
add the next 25 styles or so from the enhancement backlog, we'll be
expanding into another word.

hippo>  Have you got a method for modules to unpack the data?

	I'm still thinking about that one. It depends on what kind of things we
want to put in future packets (like strings 'n things).

	I may have been unclear about the make_new_vpacket function's taking a
list of argument lengths and pointers. It doesn't put the lengths into
the the packet (we could do that, but I don't think it's needed), just
the argument data items. So the M_CONFIGURE_WINDOW packet still just
looks like a bunch of long ints, only the gsfr_flags will occupy two of
them on 32-bit machines (and I'll move them to the end). The inbound
buffer can then be covered with a structure definition like

struct  my_packet {
Window         thiswindow;
   ...
unsigned long  thisthing;
unsigned long  thatthing;
unsigned long  totherthing;
   ...
window_flags   gsfr_flags;
};

Dominik's macros will work nicely with this structure, and we don't have
to try to remember what body[15] is supposed to be.

	I'm still ambivalent about the idea of including a length-of-flags
field in the packet. I'm not sure that a module could reliably do
anything with that information other than do a sanity check to see
whether the flag structure is of the length it expects, and bail out if
not. Although we can keep the flags defined in the same order, we can't
control how the compiler will allocate the bits within a word, and more
importantly, across words. So, if the flags expand from two to three
words, I don't think a module can safely determine where to look for the
flags it understands.

	Now, on to the Pager....

- Bob

---

From: Jason L Tibbitts III <[email-masked]>
Date: 16 Apr 1999 14:24:37 -0500

>>>>> "BW" == Bob Woodside <[email-masked]> writes:

BW> Success!
BW> My Pager immediately cored out

I feel like I'm missing something.  ^_^

 - J<

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 17 Apr 1999 14:51:16 +0200

> expanding into another word.

Before we put a lot of work in rewriting all modules: the name 'gsfr_flags'
is only temporary. It will be changed back to 'flags' soon. The file 'gsfr.h'
will be renamed or removed too. How about a 'window_flags.h' file?

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Mon, 19 Apr 1999 12:18:59 -0400

> will be renamed or removed too. How about a 'window_flags.h' file?

	I overlooked this message when it came in. I just noticed I had a stray
unread message while cleaning up my inbox, and this was it.

	The changes I've applied were done against the "flags" version, so
that's not a problem.

	gsfr.h is sourced from vpacket.h, so the one include in that file is
all that should need to be changed for the modules if you rename gsfr.h.

	I've gotta take a break from the GSFR for the rest of the day and get
some work done.

- Bob