Subject: experiences implementing colorsets in FvwmButtons

From: Dominik Vogt <[email-masked]>
Date: Sun, 15 Aug 1999 14:23:46 +0200

I perceive several problems with the current implementation
of colorsets:

 1) You can't call the SetWindowBackground function without
    a GC. What is it needed for? In FvwmButtons the GC was
    not even created when XSetWindowBackground was set
    first.

 2) How about renaming SetWindowBackground to
    ColorsetSetWindowBackground. This makes it easier
    to understand.

 3) With this in my init function:

      AddToFunc InitFunction
      + Module FvwmTheme
      + Module FvwmButtons

    FvwmButtons doesn't get the colorset information and
    uses a default. I think the only way to prevent
    synchronisation problems reliably is to make fvwm store
    the colorset lines it received from FvwmTheme and
    send them out to each new module in modconf.c
    (SendDataToModule), just like ColorLimit, ImagePath,...

 4) You can't set a transparent background in a colorset
    instead of a pixmap explicitly.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 16 Aug 1999 10:20:05 +0200

>     (SendDataToModule), just like ColorLimit, ImagePath,...

I think the main problem is synchronization. It would
be nice if the modules start up with the proper colours
and not draw themselves in the default colours and then
redraw themselves for each colour set received. This
causes a lot more redrawing than necessary. We need a
mechanism to delay mapping of the modules.

A related problem is that the colour sets are sent in
reverse order to make sure the coloursets are allocated
only once. But if you allocate coloursets 0 to 10 and
only 10 is initialized, the module may still access
e.g. colourset 3 which is all zeroes.

The same problem occurs if the config lines for
FvwmTheme do not define colour sets in ascending order.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Mon, 16 Aug 1999 14:45:26 +0100

>     not even created when XSetWindowBackground was set

It's needed by the xlib calls within SetWindowBackground so we either
have a private static one or we pass one in.  It can be anything really
as long as the plane_mask is set to AllPlanes.  We could arrang for
InitPictureCmap() to create one that is used internally by the XPM and
colorset functions. The same goes for the depth argument.
>     ColorsetSetWindowBackground. This makes it easier
No problem just lots of indenting to do, It might be a good idea to just
pass the colorset number in instead of the address of the colorset.

>     (SendDataToModule), just like ColorLimit, ImagePath,...

This is what it does already. If FvwmButtons gets it wrong that's a bug
in FvwmButtons. The problem at startup time is that there is no
synchronization of modules so FvwmButtons could get its configuration
before FvwmTheme has created all the colorsets.  What FvwmButtons should
do is to note the colorset numbers it is to use and to apply those
numbers every time it gets a Colorset M_CONFIG message.  This will casue
it to redisplay lots as FvwmTheme sends in the colorsets.

We could arrange FvwmTheme to send a "Function post_theme_start_function
Quiet" after it has read its config and sent all the colorset
definitions. You would then have to move all your module startup lines
from InitFunction to post_theme_start_function.

>     instead of a pixmap explicitly.
I think you're dealing with this,  I've seen problems with
"*FvwmThemeColoroset 0 black gray tiledpixmap side.fvwm99.xpm" it looks
like the gray background only extends to the top part (use FvwmIdent to
view), aspectpixmap doesn't seem to work at all.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 16 Aug 1999 14:53:11 +0100

> mechanism to delay mapping of the modules.

I think arranging for FvwmTheme to send a command after it has done all
it's stuff is the way to go.  If you want to reduce redrwaing then put
your module startup lines in that function and only have FvwmTheme in
the InitFunction.
> e.g. colourset 3 which is all zeroes.
If you tell a moudle to use colorset 3 and never define colorset 3 then
you are going to have problems. I suppose we could change AllocColorset
to copy Colorset 0 into each new colorset it creates, at least then
accessing an undefined colorset wouldn't give black on black.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 16 Aug 1999 16:01:35 +0200

> accessing an undefined colorset wouldn't give black on black.

The problem is the reverse order when sending. When a module evaluates
ege. set 3 this one might still be undefined because fvwm has not
finished sending the coloursets (e.g. is has sent 10, 9 and 8 already,
but you use 3).

I think we need a ThemeFunction that is executed before InitFunction
and where FvwmTheme is initialised. fvwm would wait until FvwmTheme
dies or finished it input parsing (it sends some string to fvwm
that ends the startup).

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Mon, 16 Aug 1999 10:35:43 -0400

> dies or finished it input parsing (it sends some string to fvwm

Wouldn't this be more generic:

AddToFunc "InitFunction" "I" ModuleSynchronous FvwmTheme

(The  module sends some  kind of  command back  to fvwm when  fvwm can
proceed.)

--
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: Tim Phipps <[email-masked]>
Date: Mon, 16 Aug 1999 16:47:54 +0100

> finished sending the coloursets (e.g. is has sent 10, 9 and 8 already,

Eventually set 3 will be defined at which point the module should
re-evaluate it and display it correctly.  It should redraw everything
that uses set 3 when set 3 changes. That's why LoadColorset() returns
the number of the colorset it just loaded.

> dies or finished it input parsing (it sends some string to fvwm

If FvwmTheme is going to send a string to fvwm to tell it it is done
initializing it may as well send a command. That way we don't have to
change fvwm at all, just get FvwmTheme to send a "Function
StartModules".  If the user wants to reduce redrawing at startup they
will have to move their other modules start lines from InitFunctions to
StartModules. Other users do nothing.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Mon, 16 Aug 1999 12:08:45 -0400

> StartModules. Other users do nothing.

If you are going that far why don't you just have FvwmTheme pass a
command back that will send a final M_CONFIG_INFO that signifies that we
are done loading colorsets, then the module could redraw at that point.
And users wouldn't need to rearrange their configs at all.

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 16 Aug 1999 18:34:25 +0200

> the number of the colorset it just loaded.

On one hand the redrawing is ugly and unnecessary. On the other hand
the modules has already accessed an illegal colour set.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 16 Aug 1999 18:35:40 +0200

> (The  module sends some  kind of  command back  to fvwm when  fvwm can

This appears as a good idea to me. The only thing that has to be done
is to write a manpage comment on where to put the FvwmTheme startup
command.

Bye

Dominik ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 17 Aug 1999 03:22:41 +0300 (IDT)

On Mon, 16 Aug 1999, Tim Phipps wrote:

> No problem just lots of indenting to do

This is one of the reasons why I don't use emacs. It uses very
unstructured code formating by default. I agree with Linus jokes
about emacs in /usr/src/linux/Documentation/CodingStyle.

BTW, although I don't use emacs, but my project partner uses, so my
question is how to configure emacs to produce structured code with
parentheses, so you only need search&replace, never reformatting,
i.e. --dont-line-up-parentheses equivalent of indent:

ColorsetSetWindowBackground(param1,
	param2,
	...
	);

or

ColorsetSetWindowBackground(
	param1,
	param2,
	...
);

Sorry for off-topic.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 17 Aug 1999 02:34:54 +0200

> ColorsetSetWindowBackground(

Um, simply start it? If it does it like in the first example it
is badly mis-configured. Emacs without a config file shouldn't
do it this way.

Bye

Dominik ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 17 Aug 1999 03:45:47 +0300 (IDT)

> is badly mis-configured. Emacs without a config file shouldn't

The examples are what I want to get. In c-mode of cause.

Regards,
Mikhael.

---

From: [email-masked] (Paul D. Smith)
Date: 16 Aug 1999 21:52:08 -0400

>> No problem just lots of indenting to do

  mg> This is one of the reasons why I don't use emacs. It uses very
  mg> unstructured code formating by default.

Feh.  A weak reason to reject an editor, to be sure.  Every style will
not appeal to someone; some style has to be the default.  I personally
strongly dislike the style you're requesting.

The only reason to reject an editor due to indent style is if you can't
change it to a style you prefer.  That, no one can argue for a second,
is not one of Emacs' problems (not being configurable enough :).

  mg> I agree with Linus jokes about emacs in
  mg> /usr/src/linux/Documentation/CodingStyle.

Linus is a very good programmer, but his views on coding style I take
with a grain of salt.

If you're looking for style advice, go to a _REAL_ expert.  My favourite
is Rob Pike.  Reference on request.

  mg> BTW, although I don't use emacs, but my project partner uses, so my
  mg> question is how to configure emacs to produce structured code with
  mg> parentheses, so you only need search&replace, never reformatting,
  mg> i.e. --dont-line-up-parentheses equivalent of indent:

Your use of the term "structured" is odd; I see nothing inherently more
structured about this indentation style than any other.  Also,
requirements that code not need to be reformatted are merely yolks
forced on us by those whose editors are less capable than ours, and
which can't do reformatting trivially.  ;)

  mg> ColorsetSetWindowBackground(param1,
  mg> 	param2,
  mg> 	...
  mg> 	);

  mg> or

  mg> ColorsetSetWindowBackground(
  mg> 	param1,
  mg> 	param2,
  mg> 	...
  mg> );

Have your friend read the documentation.  This is completely trivial,
you can do it very, very easily interactively, etc.  Have them read the
CC Mode manual, and look at the section entitled "Customizing
Indentation", in particular "Interactive Customization".

To get them started, this will change the indentation of arguments in
the list to 5 spaces; modify to taste:

  (defun my-c-mode-common-hook ()
    (c-set-offset 'arglist-intro 5))

  (add-hook 'c-mode-common-hook 'my-c-mode-common-hook)

I found this by writing the code, seeing where I didn't like the
indentation, then using C-c C-o to change it.

(this sets it for both C and C++ modes; that's the "common" part).

HTH.

  mg> Sorry for off-topic.

Ditto :).

-- 
-------------------------------------------------------------------------------
 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: Mikhael Goikhman <[email-masked]>
Date: Tue, 17 Aug 1999 07:32:01 +0300 (IDT)

I really don't want to start holy wars here. I have no problems with
anything others write, it is just easier to choose one coding style for
the project (I am speaking about the project with my partner, not fvwm).

On 16 Aug 1999, Paul D. Smith wrote:

> Feh. A weak reason to reject an editor, to be sure.

Right. This is a reason number 3 from several. I will list you all in a
private message if you like. And I know well that emacs is very powerful.

> Every style will not appeal to someone; some style has to be the
> default. I personally strongly dislike the style you're requesting.

So you say (you don't really say, I only guess), it must be:

a = my_first_long_named_function(my_param1,
                                 my_param2);
another_variant(param1,
                param2
                );

Very structured... Now try to rename both functions. Compare with:

a = my_first_long_named_function(
	my_param1,
	my_param2);
another_variant(
	param1,
	param2
);

The problem is that very many peoples write the first case just because
emacs by default does this.

> is not one of Emacs' problems (not being configurable enough :).

I am confortable with my once customized text editor, not less powerful.
The amount of configurations, not lisp knowledge, stops me (consider
only key remapping; I am not speaking about tons of small things like
"travel freely everywhere after end of line/file", "travel, but don't
add spaces/newlines" etc.).

> Linus is a very good programmer, but his views on coding style I take

I suggest you to take jokes with a grain of sugar. :-)

> is Rob Pike. Reference on request.

I would like to read this. My favorite is my OOP teacher, the name means
nothing.
The only really structured style is the one which doesn't use spaces for
indentation. Strong K&R. Exactly one special character (say TAB) for every
new level and no these special characters (TABs) anywhere else. This way
you can define TAB to be 4, 8, 11 (I prefer 3) without loosing structure.

> structured about this indentation style than any other.

"Structured" means you can see indentation levels of the fixed length.
Let's compare any other style with this "strong K&R". The benefits of the
last are:
  * looks very structured
  * anyone can define any TAB width he wants, so on the work I use TAB
size 3 and my partner - 5 on the same code
  * no needs in reformatting when renaming
  * you can always switch to "spaces" style, replace all TABs by 2
(4, 8) spaces (how about vice versus?)

> Also, requirements that code not need to be reformatted are merely yolks

I don't think this way. Yes, you can configure (almost) every editor to
run indent on your code after every keystroke, but this does not make the
code more structured (whatever meaning you use).

I suggest that we continue this mostly theoretical discussion in private.

> (add-hook 'c-mode-common-hook 'my-c-mode-common-hook)

You can use inline lambda function here (just to show how I know lisp).
There is no problems with hooks, the only missing thing was the
variable/function name to set/call to get the asked behaviour of
parentheses. This was the question. I would better not ask it. :-)

> indentation, then using C-c C-o to change it.

There is no C-c C-o in my emacs-20.3.1 without ~/.emacs.

Regards,
Mikhael.

---

From: [email-masked] (Paul D. Smith)
Date: 17 Aug 1999 01:47:35 -0400

mg> Right. This is a reason number 3 from several. I will list you all
  mg> in a private message if you like. And I know well that emacs is
  mg> very powerful.

Oh, no need.  I know a number of reasons people dislike Emacs.

  mg> So you say (you don't really say, I only guess), it must be:

  mg> a = my_first_long_named_function(my_param1,
  mg>                                  my_param2);
  mg> another_variant(param1,
  mg>                 param2
  mg>                 );

  mg> Very structured...

Yes, it is.

  mg> Now try to rename both functions.

I understood that was your concern, that was the origin my comment about
editors that re-indent easily.  I can change this name and re-indent it
all in a few of keystrokes.

Meanwhile, I find the above syntax _much_ simpler to parse than the
other examples, where the arguments and the function name run together
and it's difficult to see them.

YMMV, that's why it's called "style" :).

  mg> a = my_first_long_named_function(
  mg> 	my_param1,
  mg> 	my_param2);
  mg> another_variant(
  mg> 	param1,
  mg> 	param2
  mg> );

  mg> The problem is that very many peoples write the first case just
  mg> because emacs by default does this.

Or it could be that people _like_ the first style and find it more
readable.

  >> Linus is a very good programmer, but his views on coding style I take

  mg> I suggest you to take jokes with a grain of sugar. :-)

I actually never read all the way to the bottom to see his comments on
Emacs; I was commenting on the rest of it.  Now that I look, his
"linux-c-mode" definition is not complete if I understand his style
correctly; he also needs (setq indent-tabs-mode t)--that's the default
but people often turn it off.

  >> is Rob Pike. Reference on request.

  mg> I would like to read this. My favorite is my OOP teacher, the name
  mg> means nothing.

http://www.lysator.liu.se/c/pikestyle.html

Short, but truly the best comments on style I've ever read.  Of course,
that merely means they're closest to my perferences :).

Actually, all of the Culture docs at http://www.lysator.liu.se/c/ are
well worth a read (so is the rest of the stuff there).

  mg> The only really structured style is the one which doesn't use
  mg> spaces for indentation.

*shrug* I disagree, but that's OK.

  mg>   * you can always switch to "spaces" style, replace all TABs by 2
  mg> (4, 8) spaces (how about vice versus?)

M-x tabify / M-x untabify

Is that what you mean?

  mg> I don't think this way. Yes, you can configure (almost) every
  mg> editor to run indent on your code after every keystroke, but this
  mg> does not make the code more structured (whatever meaning you use).

My point is that "structure" is not so absolutely defined: I prefer
arguments that line up with the paren because it's simpler to see where
the function's arguments end, and it's simpler to find the name of the
function as your eye scans the page.  That, to me, is a more structured
code format.  YMMV.

The question of how the structure is added is completely separate.  It's
merely a matter of choosing the proper editor or configuring it
properly.  IOW, I wouldn't choose an indentation style because my editor
made some kinds of changes harder than others.

(Obviously you wouldn't reindent after every keystroke, but reindenting
a line after return and being able to reindent a function with a few
keystrokes is always useful--whatever structure you choose :)

  >> (add-hook 'c-mode-common-hook 'my-c-mode-common-hook)

  mg> You can use inline lambda function here (just to show how I know
  mg> lisp).

True, but if you add enough things it gets unwieldy.  Also, you can't
redefine the lambda so while you're testing, anyway, I find it best to
create a function that you can redefine easily without stopping/starting
the editor over and over.

  >> indentation, then using C-c C-o to change it.

  mg> There is no C-c C-o in my emacs-20.3.1 without ~/.emacs.

Yes there is.  Unless someone has gone Jack-the-Ripper on your standard
Emacs installation.

Note you have to visit a C or C++ file first (or create one), it's only
bound in a CC-mode buffer of course.

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 17 Aug 1999 13:45:04 +0300 (IDT)

> %% Mikhael Goikhman <[email-masked]> writes:

So we speak about really incompatible meanings of "structured".

> it's only bound in a CC-mode buffer of course.

Oh, in c-mode I see all these position sensitive variables.
Thank you.

Regards,
Mikhael.