Subject: how to do the GSFR

From: Dominik Vogt <[email-masked]>
Date: Thu, 4 Mar 1999 21:28:15 +0100

As mentioned in another thread I'd like to begin with the
GSFR as soon as the larger outstanding patches have been
applied. Let me summarize what we (more or less) agreed
in our last discussion:

1) Flags are implemented as bit fields inside a struct.
2) Style and state flags are kept in different objects.

     struct 
     {
       struct
       {
         unsigned start_iconic : 1;
         unsigned lenience : 1;
         ...
       } style,
       struct
       {
         unsigned IconifiedByParent : 1;
         unsigned NameChanged : 1;
         ...
       } state
     } flags;

3) Flags are accessed through macros:

   e.g.:

     if (IS_STICKY(window))
       ...

We had some discussion about (3) and if we should use
unions with an array of integers (as described in the TODO
file) but I think we can agree on the above.

I'd volunteer to do a good chunk of the work. However I've
got no idea which of the present flags are style flags and
which are state flags.

Paul (PDS) perhaps we could get that through together, what
do you think?

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: [email-masked] (Andrew T. Veliath)
Date: 04 Mar 1999 16:27:37 -0500

.........----------------==================----
..--==-  Thu, 4 Mar 1999 21:28:15 +0100,
..--==-  Dominik Vogt (DV) discussed:

 DV)  As mentioned in another thread I'd like to begin with the
 DV)  GSFR as soon as the larger outstanding patches have been
 DV)  applied. Let me summarize what we (more or less) agreed
 DV)  in our last discussion:

 DV)  1) Flags are implemented as bit fields inside a struct.
 DV)  2) Style and state flags are kept in different objects.

Good idea

 DV)  3) Flags are accessed through macros:

 DV)  e.g.:

 DV)  if (IS_STICKY(window))
 DV)  ...

 DV)  We had some discussion about (3) and if we should use
 DV)  unions with an array of integers (as described in the TODO
 DV)  file) but I think we can agree on the above.

Just thought I'd mention some past experience I had when playing
around with stuff like this (I did a GSFR last April, which patches
against 2.0.46, and had it functionally running just like 2.0.46).

Basically what I used there were things like:

set_flag(on_flags, sticky_icon)
flag_isset(t->flags, on_top))

etc.  That was a while ago, and what you might consider now are things
like. Or something like:

SET (flags, group, flag)
CLEAR (flags, group, flag)
IS_SET (flags, group, flag)

I also implemented macros operations such as OR, AND, ADD, REMOVE and
EQ (which made the on_flags off_flags thing easy).  Then define other
macros which access particular subgroups of the bitfield:

#define WIN_SET(win, group, flag) \
	SET((win)->flags, group, flag)
#define WIN_CLEAR(win, group, flag) \
	CLEAR((win)->flags, group, flag)
#define WIN_ISSET(win, group, flag) \
	IS_SET((win)->flags, group, flag)

The advantage of this more generic way was that it made it easier to
create bit operations like or/and and stuff. This much simplified
converting some stuff in style.c wrt on_flags and off_flags (which I
had completely converted), to retain the current behavior.

-- 
Andrew  	I bought some used paint. It was in the shape of a house. --
		Steven Wright

---

From: [email-masked] (Paul D. Smith)
Date: 04 Mar 1999 17:10:06 -0500

%% [email-masked] (Andrew T. Veliath) writes:

  atv> Basically what I used there were things like:

  atv> set_flag(on_flags, sticky_icon)
  atv> flag_isset(t->flags, on_top))

  atv> etc.  That was a while ago, and what you might consider now are things
  atv> like. Or something like:

  atv> SET (flags, group, flag)
  atv> CLEAR (flags, group, flag)
  atv> IS_SET (flags, group, flag)

These are all useful if we're using arrays where we then set and test
bits, but if we're using C's bitfields I don't really see the
advantage.

You can't use bitwise and/or to set or test multiple bitfields at once:
you have to do them individually anyway.  It seems more straightforward
to just deal with the data structure directly, rather than through
macros which don't add any value... e.g.

  #define HAS_STICKY_ICON(_w)    ((_w)->has_sticky_icon)

    if (HAS_STICKY_ICON(window))

doesn't seem any more clear or usefully abstracted, to me, than simply
writing:

    if (window->has_sticky_icon)

Whatever, this sounds suspiciously like a discussion we've had before.
Maybe we should all go back and read through the archives before going
further :)

-- 
-------------------------------------------------------------------------------
 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: [email-masked] (Paul D. Smith)
Date: 04 Mar 1999 17:05:43 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv>      struct 
  dv>      {
  dv>        struct
  dv>        {
  dv>          unsigned start_iconic : 1;
  dv>          unsigned lenience : 1;
  dv>          ...
  dv>        } style,
  dv>        struct
  dv>        {
  dv>          unsigned IconifiedByParent : 1;
  dv>          unsigned NameChanged : 1;
  dv>          ...
  dv>        } state
  dv>      } flags;

Yikes, let's at least have a common naming convention here :)

We should probably have someone come up with a data structure and then
post it, and we can fight about the names.  I'm partial to the
lower_case method if identifiers, but I don't care enough to worry about
it if you-all like the UpperCase method.

Just so long as we're consistent :)

  dv> 3) Flags are accessed through macros:

  dv>    e.g.:

  dv>      if (IS_STICKY(window))
  dv>        ...

  dv> We had some discussion about (3)

For the record, I'll repeat that I think these macros are superfluous,
but I don't care that much either :).

  dv> and if we should use unions with an array of integers (as
  dv> described in the TODO file) but I think we can agree on the above.

I was never sure what the purpose of the union was.  When would it make
sense to access the data via the array?  You can copy the entire data
structure with a struct assignment, or memcpy(), or whatever, and you
can't rely on being able to set bits in the bitfields via the array or
even access some bits in a structure that way, since the compiler can
organize them however it likes.

If we really think we need to be setting and/or testing multiple bits at
the same time all at once and don't want to use syntax like:

  if (!window->is_sticky && window->is_iconic)

then we can't use C bitfields and should just go back to an array of int
or whatever, with macros to hide the bit operations.

  dv> I'd volunteer to do a good chunk of the work. However I've
  dv> got no idea which of the present flags are style flags and
  dv> which are state flags.

  dv> Paul (PDS) perhaps we could get that through together, what
  dv> do you think?

I don't think I have much more of a feel than you for this distinction,
but we can take a first whack at it and let the list decide.

What exactly _is_ the distinction we're trying to make?  That is, where
in the code will we want to treat these things, as a block, differently?

---

From: [email-masked] (Andrew T. Veliath)
Date: 04 Mar 1999 17:24:25 -0500

.........----------------==================----
..--==-  04 Mar 1999 17:10:06 -0500,
..--==-  Paul D Smith (PDS) discussed:

 PDS)  %% [email-masked] (Andrew T. Veliath) writes:
 atv)  Basically what I used there were things like:

 atv)  set_flag(on_flags, sticky_icon)
 atv)  flag_isset(t->flags, on_top))

 atv)  etc.  That was a while ago, and what you might consider now are things
 atv)  like. Or something like:

 atv)  SET (flags, group, flag)
 atv)  CLEAR (flags, group, flag)
 atv)  IS_SET (flags, group, flag)

 PDS)  These are all useful if we're using arrays where we then set and test
 PDS)  bits, but if we're using C's bitfields I don't really see the
 PDS)  advantage.

 PDS)  You can't use bitwise and/or to set or test multiple bitfields at once:
 PDS)  you have to do them individually anyway.  It seems more straightforward
 PDS)  to just deal with the data structure directly, rather than through
 PDS)  macros which don't add any value... e.g.

This was all implemented with bitfields, actually.  Though it involved
some macros which I think were portable.

-- 
Andrew  	Life is one long struggle in the dark. -- Titus Lucretius Carus

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 Mar 1999 13:34:30 +0100

> Just so long as we're consistent :)

The example above is from the current code. Personally I use
underscores and I don't mind in the least which we use. But
since most flags are uppercase it's less work to change those
with underscores.

> but I don't care that much either :).

Um, I always thought that you wanted the macros and I thought them
to be dangerous. I can do without them perfectly well.
 
> structure with a struct assignment,

I think this is the reason. As far as I remember early versions of
C couldn't copy structs but simply copied the pointer.

> or memcpy(), or whatever, and you

Why should we want to test several bits at once? I've seen nothing
like this in the code. The only case i could imagine is when there
are more than two alternatives of a single option and then you can
use 'foo : 2' instead.

> in the code will we want to treat these things, as a block, differently?

Probably nowhere, the advantage is that it may make the code
easier to understand (well, of course not if we hide the struct
with macros). It will even make things more complicated since we
need a second level of structs. If we can't figure out which flag
belongs where we could simply use one struct with a style and a
state section:

  struct
  {
    /* style flags */
    unsigned start_iconic : 1,
    unsigned lenience : 1,
    ...

    /* state flags */
    unsigned IconifiedByParent : 1,
    unsigned NameChanged : 1,
    ...
  } flags

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 Mar 1999 14:58:39 +0100

> since most flags are uppercase it's less work to change those

Oops, most flags use underscores.

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 Mar 1999 15:17:49 +0100

>     unsigned NameChanged : 1,

I've hacked it into fvwm.h this way (with some modifications).
Could you take a look?  I'd like to change all the names to
'is_...' or 'has_...' too.

Comments?

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Fri, 05 Mar 1999 09:22:38 -0500

> in the code will we want to treat these things, as a block, differently?

I'm not sure we are on the same page, but when looking at style flags,
it makes sense that you first understand what is going on with
"ALL_COMMON_FLAGS".

When we discussed this  last time, we  came to the conclusion that the
"common"  bits should be  in a structure by  themselves since they are
moved  all at once from   the style structure  into  each new  windows
structure.

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

--
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: 05 Mar 1999 10:12:47 -0500

>> but I don't care that much either :).

  dv> Um, I always thought that you wanted the macros and I thought them
  dv> to be dangerous. I can do without them perfectly well.

Oh, yeah.  I think you're right!  How embarrassing.

One advantage of the macros, I will say, is that you don't have to worry
about how (or if) you split the flags into multiple structures; that's
hidden by the macro.

  >> I was never sure what the purpose of the union was.  When would it
  >> make sense to access the data via the array?  You can copy the
  >> entire data structure with a struct assignment,

  dv> I think this is the reason. As far as I remember early versions of
  dv> C couldn't copy structs but simply copied the pointer.

This is true, traditional K&R couldn't do that.  However, we've long
since abandoned any pretense at supporting pre-ANSI C compilers, what
with requiring prototypes and stdard.h, etc.

However, a memcpy() will do just as well on a struct as it will on an
array of ints if we don't want to rely on struct copies (although I
recommend it, since it's undoubtedly faster the majority of the time).

Looking through the mail archive to remind myself of exactly what my
positions are on these issues ;), I see we already laid this one to rest
in the last discussion: we don't need these arrays.

---

From: [email-masked] (Paul D. Smith)
Date: 05 Mar 1999 10:31:09 -0500

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

  de> When we discussed this last time, we came to the conclusion that
  de> the "common" bits should be in a structure by themselves since
  de> they are moved all at once from the style structure into each new
  de> windows structure.

Ah!  Yes, that sounds familiar now.  Seems like a good plan.