Subject: CVS domivogt: *Updated INVOCATION section to reflect ModuleSynchronous.

From: CVS <[email-masked]>
Date: Thu, 19 Aug 1999 09:12:35 -0500 (CDT)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	99/08/19 09:12:35

Modified files:
	modules        : ChangeLog 
	modules/FvwmTheme: FvwmTheme.1 

Log message:
*Updated INVOCATION section to reflect ModuleSynchronous.

--
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: Thu, 19 Aug 1999 17:38:37 +0100

> *Updated INVOCATION section to reflect ModuleSynchronous.

I think you're wrong on this one Dominik.  Just making FvwmTheme finish
starting up before FvwmButtons is only going to be satisfactory if you
never try to change a colorset dynamically.  FvwmTheme has the ability
to change colorsets at any time and the other modules that have been
colorsetified all update themseleves whenever a colorset changes. The
reason I put this into FvwmTheme is that I think it would be very nice
if you could try out other peoples themes just by pasting the colorset
lines into an FvwmConsole.  Having to do a Recapture to update is bad
enough with styles but a Restart to update the modules is just too
slow.  I think we should fix FvwmButtons so that it follows colorset
changes.

I'm not saying that ModuleSynchronous should be deleted, it does reduce
redrawing at start up (it might also make it possible to swallow an
FvwmScroll-ed window).  I just think that the man page for FvwmTheme
should not say it is the only way to start it up.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 19 Aug 1999 13:53:04 -0400

> should not say it is the only way to start it up.

I'm going to have to agree with Tim on this one Dominik.  The wording
in the man page is a little to harsh for my taste.  You probablly want
something like FvwmTheme can be started with ModuleSynchronous to reduce
the number of repaints, by other modules during startup of fvwm.

But Tim I don't think Dominik was planning on leaving the colorset set
stuff the way it is in FvwmButtons he just commited what he had so far
so we could help with his xload/xclock problems.
-- 
--- 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: Thu, 19 Aug 1999 22:36:19 +0200

On Thu, Aug 19, 1999 at 05:38:37PM +0100, Tim Phipps wrote:
> slow.

That's not what I wanted to say. Of course you can change configurations
while the modules are running. But there is still the problem that
FvwmIconMan coredumps because fvwm sends the colour sets in reverse
order. What I was trying to say is that FvwmTheme should start *before*
all modules that want to use it. It makes the modules more stable and
reduces redrawing greatly.

> I think we should fix FvwmButtons so that it follows colorset changes.

No need to fix it, I wasn't finished rewriting it yet :)

> should not say it is the only way to start it up.

I know that it sounds a bit strong, but I don't want to have people
complaining in the future because they don't understand the
implications. And writing even more about startup seemed to be overkill
to me. If you are unhappy with the wording, feel free to change it,
but I'd prefer that the man page discourages people from experimenting
with FvwmTheme startup. If they do it as I wrote they can do nothing
wrong.

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: Brad Giaccio <[email-masked]>
Date: Fri, 20 Aug 1999 07:16:43 -0400

On Thu, Aug 19, 1999 at 10:36:19PM +0200, Dominik Vogt wrote:

> That's not what I wanted to say. Of course you can change
> configurations while the modules are running. But there is still the
> problem that FvwmIconMan coredumps because fvwm sends the colour sets
> in reverse order. What I was trying to say is that FvwmTheme should
> start *before* all modules that want to use it. It makes the modules
> more stable and reduces redrawing greatly.
>

It does?  I never saw this my setup creates 5 managers, using colorsets
2,3,4 of 0 through 4.  I usually see my initial managers get drawn in
the regular bg,fg colors. Then the change_colorset function gets called
when the colorsets actually arive.  Could you give me an example of when
it dumps?

Now the only time it does dump core, and this just occured to me last
night, is if FvwmTheme crashes.  That is because FvwmTheme allocates the
pixmap in the XServer (keep in mind a Pixmap is really an unsigned long,
which is the id of the real pixmap in the XServer).  But when FvwmTheme
dies X cleans up after it by freeing any on freed pixmaps.  So when one
of the modules tries to use one of the pixmaps they get a BadDrawable
(fatal error).

So what I think we might want to try is having FvwmTheme ask fvwm to create the pixmap and then return the long to FvwmTheme.  Any comments, Tim I hope you are reading this too.

Brad

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 20 Aug 1999 13:26:30 +0200

> when the colorsets actually arive.  Could you give me an example of when

Perhaps you need to use more colour sets? I saw the coredump is caused
by an all-zero colour set in this call:

  	XSetForeground (theDisplay, man->backContext[i], man->backcolor[i]);

(x.c, line 906).

It didn't happen again since I use ModuleSynchronous to start FvwmTheme.
I am definig colours sets 0 to 11 at the moment and the problem shows
about one time out of five. I think it will become more likely the more
colour sets you define (plus IconMan should use colour sets with low
numbers).

> So what I think we might want to try is having FvwmTheme ask fvwm to create the pixmap and then return the long to FvwmTheme.  Any comments, Tim I hope you are reading this too.

Sound like a good idea. If it doesn't slow down things considerably...

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: Fri, 20 Aug 1999 14:14:50 +0100

Dominik Vogt wrote:
> implications.

Fair enough, let's leave it.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 20 Aug 1999 14:38:10 +0100

Brad Giaccio wrote:

> night, is if FvwmTheme crashes.
> 
> So what I think we might want to try is having FvwmTheme ask fvwm to create
> the pixmap and then return the long to FvwmTheme.  Any comments, Tim I hope
> you are reading this too.

I think the simplest solution is to make sure FvwmTheme doesn't crash
;-)
If we create a MakeMeAPixmap command we would also need a DeletePixmap
to go with it and some means of synchronizing the request/response. 
Sounds a bit complex.

Another possibility is to use XSetCloseDownMode() in FvwmTheme so the
pixmaps and colors are not freed if FvwmTheme crashes.  This would
create color and pixmap leakage unless we could come up with a way for
FvwmTheme to free them when it restarts. Maybe
XSetCloseDownMode(Temporary) followed by XKillClient(AllTemporary) is
all that is needed.

Cheers,
Tim.