Subject: Re: FVWM: window flags bitfield

From: "Charles Hines" <[email-masked]>
Date: Tue, 9 Dec 1997 09:51:08 -0500

>>>>> "Paul" == Paul D Smith <[email-masked]> writes:

Paul> %% Bob Mende Pie <[email-masked]> writes:
bmp> I just spent 15 minutes adding the ability determine if a window
bmp> is "WindowShaded" so I can do complex operations on it.  I see
bmp> that this was never added since ALL of the 32 bits of the window
bmp> flags field are allocated.  (Note, I stole bit 31, from the motif
bmp> hacks which I dont use).  What do people think about bumping this
bmp> to 64 bits?

Paul> This is known as the GSFR (Great Style Flag Rewrite) and is the very
Paul> first and most important thing that is planned for the post-2.1 FVWM
Paul> version.  People have so many uses for this by now that 64 bits is
Paul> likely not enough; it'll have to be expandable (would anyway,
Paul> obviously).

The ideas I have for the GSFR should make it completely expandable,
although I would hope that it doesn't go too far beyond 64 bits.

Paul> Of course, the GSFR is really a legend and will never happen, because
Paul> FVWM 2.1 is a legend and will never happen (no offense to anyone in
Paul> particular, but it's been 2 years or more since I saw the first message
Paul> saying there was going to be one more "clean up" version, then 2.1; many
Paul> months, releases, and identical announcements later there seems to be
Paul> lots of enhancements but exactly 0 progress towards that goal.  Just my
Paul> perspective :).

Ouch! :)

I prefer the term 'semi-mythical' myself.

I have to admit that my progress with fvwm has been less than optimal
(as I warned it would be when I started) and I've been sorely tempted
lately to give up the care and feeding of fvwm to someone else because
of that.

[If those Lotto tickets would come through for me I'd have a lot more
free time to work on it! :)]

But for the time being at least I'll continue to plod along, as I'm
not quite ready to admit defeat.  I wish I could do something about
that stubborn streak. :)

[BUT, if anyone out there feels they'd like to try taking over
eventually, PLEASE let me know sometime in some private email]

So, a quick status and some theories:

  - Work on 2.0.47 is going ok (but slowly).  Quite a bit is going
    into it.  I hope to have it ready by the end of the year or
    shortly thereafter (I'll be taking vactaion the last two weeks of
    December and plan to finish it up during that if I haven't done so
    before then).

  - I hope that only one or two more 'betas' will be necessary after
    that before 2.1.0 can finially appear.  As I said, quite a bit is
    going into 2.0.47 and some bugs will have to be ironed out, but I
    think that it's finially getting close...  Hm...  Paul, does that
    sound familiar? :)

  - The GSFR is still planned for sometime after 2.1.0 is out.  I'll
    try and get a sketch of my ideas for it into the TO-DO list, in
    case anyone is interested or I'm forced to pass on the torch to
    someone else before I'm able to take a crack at it.  (I'd like to
    get some feedback on it if I do write something up)

Chuck

--
*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
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: Jason L Tibbitts III <[email-masked]>
Date: 09 Dec 1997 13:49:09 -0600

>>>>> "CH" == Charles Hines <[email-masked]> writes:

CH> The GSFR is still planned for sometime after 2.1.0 is out.  I'll try
CH> and get a sketch of my ideas for it into the TO-DO list, in case anyone
CH> is interested or I'm forced to pass on the torch to someone else before
CH> I'm able to take a crack at it.

Didn't someone essentially do the work already?  I require a patch posted
here which purported to have dome so.

 - J<

---

From: "Charles Hines" <[email-masked]>
Date: Tue, 9 Dec 1997 16:48:22 -0500

>>>>> "Jason" == Jason L Tibbitts <[email-masked]> writes:

Jason> Didn't someone essentially do the work already?  I require a
Jason> patch posted here which purported to have dome so.

Dan Espen claimed to do the GSFR in his iconbox patch, but it really
only cleans up the style parsing code a little bit (AFAICT), but I
feel that's only part of the problem.

The actual GSFR (at least the way that I have envisioned it) is going
to require more than that - namely changing ALL of the code that
access the style flags in some way.

Chuck

---

From: [email-masked] (Paul D. Smith)
Date: 09 Dec 1997 16:46:16 -0500

%% "Charles Hines" <[email-masked]> writes:

  ch> I prefer the term 'semi-mythical' myself.

:)

  ch> I have to admit that my progress with fvwm has been less than optimal
  ch> (as I warned it would be when I started) and I've been sorely tempted
  ch> lately to give up the care and feeding of fvwm to someone else because
  ch> of that.

I notice that no one (including, I'm first to admit, me) is jumping up
and down to take your place, so don't feel bad :)

  ch>   - Work on 2.0.47 is going ok (but slowly).  Quite a bit is going
  ch>     into it.

A comment: in my experience this is extremely common with free software,
and one of the major issues to be addressed for any free software
development process.  I've seen it with perl, Linux, fvwm, gcc, etc.

People just keep adding features, and more features, and more and more
features, and a "stable" release never comes out because with every
release that fixes bugs in the last set of features there are more
features to be debugged.

And it only gets worse the more time that elapses between some kind of
reference release, because people get worried that the _next_ "stable"
release will take as long as the last one, and they're all pushing to
get their favourite item into _this_ one so they don't have to wait a
few years for the next one, and then this one takes longer, etc. etc.

A vicious catch-22 :)

My opinion, FWIW, is that no more new features should be accepted,
period (okay, maybe the autoconf stuff can go in! :).  Make one release
with not a single new feature, but just whatever bug fixes there are,
then cut 2.1 if that looks reasonable after 3 weeks or so (give a hard
deadline to prod people into getting/installing the latest version).

The only way to get out of this is for someone to be hard-hearted and
say "forget it; you have to wait."  Not that these aren't the world's
greatest features, but a line has to be drawn, and kept.

Note this _only_ works if we can commit to getting the release _done_
within a month or so of the feature freeze.  Otherwise things will back
up too much and the dam will break again.

  ch>   - I hope that only one or two more 'betas' will be necessary after
  ch>     that before 2.1.0 can finially appear.  As I said, quite a bit is
  ch>     going into 2.0.47 and some bugs will have to be ironed out, but I
  ch>     think that it's finially getting close...  Hm...  Paul, does that
  ch>     sound familiar? :)

Yep :)

As I said above, IMO we will never be able to stop the "one or two more
betas" until we stop the "just a few more features".

-- 
-------------------------------------------------------------------------------
 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--Bay Networks takes no responsibility for them.

---

From: "Peter J. Weyers" <[email-masked]>
Date: Wed, 10 Dec 1997 12:03:11 +0100 (MET)

> My opinion, FWIW, is that no more new features should be accepted,

I very much agree!

Peter
,------------------------------------------------------------------------.
|+49-033762/77-452 : +49-030/2093-7812 :http://sugra.desy.de/user/weyers/|
`------------------------------------------------------------------------'

---

From: Dan Espen <[email-masked]>
Date: Wed, 10 Dec 1997 08:40:07 -0500

"Charles Hines" <[email-masked]> writes:
> Jason> patch posted here which purported to have done so.
> 

I didn't  originate the term  GSFR, so I  can't really say whether the
iconbox patch is it or not.  However, I did rewrite  all the code that
has to do with style flags, both the parsing and the access.

All the access is thru the function LookInList in add_window.c.  I got
rid of the huge number of args  this function required  and the way it
was returning the flags bits as  its return code.  I also consolidated
all the code it was doing 3 times for each of  the 3 possible matches.
Plus I managed  to remove all the  individual field initialization and
replace it with one memset.

As far  as the  parsing, I  still don't really   care for the  parsing
itself, but I   don't see anything wrong  with  the way the  flags are
stored now.

If there is a remaining Style flags problem, I don't see it.

Chuck, please take another look and share your thoughts with us.

--
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: "Charles Hines" <[email-masked]>
Date: Wed, 10 Dec 1997 10:11:31 -0500

>>>>> "Dan" == Dan Espen <[email-masked]> writes:

>> access the style flags in some way.

Dan> I didn't  originate the term  GSFR,

(That was me)

Dan> so I can't really say whether the iconbox patch is it or not.
Dan> However, I did rewrite all the code that has to do with style
Dan> flags, both the parsing and the access.

Not exactly the "access" I meant.  I'll explain below.

Dan> All the access is thru the function LookInList in add_window.c.  I got
Dan> rid of the huge number of args  this function required  and the way it
Dan> was returning the flags bits as  its return code.  I also consolidated
Dan> all the code it was doing 3 times for each of  the 3 possible matches.
Dan> Plus I managed  to remove all the  individual field initialization and
Dan> replace it with one memset.

And all of these changes were good, as that code needed cleaning up as
part of the GSFR.

Dan> As far  as the  parsing, I  still don't really   care for the  parsing
Dan> itself,

I'd like to make the parsing better as well (using the new parsing
routines I added a while back that probably still need some work
themselves), but that should wait.

Dan> but I don't see anything wrong with the way the flags are stored
Dan> now.

Dan> If there is a remaining Style flags problem, I don't see it.

Dan> Chuck, please take another look and share your thoughts with us.

Well, I think if I explain my idea for the GSFR, that would be a good
way to start.  I had started to put this into the TO-DO list, but
better to talk about it now, I guess.

Currently the style flags are checked and set (which is what I meant
by "accessed") via bit masks, which is why we only have 32 possible
flags.  Setting them & reading them is a "bit" odd (sorry for the bad
pun there):

        set:   tmp_win->flags |= ICONIFIED;
        clear: tmp_win->flags &= ~ICONIFIED;
        check: if (tmp_win->flags & ICONIFIED) {}

Now, adding a second (then third, then fourth, etc) style flag
variable would work to get around the lack of bits problem, obviously,
but there are a couple of problems with that:

        - when someone is writting code that needs to check them, they
          have to remember which mask goes with which flag variable
        - portions of the module code would have to be rewritten each
          time a new style flag variable was added, at both ends

So, what I thought of for the GSFR was this: change the flags variable
from an unsigned int accessed via bitmasks to a union of an array of
unsigned ints and bitfields, perhaps like this:

----------------------------------------------------------------------
typedef struct FvwmWindow
{
  ...
  union flags
  {
    unsigned int allflags[NUM_INTS_FOR_FLAGS];
    struct f
    {
      unsigned int StartIconic:1;
      unsigned int OnTop:1;
      unsigned int Sticky:1;
      unsigned int StickyIcon:1;
      unsigned int SuppressIcon:1;
      unsigned int NoIconTitle:1;
      unsigned int Lenience:1;
      unsigned int WindowListSkip:1;
      unsigned int CirculateSkip:1;
      unsigned int CirculateSkipIcon:1;
      unsigned int FocusPolicy:2; /* MOUSE, SLOPPY, CLICK, NEVER */
      unsigned int ShowOnMap:1;
      unsigned int Border:1;
      unsigned int Title:1;
      unsigned int Mapped:1;
      unsigned int Iconified:1;
      unsigned int Transient:1;
      unsigned int Raised:1;
      unsigned int Visible:1;
      unsigned int IconOurs:1;
      unsigned int PixmapOurs:1;
      unsigned int ShapedIcon:1;
      unsigned int Maximized:1;
      ...
    } f;
  } flags;
  ...
} FvwmWindow;
----------------------------------------------------------------------

So now, accessing them is something like so:

        set:   tmp_win->flags.f.Iconified = TRUE;
        clear: tmp_win->flags.f.Iconified = FALSE;
        check: if (tmp_win->flags.f.Iconified) {}

which is a bit more intuitive, and some #defines could probably be
used to hide the 'f.' portion to make it slightly more readable (or
perhaps that extra struct isn't needed, I'll have to test that).  And
no matter how many unsigned int's have to be added, you don't have to
remember which one each flag would fall under, because it's hidden
from you.

And the module code would use the NUM_INTS_FOR_FLAGS define to send
the whole bunch of flags to the modules (via the allflags array), who
would stuff these values into a local style flags union structure
(defined separately in the fvwm.h file for use in by whoever needs it
besides the FvwmWindow struct) for access as above, making that code
generic no matter how many uints are needed for the flags.

Plus, I think the style parsing code could use a local style flags
union structure to hold the values, using memcpy it into the new
FvwmWindow's when needed.

But, as you can see this would require a large amount of code to be
changed, which is why I called it the GSFR...

Plus, I don't know what kind of performance hit this would entail (if
any).  I would hope that on most systems the bitfield code generated
by the compiler would be relatively efficient, but I don't know.  I
should probably code up a small testcase to check this.

Discussion time: How does this all sound?  Is it a good idea, or is it
overkill?  Anyone have a simpler solution?  Etc...

Chuck

---

From: Dan Espen <[email-masked]>
Date: Wed, 10 Dec 1997 12:43:23 -0500

> unsigned ints and bitfields, perhaps like this:

Don't the modules need access  to the entire FvwmWindow structure, not
just the bitfields?

> FvwmWindow's when needed.

In the iconboxes patch, this is currently done like this:

  tmp_win->flags |= styles.on_flags & ALL_COMMON_FLAGS;

Ie. only the common flags  are copied.  We could  use a memcpy, but it
would leave  some  bits unused.  ALL_COMMON_FLAGS  seems  to represent
about 1/2 of the bits.

> should probably code up a small testcase to check this.

I just coded up a small test case.  I'll mail details if anyone wants.

I'm on Solaris 2.5  using Sun's compiler  version 4.0.  I checked  the
generated  code    using  no optimization,   level    2 and   level  5
optimization.  In all  cases the generated  code is less efficient.  I
used an array  of 2 integers.  It looks  like the compiler  insists on
trying to shift the bit in question out of the array regardless of how
many hints it has about the size of the array and the bit in question.

There were almost twice as many instructions generated.  I didn't time
them.

Is this enough to decide not to use the union?

> overkill?  Anyone have a simpler solution?  Etc...

I didn't see any problem with the flags vs flags2 solution, so I guess
thats why I was clueless about what GSFR meant.

Perhaps some macros for access and setting would be better:

#define ICONIFY_FLAG flags.Iconified
#define NEW_FLAG flags2.new

This has the advantage  of not requiring  everything to be changed  at
once.

---

From: [email-masked] (Paul D. Smith)
Date: 10 Dec 1997 12:55:53 -0500

%% "Charles Hines" <[email-masked]> writes:

  ch> Currently the style flags are checked and set (which is what I meant
  ch> by "accessed") via bit masks, which is why we only have 32 possible
  ch> flags.  Setting them & reading them is a "bit" odd (sorry for the bad
  ch> pun there):

  ch>         set:   tmp_win->flags |= ICONIFIED;
  ch>         clear: tmp_win->flags &= ~ICONIFIED;
  ch>         check: if (tmp_win->flags & ICONIFIED) {}

I usually use handy-dandy macros to make this a bit neater: SET_FLAG,
RESET_FLAG, IS_SET, etc.  But whatever :)

  ch> Now, adding a second (then third, then fourth, etc) style flag
  ch> variable would work to get around the lack of bits problem, obviously,
  ch> but there are a couple of problems with that:

  ch>         - when someone is writting code that needs to check them, they
  ch>           have to remember which mask goes with which flag variable
  ch>         - portions of the module code would have to be rewritten each
  ch>           time a new style flag variable was added, at both ends

Yes, as I said in my last mail (did that go to workers?  I'm confused
now :) I don't like this either.

  ch> So, what I thought of for the GSFR was this: change the flags variable
  ch> from an unsigned int accessed via bitmasks to a union of an array of
  ch> unsigned ints and bitfields, perhaps like this:

  ch> typedef struct FvwmWindow
  ch> {
  ch>   ...
  ch>   union flags
  ch>   {
  ch>     unsigned int allflags[NUM_INTS_FOR_FLAGS];
  ch>     struct f
  ch>     {
  ch>       unsigned int StartIconic:1;
  ch>       ...
  ch>     } f;
  ch>   } flags;
  ch>   ...
  ch> } FvwmWindow;

I would make the bitfields a totally separate typedef, instead of
embedding it into the FvwmWindow structure.  I don't see a need for the
union at all, you could just put all the bitfields into a struct, then
you can pass the struct as a whole without even really knowing how large
it is.  What is the allflags array for?

E.g., why not use this:

  typedef struct FvwmWindow_flags {
    unsigned int StartIconic:1;
     ...
  } FvwmWindow_flags;

  typedef struct FvwmWindow {
     ...
    FvwmWindow_flags    flags;
     ...
  } FvwmWindow;

  ch> So now, accessing them is something like so:

  ch>         set:   tmp_win->flags.f.Iconified = TRUE;
  ch>         clear: tmp_win->flags.f.Iconified = FALSE;
  ch>         check: if (tmp_win->flags.f.Iconified) {}

Using my suggestion above, it's just:

  win->flags.StartIconic = TRUE;

  ch> And the module code would use the NUM_INTS_FOR_FLAGS define to send
  ch> the whole bunch of flags to the modules (via the allflags array), who
  ch> would stuff these values into a local style flags union structure
  ch> (defined separately in the fvwm.h file for use in by whoever needs it
  ch> besides the FvwmWindow struct) for access as above, making that code
  ch> generic no matter how many uints are needed for the flags.

Can't you just send the whole win->flags struct to the modules, rather
than the array?  send(&win->flags, sizeof(FvwmWindow_flags)) should be
sufficient I think.  I guess I don't know too much about how this works.

Also, you can take the broken-out typedef I had above, FvwmWindow_flags,
and define that in fvwm.h and then use it in misc.h and also elsewhere,
so everyone is using the exact same typedef instead of a local copy.

  ch> Plus, I think the style parsing code could use a local style flags
  ch> union structure to hold the values, using memcpy it into the new
  ch> FvwmWindow's when needed.

If you use a struct you can just assign them, you don't need memcpy.
This works in ISO C:

  FvwmWindow_flags a, b;

  a.StartIconic = true;

  b = a;

(of course this works for a union, too).

  ch> Plus, I don't know what kind of performance hit this would entail
  ch> (if any).  I would hope that on most systems the bitfield code
  ch> generated by the compiler would be relatively efficient, but I
  ch> don't know.  I should probably code up a small testcase to check
  ch> this.

I'm sure that the compiler's handling of bitfields is at least as good
as doing it "by hand".

  ch> Discussion time: How does this all sound?  Is it a good idea, or is it
  ch> overkill?  Anyone have a simpler solution?  Etc...

My only concern with this is you're restricting fvwm to compilers which
support bitfields, but I guess we're already pretty much assuming an ISO
C compiler, so that's no big deal.

---

From: Greg Badros <[email-masked]>
Date: 10 Dec 1997 10:01:59 -0800

> Is this enough to decide not to use the union?

IMHO, it shouldn't be.  Clarity of code, ease of evolution, and
simplicity of design all take priority over a couple of cycles.  fvwm2
is plenty fast already, and needs to be written more cleanly and
extensibly.

> This has the advantage  of not requiring  everything to be changed  at

If you stick with the current flags implementation, then it makes more
sense to add macros like ICONIFY_FLAG_P(window) and
SET_ICONIFY_FLAG(window) and RESET_ICONIFY_FLAG(window) to abstract out
the bit manipulations, etc., not just to abstract out the bit
locations.  Then you could switch to a union implementation only be
rewriting the macros and the window structure.

We're planning on doing a similar rewrite for scwm in the not too
distant future since the code there is just horendous (e.g., the
WINDOW_SHADE patch exploits the high bit of another field instead of
adding a new byte/word to the structure!  crazy!)

Greg J. Badros
[email-masked]
Seattle, WA  USA
http://www.cs.washington.edu/homes/gjb

---

From: [email-masked] (Paul D. Smith)
Date: 10 Dec 1997 14:01:05 -0500

%% Dan Espen <[email-masked]> writes:

  de> I just coded up a small test case.  I'll mail details if anyone wants.

Me, please.

  de> There were almost twice as many instructions generated.  I didn't time
  de> them.

  de> Is this enough to decide not to use the union?

It definitely gives me pause.  I'll look at your test and try it with
GCC and if it's that bad, then maybe we should think again.  If GCC does
a good job, then I don't care and I vote for bitfields :)

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

  gb> If you stick with the current flags implementation, then it makes
  gb> more sense to add macros like ICONIFY_FLAG_P(window) and
  gb> SET_ICONIFY_FLAG(window) and RESET_ICONIFY_FLAG(window) to
  gb> abstract out the bit manipulations, etc., not just to abstract out
  gb> the bit locations.  Then you could switch to a union
  gb> implementation only be rewriting the macros and the window
  gb> structure.

Oof.  I'd hate to see 3 macros defined for every flag!  That's some
serious code obfuscation IMO.

I think we should just go ahead and fix it.  If bitfields are too
expensive, we can use an array and hide it behind generic macros:

  SET_FLAG(flags, ICONIFY_FLAG);
  RESET_FLAG(flags, ICONIFY_FLAG);
  if (IS_SET(flags, ICONIFY_FLAG) ...

etc.  As an example, SET_FLAG would be something like:

  #define VSZ   (sizeof(unsigned long)*CHAR_BIT)

  #define SET_FLAG(_v,_f)   ((_v)[(_f)/VSZ]|=((_f)%VSZ))

(I just wrote this off the top of my head but I think it's correct) if
the flag array is of type (unsigned long *).  The others easily derived
from this.

Although that seems like a lot of calculation, remember that _f and VSZ
are both constants, so the compiler will do all that calculation for you
at compile time, not runtime.

---

From: lar3ry gensch <[email-masked]>
Date: Wed, 10 Dec 1997 13:41:14 -0500 (EST)

>       unsigned int FocusPolicy:2; /* MOUSE, SLOPPY, CLICK, NEVER */

A little nit:

Wouldn't it be even nicer to use:

	enum focuspolicy {
	    MOUSE_FOCUS,
	    SLOPPY_FOCUS,
	    CLICK_TO_FOCUS,
	    NEVER_FOCUS
	 } FocusPolicy:2;

rather than

This way, you can see what the possible values are at the point of
definition, rather than having the enumerations being listed
elsewhere (and only listed via a comment).

Using an enum can also allow the compiler to ensure that only the
proper values may be placed into the bitfield (i.e., moving a zero
into that field might issue a compiler warning).

Finally, if you add a couple of focus policies later on (such as, say,
FOCUS_20_SECONDS_TOO_LATE, for a silly example), the compiler may also
be able to issue a warning if the number of bits in the bitfield will
not be able to hold the maximum and minimum values.

I've always been a big fan of having the compiler do as much of the
work as possible.  Issuing values for enumerations is a good thing
that the compiler can do.  Providing warning messages when (obvious)
good intentions fail is another.

Finally, when having to debug code, the debugger can possibly show us
the value of our enumeration (eg, 'print f.flags.f.FocusPolicy' can
show the value 'CLICK_TO_FOCUS').

Now, I'm not sure if this is 100% legal ANSI C.  I *did* check it
using 'gcc -ansi -pedantic -Wall' and Digital C, but this only shows us
what the compilers' authors think.  But, even if there are some
compilers that don't support enum bitfields, we could have autoconf
(when it gets working) check for it, and wrap the code as follows:

#ifdef HAVE_ENUM_BITFIELDS
	enum focuspolicy {
	    MOUSE_FOCUS,
	    SLOPPY_FOCUS,
	    CLICK_TO_FOCUS,
	    NEVER_FOCUS
	 } FocusPolicy:2;
#else
	unsigned int FocusPolicy:2;
# define MOUSE_FOCUS		(0)
# define SLOPPY_FOCUS		(1)
# define CLICK_TO_FOCUS		(2)
# define NEVER_FOCUS		(3)
#endif

This gives us the option of having our values checked by compilers
that support the enum-bitfields (to keep us honest), while being able
to still be compiled by the most pedantic compilers.

-- 
(void) lar3ry();                                      [email-masked]

     "Sometimes it happens.  People just explode.  Natural causes."

---

From: Dan Espen <[email-masked]>
Date: Wed, 10 Dec 1997 15:29:27 -0500

>   de> I just coded up a small test case.  I'll mail details if anyone wants.

OK.

Heres bitf.c:

#include <stdio.h>
#define NUM_INTS_FOR_FLAGS 2
typedef struct FvwmWindow
{
  union flags
  {
    unsigned int allflags[NUM_INTS_FOR_FLAGS];
    struct f
    {
      unsigned int StartIconic:1;       /* 1 */
      unsigned int OnTop:1;             /* 2 */
      unsigned int Sticky:1;
      unsigned int StickyIcon:1;
      unsigned int SuppressIcon:1;      /* 5 */
      unsigned int NoIconTitle:1;
      unsigned int Lenience:1;
      unsigned int WindowListSkip:1;
      unsigned int CirculateSkip:1;
      unsigned int CirculateSkipIcon:1; /* 10 */
      unsigned int FocusPolicy:2; /* MOUSE, SLOPPY, CLICK, NEVER */
      unsigned int ShowOnMap:1;
      unsigned int Border:1;
      unsigned int Title:1;             /* 15 */
      unsigned int Mapped:1;
      unsigned int Iconified:1;
      unsigned int Transient:1;
      unsigned int Raised:1;
      unsigned int Visible:1;
      unsigned int IconOurs:1;
      unsigned int PixmapOurs:1;
      unsigned int ShapedIcon:1;
      unsigned int Maximized:1;         /* 24 */
      unsigned int t25:1;
      unsigned int t26:1;
      unsigned int t27:1;
      unsigned int t28:1;
      unsigned int t29:1;
      unsigned int t30:1;
      unsigned int t31:1;
      unsigned int t32:1;
      unsigned int t33:1;
      unsigned int t34:1;
      unsigned int t35:1;
      unsigned int t36:1;
    } f;
  } flags;
} FvwmWindow;

FvwmWindow tmp_win;

unsigned long old_way;

main() {

  tmp_win.flags.f.Iconified = 1;
  if (tmp_win.flags.f.Iconified) {
    printf("It's on\n");
  }
  tmp_win.flags.f.Iconified = 0;
  if (!tmp_win.flags.f.Iconified) {
    printf("It's off\n");
  }
  tmp_win.flags.f.t36 = 1;
  if (tmp_win.flags.f.t36) {
    printf("It's on\n");
  }

#define ICONIFIED 2
  old_way &= ~ICONIFIED;
  old_way |= ICONIFIED;
  if (old_way & ICONIFIED) {
    printf("It's on\n");
  }
}

And, without optimization bitf.s (I've trimmed out some useless stuff):

!   54	main() {
!   55	
!   56	  tmp_win.flags.f.Iconified = 1;

	sethi	%hi(tmp_win),%l3
	or	%l3,%lo(tmp_win),%l3
	mov	1,%l0
	and	%l0,1,%l0
	sll	%l0,15,%l2
	ld	[%l3+0],%l0
	sethi	32,%l1
	xor	%l1,-1,%l1
	and	%l0,%l1,%l0
	or	%l0,%l2,%l0
	st	%l0,[%l3+0]

!   57	  if (tmp_win.flags.f.Iconified) {

	sethi	%hi(tmp_win),%l0
	or	%l0,%lo(tmp_win),%l0
	ld	[%l0+0],%l0
	srl	%l0,15,%l0
	and	%l0,1,%l0
	cmp	%l0,%g0
	be	.L80
	nop

	! block 2
.L81:

!   58	    printf("It's on\n");

	sethi	%hi(.L82),%l0
	or	%l0,%lo(.L82),%l0
	mov	%l0,%o0
	call	printf
	nop

	! block 3
.L80:

!   59	  }
!   60	  tmp_win.flags.f.Iconified = 0;

	sethi	%hi(tmp_win),%l3
	or	%l3,%lo(tmp_win),%l3
	mov	0,%l0
	and	%l0,1,%l0
	sll	%l0,15,%l2
	ld	[%l3+0],%l0
	sethi	32,%l1
	xor	%l1,-1,%l1
	and	%l0,%l1,%l0
	or	%l0,%l2,%l0
	st	%l0,[%l3+0]

!   61	  if (!tmp_win.flags.f.Iconified) {

	sethi	%hi(tmp_win),%l0
	or	%l0,%lo(tmp_win),%l0
	ld	[%l0+0],%l0
	srl	%l0,15,%l0
	and	%l0,1,%l0
	cmp	%l0,%g0
	bne	.L83
	nop

	! block 4
.L84:

!   62	    printf("It's off\n");

	sethi	%hi(.L85),%l0
	or	%l0,%lo(.L85),%l0
	mov	%l0,%o0
	call	printf
	nop

	! block 5
.L83:

!   63	  }
!   64	  tmp_win.flags.f.t36 = 1;

	sethi	%hi(tmp_win),%l3
	or	%l3,%lo(tmp_win),%l3
	mov	1,%l0
	and	%l0,1,%l0
	sll	%l0,28,%l2
	ld	[%l3+4],%l0
	sethi	262144,%l1
	xor	%l1,-1,%l1
	and	%l0,%l1,%l0
	or	%l0,%l2,%l0
	st	%l0,[%l3+4]

!   65	  if (tmp_win.flags.f.t36) {

	sethi	%hi(tmp_win),%l0
	or	%l0,%lo(tmp_win),%l0
	ld	[%l0+4],%l0
	srl	%l0,28,%l0
	and	%l0,1,%l0
	cmp	%l0,%g0
	be	.L86
	nop

	! block 6
.L87:

!   66	    printf("It's on\n");

	sethi	%hi(.L88),%l0
	or	%l0,%lo(.L88),%l0
	mov	%l0,%o0
	call	printf
	nop

	! block 7
.L86:

!   67	  }
!   68	
!   69	#define ICONIFIED 2
!   70	  old_way &= ~ICONIFIED;

	sethi	%hi(old_way),%l0
	or	%l0,%lo(old_way),%l0
	ld	[%l0+0],%l0
	and	%l0,-3,%l1
	sethi	%hi(old_way),%l0
	or	%l0,%lo(old_way),%l0
	st	%l1,[%l0+0]

!   71	  old_way |= ICONIFIED;

	sethi	%hi(old_way),%l0
	or	%l0,%lo(old_way),%l0
	ld	[%l0+0],%l0
	or	%l0,2,%l1
	sethi	%hi(old_way),%l0
	or	%l0,%lo(old_way),%l0
	st	%l1,[%l0+0]

!   72	  if (old_way & ICONIFIED) {

	sethi	%hi(old_way),%l0
	or	%l0,%lo(old_way),%l0
	ld	[%l0+0],%l0
	and	%l0,2,%l0
	cmp	%l0,%g0
	be	.L89
	nop

	! block 8
.L90:

!   73	    printf("It's on\n");

	sethi	%hi(.L91),%l0
	or	%l0,%lo(.L91),%l0
	mov	%l0,%o0
	call	printf
	nop

	! block 9

So to set a bit the new way (11 instructions):

!   56	  tmp_win.flags.f.Iconified = 1;

	sethi	%hi(tmp_win),%l3
	or	%l3,%lo(tmp_win),%l3
	mov	1,%l0
	and	%l0,1,%l0
	sll	%l0,15,%l2
	ld	[%l3+0],%l0
	sethi	32,%l1
	xor	%l1,-1,%l1
	and	%l0,%l1,%l0
	or	%l0,%l2,%l0
	st	%l0,[%l3+0]

Vs. the old way (7 instructions):

!   71	  old_way |= ICONIFIED;

	sethi	%hi(old_way),%l0
	or	%l0,%lo(old_way),%l0
	ld	[%l0+0],%l0
	or	%l0,2,%l1
	sethi	%hi(old_way),%l0
	or	%l0,%lo(old_way),%l0
	st	%l1,[%l0+0]

Optimization gave  less instructions in   both  cases, but  it  looked
similar.

>  Paul D. Smith <[email-masked]>         Network Management Developmen

---

From: lar3ry gensch <[email-masked]>
Date: Wed, 10 Dec 1997 13:41:14 -0500 (EST)

A little nit:

	enum focuspolicy {
	    MOUSE_FOCUS,
	    SLOPPY_FOCUS,
	    CLICK_TO_FOCUS,
	    NEVER_FOCUS
	 } FocusPolicy:2;

rather than

---

From: Jason L Tibbitts III <[email-masked]>
Date: 10 Dec 1997 14:41:02 -0600

>>>>> "GB" == Greg Badros <[email-masked]> writes:

GB> We're planning on doing a similar rewrite for scwm in the not too
GB> distant future since the code there is just horendous (e.g., the
GB> WINDOW_SHADE patch exploits the high bit of another field instead of
GB> adding a new byte/word to the structure!  crazy!)

Time and time again we've seen projects branch from FVWM (Bowman,
AfterStep, FVWM95, Enlightenment, scwm, probably more) and with the
exception of FVWM95 (and the wharf from AfterStep, I suppose) none of it
ever comes back into the core.  Why is this?  It seems we'd get a whole
bunch more work done if, say, the the GSFR only had to be done once instead
of repeatedly for every divergent branch.  I don't recall that any of the
branch developers tried to find a way to do what they wanted without
branching.  And after something like the GSFR is done (differently) for
each branch, a merge becomes essentially impossible.  So we're left with
several more window managers, which confuses and partitions the users and
divides up the available development manpower.

I wish that before things between, say, fvwm and scwm diverge too far, at
least a little thought would be put in to decide how to put them together.
Could we have a core which handles communication between modules and deals
with event bindings, define the necessary interfaces, and write everything
else as modules (drawing/decoration, user input, configuration/interaction
language, etc.)?  If it were done via shared libraries it would probably
have less overhead (performance and memory) and more flexibility than the
current modules-as-programs implementation.

I suppose it's a bit idealistic, but I think that if all of the programming
talent that has fractured between the various near-branches of fvwm could
converge for just a few months it could all be dome.  scwm and fvwm are
both looking at reasonably large changes in the near term anyway.

 - J<

---

From: "David A. Rogers" <[email-masked]>
Date: Wed, 10 Dec 1997 14:55:57 -0600

>        unsigned int FocusPolicy:2; /* MOUSE, SLOPPY, CLICK, NEVER */

Yeah, I like this approach for things like this that make sense.  For
things that are truly boolean, I think it makes sense to use a magic cookie
approach.  typedef whatever you like to the magic cookie type and use
setter, unsetter, and getter functions to process the magic cookie.  Then
you can change your mind about how to implement at a later date.

Encapsulation.  Its a good thing.

Regards,
David

---

From: Greg Badros <[email-masked]>
Date: 10 Dec 1997 13:04:04 -0800

> branching.  And after something like the GSFR is done (differently) for

I agree completely w.r.t., e.g., Fvwm95 and AfterStep.  For SCWM,
however, we're not looking for a visual change, but a fundamental
rewrite replacing the static configuration language with guile scheme.
This is something you can't do incrementally and can't merge back in.

> least a little thought would be put in to decide how to put them together.

Too late-- even a month ago the scwm code was too far removed from fvwm
to even hand-patch my menu animation change that I made to fvwm2 into
the working scwm version.  I instead did a much nicer rewrite from scratch.

> current modules-as-programs implementation.

This is exactly what scwm is designed to be; we already have the menu
drawing code abstracted out, we are ripping the window decoration stuff
out, and we're reworking the event model completely.

> both looking at reasonably large changes in the near term anyway.

Ideally, scwm can be that one window manager that people can add
features to and customize arbitrarily while staying within the basic
framework (i.e., not needing to separate off new wm-s to add simple
primitives).   fvwm2's fundamental infrastructure is terribly lacking,
so staying inside fvwm2 would've been far too constraining for what
we're doing.   I'd really like to see fvwm2 stabilize with the changes
Charles has on the table now, and that be the end of fvwm2.  Then have
more people working on scwm, porting different WM's decorations to the
scwm interface, etc.  Believe me, it's a lot nicer to work with a wm
fully supported by a real, increasingly-popular language like Guile than 
to hand-parse every argument and implement each dynamic feature in an
ad-hoc way.

We're really striving to make scwm an upgrade path for fvwm2 users--
I've worked out most of a legacy module interface to provide access to
fvwm2 modules in Scheme code, with only limited C support.  The scwm
binary is smaller than fvwm2 because so much code duplication is
eliminated.  (The memory image is bigger, but that's mostly due to
guile, not fundamental to scwm).  Hopefully we'll also have a script to
aid converting .fvwm2rc to scwmrc-s, etc.

Yes, one extensible window manager should be enough.  But that window
manager is *not* fvwm2 -- not without major changes.  The scwm project
was born out of a desire to not reimplement the wheel and is positioned
to become the "Emacs of Window Managers", made even more powerful by
dynamically loaded C extensions implementing clean interfaces to lots of 
useful functionality.

Greg J. Badros
[email-masked]
Seattle, WA  USA

---

From: Jason L Tibbitts III <[email-masked]>
Date: 10 Dec 1997 15:45:43 -0600

>>>>> "GB" == Greg Badros <[email-masked]> writes:

GB> I agree completely w.r.t., e.g., Fvwm95 and AfterStep.  For SCWM,
GB> however, we're not looking for a visual change, but a fundamental
GB> rewrite replacing the static configuration language with guile
GB> scheme.

I wasn't either.  I still don't see the need for a complete development
split, but maybe it's too late now.

GB> Too late-- even a month ago the scwm code was too far removed from fvwm
GB> to even hand-patch my menu animation change that I made to fvwm2 into
GB> the working scwm version.

I don't recall even hearing about it until even a month ago, which would
mean that the divergence happened without even being talked about here.
Too bad.  (Forgive my memory if I'm wrong, but do correct it.)  The
earliest mention of scwm in the list archives came in September with Bruce
Stephens saying basically the same things I'm saying, but no additional
messages from anyone involved with scwm.

I'm not trying to slight anybody, but all of this divergence just doesn't
seem to be in the spirit of cooperation that this free software thing is
supposed to be.  Saying "our way is superior" isn't any kind of
justification.  Saying "we tried to talk about it and nobody listened"
definitely is, but I just don't recall any of that.

GB> This is exactly what scwm is designed to be; we already have the menu
GB> drawing code abstracted out, we are ripping the window decoration stuff
GB> out, and we're reworking the event model completely.

But why does this all have to be tied to scheme?.  It's not really that bad
and if no better alternative comes about then I suppose I'll have no other
choice, but the language should be just another module that tells the core
what events to bind (and feeds events to the core itself).  The language
should not _be_ the core.

GB> Yes, one extensible window manager should be enough.  But that window
GB> manager is *not* fvwm2 -- not without major changes.

But you made those major changes.  You could have picked up all of the fvwm
development effort for free if you had wanted to, just by saying "here's a
plan for fvwm3; I'm going to eventually do this anyway but I want to
include you folks in it."  Now we have confusion and work going towards
post-2.1 fvwm that could be going into your project.  (You could say,
though, that you'd never get any consensus, but that's hard to say.)

GB> The scwm project was born out of a desire to not reimplement the wheel
GB> and is positioned to become the "Emacs of Window Managers",

You don't really want to say that, do you?  Emacs may be the paragon of
extensibility, but the price is a lot more than some people want to pay for
a few rectangles with buttons.  (I do everything in emacs, but I'm not sure
I want it managing my windows.)

In the spirit of optimism I'll say that its never too late to do anything,
but that scwm may already have gone in a direction that the fvwm folks just
don't find interesting.  I don't really know.  Am I the only one that
really cares about this?  Does anyone besides Greg and I have an opinion
here?

 - J<

---

From: Dan Espen <[email-masked]>
Date: Wed, 10 Dec 1997 17:08:25 -0500

Jason L Tibbitts III <[email-masked]> writes:
> 
> In the  spirit of optimism  I'll say that  its never too late  to do
> anything, but  that scwm may already have  gone in a  direction that
> the fvwm  folks just don't find interesting.   I don't  really know.
> Am I the only one that really cares about this?  Does anyone besides
> Greg and I have an opinion here?

Jason,

  It's like you read my mind.

  There must be a way that we can all work together.

  In scwm's defense,  I notice that there seems to be active development
in the ctwm camp, so I guess that fvwm2 is a spinoff also.

  But really, we are only making a tiny fraction of the progess possible
with all these variants.  Its a damn shame.

---

From: Greg Badros <[email-masked]>
Date: 10 Dec 1997 14:18:41 -0800

> messages from anyone involved with scwm.

As much as we'd like to think it, fvwm2 is *not* the only wm around.
There was only a slight bit more reason to discuss scwm's inception on
the fvwm2 list as there was to discuss it on the gwm list or the
afterstep list, etc.  The bottom line is that several people
independently thought that lots of the window managers out there were
getting it all wrong, and wanted to get it right.  Fvwm2 was a
reasonable starting place, but GWM was almost used.  Scwm was born not
out of a "geez, if only fvwm2 could do this", but more out of a "we want 
a wm like this and fvwm2 might be a place to start to get up and running 
quickly".

> definitely is, but I just don't recall any of that.

But our way is superior! :-)

The biggest reason scwm was not discussed here (given my remarks above)
is that I was not the one who split it off, and only got involved in
scwm development at version 0.2.

> But why does this all have to be tied to scheme?.  It's not really that bad

It doesn't have to be tied to scheme at all-- that's why we chose Guile
since it's one of their goals to have Scheme, Ctax, Lisp, etc., all
working from the same infrastructure.  I considered using perl for a
while, but guile's multiple front-ends and simplicity were hard to overlook.

> should not _be_ the core.

I tend to disagree.  Scwm is guile with primitives for managing
windows.  The language is the framework within which the window manager
is written.  I think choosing to make the language infrastructure
decision a module would've unnecessarily complicated the design
dramatically.  The point is getting a real language available to the
window manager and its configuration.

> though, that you'd never get any consensus, but that's hard to say.)

There are others who work on fvwm2 who are interested in scwm.  One of
the reasons for branching from fvwm2 was that it has one of the most
active development communities, and we can provide a reasonable upgrade
path.  If it's pretty painless to switch to scwm from fvwm, then I see
no reason for fvwm2 development to continue (certainly my efforts will
be directed elsewhere, but my efforts are such a tiny fraction of fvwm2
that it's insignificant) after the next stable version.  We want scwm to 
provide a superset of the functionality and configurability of fvwm2,
and it pretty much already does (not counting modules as that piece
still does not work).

> I want it managing my windows.)

Right, and there are other wm-s for those who value low memory
consumption in exchange for configurability.  e.g., wm2, fvwm1 (and to a 
lesser extent fvwm2).

> really cares about this?  Does anyone besides Greg and I have an opinion

Scwm isn't for all fvwm2 folks -- it's a fundamental rethinking of what
a wm could (and should, to us) be.  As such, it's never going to be
fvwm3, but we think it's a more useful place for developer energy to
focus.

Greg J. Badros
[email-masked]
Seattle, WA  USA

---

From: Jason L Tibbitts III <[email-masked]>
Date: 10 Dec 1997 16:21:56 -0600

>>>>> "DE" == Dan Espen <[email-masked]> writes:

DE> In scwm's defense, I notice that there seems to be active development
DE> in the ctwm camp, so I guess that fvwm2 is a spinoff also.

Oops; I forget that fvwm is in no way the original.  I can only say that
when people started up different development projects back then, things
were different.  Now I think there has to be a major push for quality and
that development groups can't be frivolous with talent.  The fact that it
happened before is no reason for it to happen now.

DE> But really, we are only making a tiny fraction of the progess possible
DE> with all these variants.  Its a damn shame.

It seems to be that way all over.  Emacs/XEmacs, Gnome/KDE, etc.  But with
fvwm we have no "RMS attitude" and no Qt license issues.  Instead we have
two pieces of software with essentially the same design philosophies and
implementation.

 - J<

---

From: Greg Badros <[email-masked]>
Date: 10 Dec 1997 14:27:18 -0800

> It seems to be that way all over.  Emacs/XEmacs, Gnome/KDE, etc.  But with

FWIW, scwm is part of the Gnome project last I heard.

Greg

---

From: Greg Badros <[email-masked]>
Date: 10 Dec 1997 14:25:02 -0800

> in the ctwm camp, so I guess that fvwm2 is a spinoff also.

And I'd claim that the difference between scwm and fvwm2 (now only 3
months into development, or so) is more fundamental (if not greater)
than between fvwm2 and ctwm.

> with all these variants.  Its a damn shame.

Our hope with scwm is to be a superset of a handful of wm-s, and invite
development to continue on scwm alone.  If fvwm2, ctwm, piewm, Afterstep, 
etc., users all could switch to scwm painlessly, then maybe we'd have a
chance of combining these efforts.  Some window managers (e.g., wm2)
have fundamentally different goals (really small memory footprint) and
the best we'll be able to do is get a module for their look so people
who like the look can have it w/o giving up the behavioural flexibility
of scwm.

Greg

---

From: Jason L Tibbitts III <[email-masked]>
Date: 10 Dec 1997 16:41:45 -0600

>>>>> "GB" == Greg Badros <[email-masked]> writes:

GB> As much as we'd like to think it, fvwm2 is *not* the only wm
GB> around.

Never said it was.  It doesn't really affect things.

GB> The bottom line is that several people independently thought that lots
GB> of the window managers out there were getting it all wrong, and wanted
GB> to get it right.

But if they were all 'wrong', why didn't you start from scratch?

GB> Fvwm2 was a reasonable starting place, but GWM was almost used.  Scwm
GB> was born not out of a "geez, if only fvwm2 could do this", but more out
GB> of a "we want a wm like this and fvwm2 might be a place to start to get
GB> up and running quickly".

Wouldn't it have been nicer to get up and running with all of the
development folks, too?  You see, I still haven't seen a good reason.

GB> The biggest reason scwm was not discussed here (given my remarks above)
GB> is that I was not the one who split it off, and only got involved in
GB> scwm development at version 0.2.

I'm beginning to realize that after reading the announcements.

GB> It doesn't have to be tied to scheme at all-- that's why we chose Guile
GB> since it's one of their goals to have Scheme, Ctax, Lisp, etc., all
GB> working from the same infrastructure.  I considered using perl for a
GB> while, but guile's multiple front-ends and simplicity were hard to
GB> overlook.

Perl is probably too heavy for this.  (I use perl for just about everything
I do, but like emacs I don't want it in my window manager.) 

>> and if no better alternative comes about then I suppose I'll have no
>> other choice, but the language should be just another module that tells
>> the core what events to bind (and feeds events to the core itself).  The
>> language should not _be_ the core.

GB> I tend to disagree.

In light of your previous paragraph (quoted above), this seems to be
contradictory.  If its language independent to the degree that you could
use perl if you wanted to, then you have a library.  Or have I
misunderstood you?

GB> There are others who work on fvwm2 who are interested in scwm.  One of
GB> the reasons for branching from fvwm2 was that it has one of the most
GB> active development communities, and we can provide a reasonable upgrade
GB> path.

Again, I ask: then why branch at all?  The feeling I get is that something
like scwm was what just about everyone involved with fvwm has wanted.

GB> If it's pretty painless to switch to scwm from fvwm, then I see no
GB> reason for fvwm2 development to continue (certainly my efforts will be
GB> directed elsewhere, but my efforts are such a tiny fraction of fvwm2
GB> that it's insignificant) after the next stable version.

But that begs the same question again.  The point is that if everyone
involved makes the effort, scwm could be _the_ upgrade path.  (Although it
might be nice to capitalize on the name recognition and call it fvwmSC or
something.)

GB> Scwm isn't for all fvwm2 folks -- it's a fundamental rethinking of what
GB> a wm could (and should, to us) be.  As such, it's never going to be
GB> fvwm3, but we think it's a more useful place for developer energy to
GB> focus.

How can you say what fvwm3 would be?  Especially if scwm hadn't
fragmented...

Besides, it looks as if fvwm3 may never exist because the spinoffs have
sucked away the critical mass of interest.  That makes scwm as good a
choice as any, and perhaps a better choice than most.

If I'm not confused, you still need to deal with the popular fvwm modules.
There's some good functionality there, and I hope that the plan wasn't to
just split development of the modules, too.

 - J<

---

From: Jason L Tibbitts III <[email-masked]>
Date: 10 Dec 1997 16:49:25 -0600

>>>>> "GB" == Greg Badros <[email-masked]> writes:

GB> FWIW, scwm is part of the Gnome project last I heard.

On the Gnome list just yesterday I believe they said they don't want to
connect it to a window manager.  I'll have to look up a reference....

Here's one (sorry for not doing proper MIME inclusion):

To: Edward Betts <[email-masked]>
Cc: [email-masked]
Subject: Re: Is gnome a windows manager?
References: <[email-masked]>
X-Url: http://www.jimpick.com/
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Sat_Dec__6_16:07:43_1997-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
From: Jim Pick <[email-masked]>
Date: 06 Dec 1997 16:08:00 -0800
In-Reply-To: Edward Betts's message of "Sat, 6 Dec 1997 10:17:13 -0000"
Message-ID: <[email-masked]>
X-Mailer: Gnus v5.4.66/XEmacs 20.2
X-Face:  Hz"C77\53<,u1}C~=DFwS#Ddj161XLl6W!3g7xjxh*P'`FF^-IYQXX$a*WC~=^8rvy"~<3z
 UeQqGo&KZe[}lJg`\+SDMGRVIUJ~P,#(=w~yYv{g9i%"k|\J|jYVvv^Bzfwo=@AddrDMO<xV_IAl`(
 TW7;|vH6Kik(,iljluXex0vrnM:SedI@lbAeNvM
Sender: [email-masked]
Precedence: bulk
Lines: 47
Xref: sina.hpc.uh.edu gnome:566

--pgp-sign-Multipart_Sat_Dec__6_16:07:43_1997-1
Content-Type: text/plain; charset=US-ASCII

Edward Betts <[email-masked]> writes:

> but where is the windows manager? is there something like
> startkde ?? I have played with some of the programs, but i am yet to find
> the windows manager

Gnome does not include a window manager.  It should be able to run with
any window manager.  Think of it as more of a collection of applications
and libraries.  Try the 'panel' application - it will create an application
launching menu at the bottom of your screen.  You can access the other
Gnome apps from there.

Maciej Stachowiak is a Gnome contributor and is working on a Scheme based
window manager:

http://web.mit.edu/mstachow/www/scwm.html

It will probably work very nicely with Gnome (I haven't tried it yet).  But,
I think it's been decided that Gnome is not going to depend on or prefer any
single window manager.

Cheers,

 - Jim

--pgp-sign-Multipart_Sat_Dec__6_16:07:43_1997-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--pgp-sign-Multipart_Sat_Dec__6_16:07:43_1997-1--

 - J<

---

From: Jason L Tibbitts III <[email-masked]>
Date: 10 Dec 1997 17:05:54 -0600

>>>>> "GB" == Greg Badros <[email-masked]> writes:

GB> And I'd claim that the difference between scwm and fvwm2 (now only 3
GB> months into development, or so) is more fundamental (if not greater)
GB> than between fvwm2 and ctwm.

Not from where I see it.  To me, over ctwm fvwm2 has modules and an attempt
at an internal language.  Over fvwm2, scwm has, a real internal language,
which is something that we always wanted fvwm to have.  I don't see much
difference at all.  Sure, it has substantive code differences but not
substantive philosophical differences.

GB> Our hope with scwm is to be a superset of a handful of wm-s, and invite
GB> development to continue on scwm alone.

I don't recall seeing an invitation.  I guess that's the point of all of
this.  Until now nobody's talking, and in the end it's all about
communication.  The reason I'm going to all of this trouble is to show that
(IMHO) scwm has a good chance of subsuming fvwm development almost
entirely.  (Again, that's IMHO; I won't speak for anyone else here.)  But
it's getting a little late in the game for that, and it seems to me rather
daft for the scwm folks not to have done anything about it so far.

 - J<

---

From: Greg Badros <[email-masked]>
Date: 10 Dec 1997 15:38:19 -0800

> connect it to a window manager.  I'll have to look up a reference....

Your information is more recent than mine -- I was basing my statement
only on the GNOME Web page which listed scwm as part of GNOME last I checked.

Greg

---

From: Greg Badros <[email-masked]>
Date: 10 Dec 1997 15:48:22 -0800

> at an internal language.  Over fvwm2, scwm has, a real internal language,

Modules are a terrible hack at getting a real language -- they serve the 
same fundamental purpose.

> substantive philosophical differences.

scwm also is separating out the major interfaces so that small plug-in C 
code can decorate windows, draw menus, etc.

> this.  Until now nobody's talking, and in the end it's all about

Because in the early stages of a project, many people tend to hinder,
not help development.  We needed to get an infrastructure implemented
and working before having lots of contributing developers.  Even on the
scwm list people have gotten a bit frustrated with us being when they
report bugs, we say "Thanks much, but in fact, that entire piece of code 
has just been rewritten from scratch, so your bug has been replaced with 
other unrelated ones".   There is a tension between moving development
along quickly, and providing a reasonably stable version from which
modifications can be made.  We've still got a small handful of rewrites
(each of which is a weekend project) before the infrastructure and
interfaces will be semi-stable.

Your point about communication is well taken, and is why I'm really glad 
we're having this conversation now.  We're on the same team...

> entirely.  (Again, that's IMHO; I won't speak for anyone else here.)  But

I'd like to see this happen as there's definitely good work done on fvwm2.

> daft for the scwm folks not to have done anything about it so far.

It's because of the infrastructure issue --- as a simplistic example,
consider reindenting all the code -- no patches made before the reindentation
will easily apply after the indentation.  Similarly for all the
non-trivial re-architecting we've done.  Our standard error handling and 
type handling idioms aren't yet set in stone.  Recent effort has spent
some time on formalizing these and writing developer documentation, but
it's not done yet.

We're close, and I encourage developers capable of writing solid code
who are interested in contributing to take a look at scwm and see what
we've got -- we intend to make nightly snapshots available soon, as the
last semi-stable release is considerably behind where the sources now stand.

Greg

---

From: Greg Badros <[email-masked]>
Date: 10 Dec 1997 16:05:20 -0800

> But if they were all 'wrong', why didn't you start from scratch?

Because we wanted to be up and going faster than that would
necessitate.  We have been replacing fvwm2 functionality piecewise with
cleaner versions with well-dilineated interfaces, and moving appropriate 
functionality out of the C code, into the scheme code where performance
was not essential.

> use perl if you wanted to, then you have a library.  Or have I

More precise: the *language* is not the core, but the choice of language
implementation infrastrcture is.  ie. it's not Scheme that matters, but
the guile way of interfacing primitives to the dynamic configuration
language.  Any choice made regarding this is pervasive in the system and 
is difficult to permit to be interchangeable.

> like scwm was what just about everyone involved with fvwm has wanted.

I didn't necessarily have that sentiment, but anyway you look at it, a
branch is necessary for parallel development -- either a CVS branch or a 
split source tree.  I think the latter was chosen because I believe
Maciej's intent is/was to rewrite all the code eventually to permit GPL
as the sole distribution terms. 

> might be nice to capitalize on the name recognition and call it fvwmSC or

Sometimes changing a name is necessary to make it clear that there's
something fundamentally different happening.  (I'm not sure I've
convinced you that that's the case, but that's our goal).

> How can you say what fvwm3 would be?  Especially if scwm hadn't

I can't but the discussion on this list has generally been about very
simple changes and incremental improvements.

> just split development of the modules, too.

Nope... as I mentioned before, modules are really high on my list to get 
working again as the lack of a pager is the main reason for my not using 
scwm as my main wm yet (still using a patched fvwm2).

Like I said, we're on the same team, and the communication channels are
definitely open.  Maciej and I don't mean to alienate anyone by doing
early stages of development more privately -- we just felt that that was 
best while code is/was changing dramatically.

Your input is valuable, and we encourage more of the same -- the scwm
url is :

and I encourage fvwm2 folks who are intrigued to take a look.

Thanks,
Greg J. Badros
[email-masked]
Seattle, WA  USA

---

From: Jason L Tibbitts III <[email-masked]>
Date: 10 Dec 1997 23:31:35 -0600

>>>>> "H" == Greg Badros <[email-masked]> writes:

H> scwm also is separating out the major interfaces so that small plug-in C
H> code can decorate windows, draw menus, etc.

Some people wanted that, and I do recall that it was rejected in the short
term because it would require too many changes.  There were also some
questions as to efficiency, but nobody ever provided any hard data.  I'd be
interested to see what the tradeoffs were.  (I figured it could be done
with very little overhead.)

H> Because in the early stages of a project, many people tend to hinder,
H> not help development.

OK, I can understand that.  I've been at that phase with Majordomo, but its
large enough that someone could work on a piece for quite a while before I
got back to it.  Something weird is that with Majordomo I threw away _all_
of the existing code but kept the name; you kept some code (at least for
the near term) and changed the name.  Name recognition is important to me;
I'm probably keeping less backwards compatibility with Majordomo than
you're keeping with fvwm->scwm, but if I were to lose the name I'd lose
almost all interest.

H> Your point about communication is well taken, and is why I'm really glad
H> we're having this conversation now.  We're on the same team...

Good enough for me.  Keep the fvwm development community in mind for the
time when you want more developers.  Also, if your team needs any
infrastructure (lists, web pages, etc.) just ask.  I see you have most of
that, although I don't see any kind of list archives.

 - J<

---

From: Bob Woodside <[email-masked]>
Date: Thu, 11 Dec 1997 01:26:04 -0500 (EST)

Whew! It's been a busy day in the neighborhood! Think I'll stay
out of the emotional thread and stick to this one. It's been a long day,
and a nasty, snowy drive home.

> unsigned ints and bitfields, perhaps like this:

                 [snip]

> (or perhaps that extra struct isn't needed, I'll have to test that). 

        I'm not sure what the extra level of struct and union will buy
us. I suspect that it may cause some compilers, at least, to generate
more convoluted code than they need to. But, as you say, this could
stand some testing on a variety of systems and compilers.

        Also, you might consider whether you want to split the flags
into 2 groups: the style-related flags (which the style code cares about
outside of the context of any window), and the window-state flags. A
style-flag struct that's common to the style and window code doesn't
really need to carry window-state flags.

        Otherwise, I really like the idea. Dan's first test suggests
some possible reservations, of course, but it'd be nice to see that
sort of thing done in a few different environments before we decide to
panic. And, as I replied to Dan, I'd like to see a little refinement
of the test.

        - Bob

---

From: Bob Woodside <[email-masked]>
Date: Thu, 11 Dec 1997 01:27:21 -0500 (EST)

[snip]

        I don't think this is a totally accurate comparison. The bitfields are
imbedded within a struct within a union within a struct, whereas the int is
just a stand-alone variable. Wonder what would happen if you imbedded the int
"old_way" within another struct that mimicked the FvwmWindow.flags.f setup?
The bitfields might still lose, but I suspect it'd be a closer contest. Mind
you, I have no knowledge of your compiler, so I can't claim it's anything more
than a suspicion. Just a thought....

        - Bob

---

From: "David A. Rogers" <[email-masked]>
Date: Thu, 11 Dec 1997 08:50:05 -0600

>!   71	  old_way |= ICONIFIED;

I know UNIX/Linux programmers like to optimize everything, but _four
instructions_???  Surely, time is better spent on other things.

Regards,
David

---

From: Greg Badros <[email-masked]>
Date: 11 Dec 1997 09:59:44 -0800

> with very little overhead.)

Re: the tradeoffs, it's hard to say, yet.  I've abstracted clean
interfaces, but not written a second implementation.  Obviously
simplicity of interface trades off with flexibility, but I tried to
remain flexible so that different menu code implementations could vary
pretty widely and support button-bar menus, pie menus, horizontal menus, 
table menus, etc.  Menus in scwm will not need to do a server grab --
rip-offs will be allowed, replacing button bar functionality.

> that, although I don't see any kind of list archives.

I'm going to talk to Maciej about getting some of the cleanup and
policy-decisions ironed out so that we can really start asking for help
in development, and begin moving forward more rapidly.

Greg

---

From: Dan Espen <[email-masked]>
Date: Thu, 11 Dec 1997 16:06:55 -0500

Bob Woodside <[email-masked]> writes:

> I don't  think this is  a totally accurate comparison. The bitfields
> are imbedded within a struct within a union within a struct, whereas
> the int is just a stand-alone variable. Wonder  what would happen if
> you imbedded the  int "old_way" within  another struct that mimicked
> the FvwmWindow.flags.f setup?  The bitfields might still lose, but I
> suspect it'd be  a closer contest. Mind you,  I have no knowledge of
> your  compiler,   so  I  can't claim   it's   anything more  than  a
> suspicion. Just a thought....

I tried this:

#include <stdio.h>
  union flags {
    struct f {

FvwmWindow tmp_win;

typedef struct OldWindow {
  unsigned long flags;
  unsigned long old_way;
} OldWindow;

OldWindow old_win;

main() {

  tmp_win.flags.f.t36 = 0;
  tmp_win.flags.f.t36 = 1;
  if (!tmp_win.flags.f.t36) {
    printf("It's off\n");
  }

#define ICONIFIED 2
  old_win.old_way &= ~ICONIFIED;
  old_win.old_way |= ICONIFIED;
  if (old_win.old_way & ICONIFIED) {
    printf("It's on\n");
  }
}

The results with  Suns 4.0 compiler are  the same.   I also tried  gcc
2.7.2.2.  With gcc it is a little harder to follow, they don't mark up
the assembler as well, but the results seemed to  be about the same as
with Sun's compiler.   With  optimization  I  got the  old  way at  10
instructions, the new way at 13.

It  does  seem like  the compilers aren't  doing a   very  good job of
figuring out   what  the  source code  is  doing.   The   source  code
instructions are equivalent.

After looking at all this, and  finally understanding what the GSFR is
all  about, I feel patch  writers should go ahead  and add flags using
whatever approach they like to  the Style structure and the FvwmWindow
structure.   Whenever and however the  GSFR happens,  a few additional
bits to worry about won't make a significant difference.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 11 Dec 1997 17:45:02 -0500 (EST)

BITFIELD WINS BIG on ARMONK IRON
                   - Details at 11

    Couldn't resist trying out Dan's bitfield test on a big
ol' mainframe compiler - IBM's LE/370 on a 3090. Blew away
my theory that the struct-within-a-struct might induce
the compiler to perform more gyrations than were really
necessary. With this compiler, it's not the struct definition
but the int declaration that adds the contortions. But YMMV. 
I'd like to see this tried on a few different systems/compilers.
(No, the compiler doesn't generate those assembler comments.)

        /* Bitfield in struct-in-union-in-struct... */
 *  s1.flags.bf.bf3       =  True;
           OI    144(r13),32    /* Aww, just set the damn bit. */
        /* Int in struct-in-union-in-struct... */
 *  s2.flags2.bf2.Other1 |=  ThirdBit; 
           L     r4,152(,r13)        /* Get the var...         */  
           O     r4,=F'536870912'    /* Apply the or-mask...   */
           ST    r4,152(,r13)        /* Put 'er back.          */
        /* Simple int variable... */
 *  AnotherInt           |=  ThirdBit; 
           L     r4,160(,r13)        /* Get the var...         */
           O     r4,=F'536870912'    /* Apply the or-mask...   */
           ST    r4,160(,r13)        /* Put it back.           */

    This is with no optimization specified. It would be 
difficult to optimize the bitfield operation any more than
this. (Well, I did think of one way: by commenting out subsequent 
references to any of these local variables, you can optimize the 
whole program away. There's performance for you!)

    Actually, turning optimization on generated less efficient 
code for the bitfield case, because the compiler tried so hard to 
keep as much stuff as it could in registers; but the overall 
sequence was probably faster. 

    For a really conclusive test, the structs/variables/whatever
should be external to the funcion operating on them, referenced
by a passed pointer. This would better mimick the way the new Style
flags would actually be used, and keep the optimizer from getting
*too* carried away. Matter of fact, the three operations should 
probably be isolated into three separate functions that do just one
thing. Otherwise, when you start optimizing, the first operation 
may appear to be doing a lot more because it's picking up some 
setup overhead that's common to all three. 

    All that said, based on the feedback that's come in today, I
think two things seem to be emerging:

    1. Not all optimizing compilers are created equal.
    2. The bit-field performance penalty, where it exists, is
       *probably* not a show-stopper.

        - Bob

---

From: Bob Woodside <[email-masked]>
Date: Sat, 13 Dec 1997 23:13:10 -0500 (EST)

One more test of the bitfield vs. old-style flag
treatment.... This was generated by GCC under Linux on a
Wintel box, no optimization. It's hard to see a great deal
to recommend one technique over the other (from a performance
point of view) in this case. And once again it quashes my sug-
gestion that the struct-union-struct construct might cause
less efficient code to be generated. The only way to soup this
up any more would be to fold the 2 or's into a single instruction.

        - Bob

================ The Assembler Code =================

Assembler code courtesy of GDB.
Hand interpolated C code courtesy of yours truly.

Dump of assembler code for function main:

           [uninteresting stuff deleted]

*   printf("About to set some bits the new way...\n");

    0x8048189 <main+85>:    pushl  $0x80591bf
    0x804818e <main+90>:    call   0x8048290 <_IO_printf>
    0x8048193 <main+95>:    addl   $0x4,%esp

*   s1.flags.fb.f3          =  True;

    0x8048196 <main+98>:    orb    $0x4,0xfffffff8(%ebp)

*   s1.flags.fb.f10         =  True;

    0x804819a <main+102>:   orb    $0x2,0xfffffff9(%ebp)

*   s1.flags.fb.f6          =  False;

    0x804819e <main+106>:   andb   $0xdf,0xfffffff8(%ebp)

*   printf("About to set some bits the old way...\n");

    0x80481a2 <main+110>:   pushl  $0x80591e6
    0x80481a7 <main+115>:   call   0x8048290 <_IO_printf>
    0x80481ac <main+120>:   addl   $0x4,%esp

*   s2.flags2.TheOtherFlagWords[0]    |=  ThirdBit;  

    0x80481af <main+123>:   orb    $0x4,0xfffffff0(%ebp)

*   s2.flags2.TheOtherFlagWords[0]    |=  TenthBit;  

    0x80481b3 <main+127>:   orl    $0x200,0xfffffff0(%ebp)

*   s2.flags2.TheOtherFlagWords[0]    &=  ~SixthBit;  

    0x80481ba <main+134>:   andl   $0xffffffdf,0xfffffff0(%ebp)

           [etc.]

End of assembler dump.

==================== The C Source =====================

#include <stdio.h>
void  main ()
{
#define True        1
#define False       0
/*
#define ThirdBit    0x20000000
#define SixthBit    0x04000000
#define TenthBit    0x00200000
*/
/*  
    Hmm...looks like GCC is assigning bitfields in the old PDP-11 
    style, at least for Wintel machines. Ok, we will too.
*/
#define ThirdBit          4
#define SixthBit          32
#define TenthBit          512

struct s1
{
  union flags
  {
    unsigned long int TheFlagWords[2];
    struct fb
    {
    unsigned    f1:   1;
    unsigned    f2:   1;
    unsigned    f3:   1;
    unsigned    f4:   1;
    unsigned    f5:   1;
    unsigned    f6:   1;
    unsigned    f7:   1;
    unsigned    f8:   1;
    unsigned    f9:   1;
    unsigned    f10:  1;
    unsigned    f11:  1;
    unsigned    f12:  1;
    unsigned    f13:  1;
    unsigned    f14:  1;
    unsigned    f15:  1;
    unsigned    f16:  1;
    unsigned    f17:  1;
    unsigned    f18:  1;
    unsigned    f19:  1;
    unsigned    f20:  1;
    unsigned    f21:  1;
    unsigned    f22:  1;
    unsigned    f23:  1;
    unsigned    f24:  1;
    unsigned    f25:  1;
    unsigned    f26:  1;
    unsigned    f27:  1;
    unsigned    f28:  1;
    unsigned    f29:  1;
    unsigned    f30:  1;
    unsigned    f31:  1;
    unsigned    f32:  1;
    unsigned    f33:  1;
    unsigned    f34:  1;
    unsigned    f35:  1;
    }  fb;
  }  flags;
}  s1;

struct s2
{
  union flags2
  {
    unsigned long int TheOtherFlagWords[2];
    struct fb2
    {
    unsigned    f1:   1;
    unsigned    f2:   1;
    unsigned    f3:   1;
    unsigned    f4:   1;
    unsigned    f5:   1;
    unsigned    f6:   1;
    unsigned    f7:   1;
    unsigned    f8:   1;
    unsigned    f9:   1;
    unsigned    f10:  1;
    unsigned    f11:  1;
    unsigned    f12:  1;
    unsigned    f13:  1;
    unsigned    f14:  1;
    unsigned    f15:  1;
    unsigned    f16:  1;
    unsigned    f17:  1;
    unsigned    f18:  1;
    unsigned    f19:  1;
    unsigned    f20:  1;
    unsigned    f21:  1;
    unsigned    f22:  1;
    unsigned    f23:  1;
    unsigned    f24:  1;
    unsigned    f25:  1;
    unsigned    f26:  1;
    unsigned    f27:  1;
    unsigned    f28:  1;
    unsigned    f29:  1;
    unsigned    f30:  1;
    unsigned    f31:  1;
    unsigned    f32:  1;
    unsigned    f33:  1;
    unsigned    f34:  1;
    unsigned    f35:  1;
    }  fb2;
  }  flags2;
}  s2;

memset(&s1, '\0', sizeof(s1));
memset(&s2, '\0', sizeof(s2));

printf("Hello, world!  Let's set some bits.\n");
printf("About to set some bits the new way...\n");
s1.flags.fb.f3          =  True;
s1.flags.fb.f10         =  True;
s1.flags.fb.f6          =  False;

printf("About to set some bits the old way...\n");
s2.flags2.TheOtherFlagWords[0]    |=  ThirdBit;  
s2.flags2.TheOtherFlagWords[0]    |=  TenthBit;  
s2.flags2.TheOtherFlagWords[0]    &=  ~SixthBit;  

printf("After: 1st flag word 1 = %d.\n", s1.flags.TheFlagWords[0]);
printf("After: 2nd flag word 1 = %d.\n", s2.flags2.TheOtherFlagWords[0]);
printf("About to leave now...\n");

return ;
}