Subject: FVWM: window flags bitfield

From: Bob Mende Pie <[email-masked]>
Date: Mon, 8 Dec 1997 12:42:09 -0800 (PST)

I just spent 15 minutes adding the ability determine if a window is
"WindowShaded" so I can do complex operations on it.  I see that this was
never added since ALL of the 32 bits of the window flags field are
allocated.  (Note, I stole bit 31, from the motif hacks which I dont use).
What do people think about bumping this to 64 bits?

Also, when this happens, the WindowShade stuff can be cleaned up a little.

                    /Bob...                    mailto:[email-masked]
              http://reality.sgi.com/mende            KF6EID
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Paul D. Smith)
Date: 08 Dec 1997 18:16:50 -0500

%% 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?

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

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

-- 
-------------------------------------------------------------------------------
 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.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

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:

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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

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".

---

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

> lots of enhancements but exactly 0 progress towards that goal.  Just my

Maybe I'm confused.  There are  flags in the WindowList structure, and
flags  in the   name_list (Style flags)  structure.   The   bits serve
different purposes in each.  In both cases, it looks like all the bits
are used up.  I thought the term GSFR applied to the Style Flags.

In  the case of  the WindowList,  I don't see   any obstacle to adding
another unsigned long (flags2?) to hold additional bits.

On the separate subject of the style flags, after the iconboxes patch,
I don't see   any obstacle to  doing  the  same  thing for new   style
bitfields.

Please correct me if I'm missing something.

--
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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Paul D. Smith)
Date: 10 Dec 1997 11:25:02 -0500

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

  de> Maybe I'm confused.  There are  flags in the WindowList structure, and
  de> flags  in the   name_list (Style flags)  structure.   The   bits serve
  de> different purposes in each.  In both cases, it looks like all the bits
  de> are used up.  I thought the term GSFR applied to the Style Flags.

I think it does, although any flags field where all the bits are used up
is a potential problem.

  de> In  the case of  the WindowList,  I don't see   any obstacle to adding
  de> another unsigned long (flags2?) to hold additional bits.

  de> On the separate subject of the style flags, after the iconboxes patch,
  de> I don't see   any obstacle to  doing  the  same  thing for new   style
  de> bitfields.

The problem is, as you say, all the bits are used up.  There are many
ways to solve the problem, of course.  One way is this, keep adding new
ulongs with new names.  That's probably the most trivial way to fix it.

I don't like this (although I don't hack fvwm so I don't really have any
say :); now when you want to test a flag you have to remember and put in
the code which "flags" param it is: flags, flags2, flags3, etc.  It's
just kind of gross.

I'd prefer changing the type of the flags field from ulong to an array
of unsigned char, something like this:

  #include <limits.h>

  #ifndef CHAR_BIT
  #define CHAR_BIT 8    /* ISO C should #define this for us in limits.h */
  #endif

    ...

  #define MAX_STYLE_FLAGS   54  /* Increment for new flags */

  #define STYLE_FLAG_SIZE   ((MAX_FLAGS/CHAR_BIT)+1)

  ...
    unsigned char on_flags[STYLE_FLAG_SIZE];
  ...

then provide a set of functions or macros for testing and setting bits
and hiding this structure.

Since this touches all code that currently looks at these bits, it was
decided it's too big a change to make before 2.1.  Of course, that was
when we thought 2.1 would be out in the summer of 1996 or so ;) :)

---

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

On 10-Dec-97 Dan Espen wrote:

> are used up....

        Yes, this is a major stumbling block for development that goes far
beyond the Style problem, though that's what seems to get the most 
attention. The reason the poor old flag word in the FvwmWindow struct is
so overloaded is that it's being used for two unrelated things: window
*style*, and window *state*, which is even more important to the 
functioning of a window manager (even though that's not where the 
sex-appeal is at). I think the two really ought to be divorced from one 
another somehow. And a style flag struct of some sort that's common to
both the style (but not specific window) related code and the window
related code would be really nice.

        Whatever is decided for the style flags, the same treatment should
probably be accorded the state-related flags - whether it's a bit-field 
struct or some other solution. And whatever is done will affect every bit 
of code, style-related or not, that ever looks at SomeOldWin->flags. Lotta
grunt work to be done there. 'Tain't glamorous, but I'll happily volunteer
to do some of it, whenever the design's finalized.

        I still tend to favor the bit-field approach, but more on that in
another note.

        - Bob