Re: planning the 10th fvwm birthday event

2002-09-18 Thread parv
in message [EMAIL PROTECTED],
wrote Mikhael Goikhman thusly...

 On 17 Sep 2002 14:00:26 -0600, Gregg Dameron wrote:
  
  Maybe Mr. Nation could be persuaded to retract feeble and designate his
  choice for a new word for F.  Failing that, how about a ballot, with
  the FAQ 1.1 choices, plus write-ins (I like Foundry, myself) and a choice
  of Keep the mystery.
 
 My choice is a recursive acronym. FVWM == FVWM's Virtual Window Manager.

yuck ... F. Virtual Window Manager seems ever more interesting.

-- 


--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Active Desk Label

2002-09-18 Thread Suzanne Skinner
The active desk label in the pager is not being hilighted properly at startup
(unless Xft is used?). I think this bug was introduced via the change Use
clipping redrawing for the desk label to DrawGrid(), as the hilight
background is never initially drawn.

The attached patch fixes the problem but it's probably overkill :-)

Suzanne

-- 
[EMAIL PROTECTED] - http://www.igs.net/~tril/
--- x_pager.c.orig  Wed Sep 18 01:40:57 2002
+++ x_pager.c   Wed Sep 18 01:41:56 2002
@@ -1663,7 +1663,7 @@
}
if(((Scr.CurrentDesk - desk1) == desk)  !ShapeLabels)
{
-   if (uselabel  erase)
+   if (uselabel)
{
XFillRectangle(
dpy,Desks[desk].title_w,Desks[desk].HiliteGC,


RE: FVWM: Re: planning the 10th fvwm birthday event

2002-09-18 Thread Riswick, J.G.A. van
 
yes, are there any special features planned for 2.6?

jos
-Original Message-
From: parv

   * Finish the 2.6 release before that day.

shouldn't that be an maybe item as that release will server nobody
if it would be only in name sake?  i would much prefer a stable
version (any of 2.[45].x) than the _necessary_ 2.6 ...
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Dominik Vogt
On Tue, Sep 17, 2002 at 02:00:27PM -0500, Eric Gillespie wrote:
 Dominik Vogt fvwm-workers@fvwm.org writes:
 
  Yes, there is a very good reason: configure chokes on the
  -Werror flag and produces more or less random test results.
  This can be hell to debug.  Maybe I can find a way to enable
  the original CFLAGS again before they are placed in the
  Makefiles.
 
 That is not generally sufficient, nor is setting the variables on
 the make command line.  There is a reason for the standard
 behavior.  If you have libraries installed outside the standard
 search path (/usr), you need to set CPPFLAGS and LDFLAGS before
 running configure.  The most famous examples are /usr/X11R6 and
 /usr/local (yes, i know most (all?) GNU/Linux distributions put
 those on the standard search path, but that's just lunacy), but
 there are also things like /opt and /usr/pkg (where NetBSD
 packages are installed).

Okay, but what about CFLAGS?  I don't care much about the CPPFLAGS
or LDFLAGS.  And by the way, the paths of all libraries that fvwm
uses can be set with configure options.

 And no, it isn't generally sufficient for the configure script to
 set the appropriate options itself.  That is necessary for the
 standard options (-L and -I), but not sufficient because
 sometimes platform- or site-specific settings are needed.  For
 example, on NetBSD we always set an rpath with -Wl,-R, but on
 Darwin the linker will explode since it has no -R option.
 Configure scripts would be a mess if they had to handle this sort
 of thing.
 
 I say generally because, in my experience, it is not necessary
 to set these variables with fvwm.  I think it's picking up
 /usr/{X11R6,pkg}/{include,pkg} from the gtk-config script.  So
 the above paragraph may not apply to Fvwm (someone not using the
 Gtk stuff will have to comment), but it's good to keep in mind
 anyway.  And it may be worth sticking with the standard behavior
 so as not to violate the principle of least surprise, if for no
 other reason.
 
 As for the -Werror example, that is just user error.  There are
 things you need to put into CPPFLAGS (defines and includes), and
 there are things you can put in there that will break (code
 generation or scanning flags).

No, it isn't necessarily a user error.  Sometimes, when one of the
autoconf/automake files has changed, an I type

  $ make CFLAGS=-Wall -Werror -O2 -g

configure is rerun automatically with the CFLAGS I passed to make.
When configure is not run, these options are fine.  It's tedious
to keep that in mind.  Last time I wasted half an hour hunting
bugs that were not there just because configure detected a
non-ANSI C compiler and did funny things in config.h.

Of course I can just strip the -Werror from the CFLAGS, but
non-gcc users won't profit then.

How about this:  write a small test program that issues lots of
warnings with -Wall and AC_TRY_COMPILE it.  When that fails,
configure bugs out with an error message.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Dominik Vogt
On Wed, Sep 18, 2002 at 10:30:52AM +0200, fvwm-workers wrote:
[snip]
 How about this:  write a small test program that issues lots of
 warnings with -Wall and AC_TRY_COMPILE it.  When that fails,
 configure bugs out with an error message.

This is the test code I came up with.  To the best of my
knowledge, every ANSI C compiler should be able to compile it, but
not without warnings:

--- warn.c ---
  #include stdio.h
  main(const i, const int * const p)
  {
char *c;

switch (*p = p = *c)
{
case 0:
  printf(%p, c, p);
}
*c = i;
c = p;
while (1 || (unsigned int)3 = 0 ||
   ((int)-1) == ((unsigned int)1));

return;
  }
--

It's meant to provoke a number of non-fatal warnings that would
cause compilation to fail with -Werror or a similar option in
other compilers.  It's very important that it doesn't fail without
such an option.  So I ask everybody to review it and/or try to
compile it with

  $ cc warn.c

If it doesn't compile with any *C* compiler, please report back.
I'm fully aware that it won't compile on *C++* compilers.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: FVWM: Re: planning the 10th fvwm birthday event

2002-09-18 Thread Dominik Vogt
On Wed, Sep 18, 2002 at 10:10:34AM +0200, Riswick, J.G.A. van wrote:
  
 yes, are there any special features planned for 2.6?

Other than what we do anyway?  No.  What exactly would a special
feature be?  All menus being decorated with a birthday cake in
the backgroung on that day?

 jos
 -Original Message-
 From: parv
 
* Finish the 2.6 release before that day.
 
 shouldn't that be an maybe item as that release will server nobody
 if it would be only in name sake?  i would much prefer a stable
 version (any of 2.[45].x) than the _necessary_ 2.6 ...

What I have in mind is a release that we can point at that isn't
two years old.  I am planning to spend less time before the 2.6
release anyway.  I will definitely not push it if it isn't
stabilizing fast enough.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


CVS domivogt: * Added a compile test program in configure; bug out if it doesn't compile.

2002-09-18 Thread FVWM CVS
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: domivogt02/09/18 04:34:57

Modified files:
.  : ChangeLog configure.in 

Log message:
* Added a compile test program in configure; bug out if it doesn't compile.

--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Ulrich Fahrenberg
On Wed, 18 Sep 2002, Dominik Vogt wrote:

 --- warn.c ---
   #include stdio.h
   main(const i, const int * const p)
   {
 char *c;

 switch (*p = p = *c)
 {
 case 0:
   printf(%p, c, p);
 }
 *c = i;
 c = p;
 while (1 || (unsigned int)3 = 0 ||
((int)-1) == ((unsigned int)1));

 return;
   }
 --

 So I ask everybody to review it and/or try to compile it

I'm at work, SPARC Solaris 5.8. gcc complains a lot many times, but
compiles happily, as expected. But Sun's own proprietary forte-cc
fails to compile it.

uli

-- 
Ulrich Fahrenberg -- http://www.math.auc.dk/~uli

--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Dominik Vogt
On Wed, Sep 18, 2002 at 01:27:09PM +0200, Ulrich Fahrenberg wrote:
 On Wed, 18 Sep 2002, Dominik Vogt wrote:
 
  --- warn.c ---
#include stdio.h
main(const i, const int * const p)
{
  char *c;
 
  switch (*p = p = *c)
  {
  case 0:
printf(%p, c, p);
  }
  *c = i;
  c = p;
  while (1 || (unsigned int)3 = 0 ||
 ((int)-1) == ((unsigned int)1));
 
  return;
}
  --
 
  So I ask everybody to review it and/or try to compile it
 
 I'm at work, SPARC Solaris 5.8. gcc complains a lot many times, but
 compiles happily, as expected. But Sun's own proprietary forte-cc
 fails to compile it.

Is that an ANSI C compiler?  If it is, what problems does it have?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Dan Espen
Dominik Vogt fvwm-workers@fvwm.org writes:
 On Wed, Sep 18, 2002 at 10:30:52AM +0200, fvwm-workers wrote:
 [snip]
  How about this:  write a small test program that issues lots of
  warnings with -Wall and AC_TRY_COMPILE it.  When that fails,
  configure bugs out with an error message.
 
 This is the test code I came up with.  To the best of my
 knowledge, every ANSI C compiler should be able to compile it, but
 not without warnings:

Solaris 8 (yes, its an ANSI compiler):

fork cc dominik.c   
dominik.c, line 6: left operand must be modifiable lvalue: op =
dominik.c, line 6: left operand must be modifiable lvalue: op =
dominik.c, line 11: warning: improper pointer/integer combination: op =
dominik.c, line 12: warning: assignment type mismatch:
pointer to char = const pointer to const int
cc: acomp failed for dominik.c
fork cc -V   
cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15

HPUX11.11:

peterpan cc dominik.c
cc: dominik.c, line 6: error 1549: Modifiable lvalue required for assignment 
operator.
cc: dominik.c, line 6: error 1549: Modifiable lvalue required for assignment 
operator.
cc: dominik.c, line 11: warning 526: Pointer implicitly converted to integral 
value in assignment.
cc: dominik.c, line 12: warning 611: Qualifiers are not assignment-compatible.
peterpan cc -V dominik.c
cpp.ansi: HP92453-01 B.11.11.02 HP C Preprocessor (ANSI)
ccom: HP92453-01 B.11.11.02 HP C Compiler

AIX 5.1:

dumbo cc dominik.c
dominik.c, line 6.18: 1506-068 (W) Operation between types const int* const 
and unsigned char is not allowed.
dominik.c, line 6.16: 1506-025 (S) Operand must be a modifiable lvalue.
dominik.c, line 11.6: 1506-068 (W) Operation between types unsigned char 
and const int* is not allowed.
dominik.c, line 12.5: 1506-068 (W) Operation between types unsigned char* 
and const int* const is not allowed.
dumbo cc -V
  VisualAge C++ Professional / C for AIX Compiler, Version 5


-- 
Dan Espen   E-mail: [EMAIL PROTECTED]
444 Hoes Lane  Room RRC 1C-214  Phone: (732) 699-5570
Piscataway, NJ 08854
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Eric Gillespie
Dominik Vogt fvwm-workers@fvwm.org writes:

 Okay, but what about CFLAGS?  I don't care much about the

You're probably OK resetting CFLAGS; anything someone will need
to add to build it would be a define, include path, or library
path, i should think.  You never know though, and there's still
the principle of least surprise, since fvwm's configure script
will behave differently than other configure scripts.

 CPPFLAGS or LDFLAGS.  And by the way, the paths of all
 libraries that fvwm uses can be set with configure options.

Sure, it will add a -L, but not a -Wl,-R or any other platform-
or site-specific flag.

 No, it isn't necessarily a user error.  Sometimes, when one of
 the autoconf/automake files has changed, an I type
 
   $ make CFLAGS=-Wall -Werror -O2 -g
 
 configure is rerun automatically with the CFLAGS I passed to
 make.

Ah, good old automake.  Rerunning the configure script is evil,
for this reason and many others.  Since my advice don't use
automake probably isn't something anyone is interested in
hearing, resetting only CFLAGS like you suggested will probably
be OK.

While we're on this, let me point out one of the other reasons
rerunning the configure script is evil.

0 fvwm% cat ../configure/fvwm
#! /bin/sh

CFLAGS=-g
CPPFLAGS='-I/usr/pkg/include'
LDFLAGS=-Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/X11R6/lib
export CFLAGS CPPFLAGS LDFLAGS

sh ./configure \
--disable-gnome-hints \
--without-gnome \
--disable-sm \
$@

I have a similar script for every package i install.  Luckily for
me, the only automake-using package is fvwm, for which my
CPPFLAGS and LDFLAGS settings are apparently unnecessary because
it will pick them up from the gtk-config script.  If it weren't
for that luck, the automake-generated would happily run a
configure script incorrectly and things would explode.

 How about this: write a small test program that issues lots of
 warnings with -Wall and AC_TRY_COMPILE it.  When that fails,
 configure bugs out with an error message.

I guess you meant -Werror?  I don't see what you're trying to
accomplish though.

--  
Eric Gillespie * [EMAIL PROTECTED]

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Dominik Vogt
On Wed, Sep 18, 2002 at 08:33:32AM -0500, Eric Gillespie wrote:
 Dominik Vogt fvwm-workers@fvwm.org writes:
[snip]
  How about this: write a small test program that issues lots of
  warnings with -Wall and AC_TRY_COMPILE it.  When that fails,
  configure bugs out with an error message.
 
 I guess you meant -Werror?  I don't see what you're trying to
 accomplish though.

Currently:

 $ touch configure.in
 $ make CFLAGS=-Wall -Werror
 = make reruns configure
 = some configure test programs fail because of the warnings in
some header files
 = features are detected/missed incorrectly (e.g. AC_C_CONST
detects a non-ansi compiler and adds #define const to
config.h)
 = bad surprises when compiling (in other words: BOOM)
 = lots of time wasted debugging imagined problems

Hopefully in the future:

 $ touch configure.in
 $ make CFLAGS=-Wall -Werror
 = make reruns configure
 = configure refuses to run

Of course I'd rather have configure not run automatically.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


CVS domivogt: * Updated compile test program (removed const).

2002-09-18 Thread FVWM CVS
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: domivogt02/09/18 08:55:18

Modified files:
.  : ChangeLog configure.in 

Log message:
* Updated compile test program (removed const).

--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Dominik Vogt
On Wed, Sep 18, 2002 at 08:35:22AM -0400, Dan Espen wrote:
 Dominik Vogt fvwm-workers@fvwm.org writes:
  On Wed, Sep 18, 2002 at 10:30:52AM +0200, fvwm-workers wrote:
  [snip]
   How about this:  write a small test program that issues lots of
   warnings with -Wall and AC_TRY_COMPILE it.  When that fails,
   configure bugs out with an error message.
  
  This is the test code I came up with.  To the best of my
  knowledge, every ANSI C compiler should be able to compile it, but
  not without warnings:
 
 Solaris 8 (yes, its an ANSI compiler):
 
 fork cc dominik.c   
 dominik.c, line 6: left operand must be modifiable lvalue: op =
 dominik.c, line 6: left operand must be modifiable lvalue: op =
 dominik.c, line 11: warning: improper pointer/integer combination: op =
 dominik.c, line 12: warning: assignment type mismatch:
 pointer to char = const pointer to const int
 cc: acomp failed for dominik.c
 fork cc -V   
 cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15

Does it compile if you remove the conts bits?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


CVS olicha: * Fixed active desk label in the pager (Suzanne Skinner)

2002-09-18 Thread FVWM CVS
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: olicha  02/09/18 08:56:51

Modified files:
modules: ChangeLog 
modules/FvwmPager: x_pager.c 

Log message:
* Fixed active desk label in the pager (Suzanne Skinner)

--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Active Desk Label

2002-09-18 Thread Olivier Chapuis
On Wed, Sep 18, 2002 at 02:35:44AM -0400, Suzanne Skinner wrote:
 The active desk label in the pager is not being hilighted properly at startup
 (unless Xft is used?). I think this bug was introduced via the change Use
 clipping redrawing for the desk label to DrawGrid(), as the hilight
 background is never initially drawn.
 
 The attached patch fixes the problem but it's probably overkill :-)
 

No, no it is ok, applied.
Thanks, Olivier
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


CVS migo: * commit perllib documentation changes that are already on the web

2002-09-18 Thread FVWM CVS
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: migo02/09/18 09:00:13

Modified files:
bin: fvwm-perllib.in 
perllib: ChangeLog 
perllib/FVWM   : Module.pm.in 
Added files:
tests/random   : randomsc.db 

Log message:
* commit perllib documentation changes that are already on the web

--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Dan Espen
Dominik Vogt fvwm-workers@fvwm.org writes:
 On Wed, Sep 18, 2002 at 08:35:22AM -0400, Dan Espen wrote:
  Dominik Vogt fvwm-workers@fvwm.org writes:
   On Wed, Sep 18, 2002 at 10:30:52AM +0200, fvwm-workers wrote:
 Does it compile if you remove the conts bits?

Yes.

I changed 1 line like this:

main(int i, int * p)

Solaris:

fork cc dominik.c
dominik.c, line 6: warning: improper pointer/integer combination: op =
dominik.c, line 6: warning: improper pointer/integer combination: op =
dominik.c, line 11: warning: improper pointer/integer combination: op =
dominik.c, line 12: warning: assignment type mismatch:
pointer to char = pointer to int

HPUX:

peterpan cc dominik.c
cpp.ansi: HP92453-01 B.11.11.02 HP C Preprocessor (ANSI)
cc: dominik.c, line 6: warning 526: Pointer implicitly converted to integral 
value in assignment.
cc: dominik.c, line 11: warning 526: Pointer implicitly converted to integral 
value in assignment.
cc: dominik.c, line 12: warning 604: Pointers are not assignment-compatible.

AIX:

dumbo cc dominik.c
dominik.c, line 6.18: 1506-068 (W) Operation between types int* and 
unsigned char is not allowed.
dominik.c, line 6.14: 1506-068 (W) Operation between types int and int* 
is not allowed.
dominik.c, line 11.6: 1506-068 (W) Operation between types unsigned char 
and int* is not allowed.
dominik.c, line 12.5: 1506-068 (W) Operation between types unsigned char* 
and int* is not allowed.

-- 
Dan Espen   E-mail: [EMAIL PROTECTED]
444 Hoes Lane  Room RRC 1C-214  Phone: (732) 699-5570
Piscataway, NJ 08854
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: CVS olicha: * A Transparent and clipping patch

2002-09-18 Thread Mikhael Goikhman
On 13 Sep 2002 05:28:54 -0500, FVWM CVS wrote:
 
 Log message:
 * A Transparent and clipping patch
 * Starting implementation of Root Transparency (E method)
 * Progress in tinting the Transparent colorset
 * Implemented clipping redrawing in IconMan and Ident. IconMan should not
 flicker any more with xft fonts and icons with alpha. Should do that
 for all modules and menu ...
 * Some clean up and fixes in IconMan. There is very strange things in
 IconMan code! Tried to fix some ... Colorsets should work as expected now.
 * New RetainPixmap option to the Backer.
 * The new RootTransparent colorset should work in menu (not animated)
 IconMan and Ident. You should set your background with an Esetroot or
 fvwm-root compatible program. You can also use FvwmBacker and the new
 RetainPixmap option. Tint should works.
 * Tinting the Transparent colorset may work under certain condition
 with menu, IconMan and Ident. The first condition is to have an
 X server with BackingStore enabled (not needed for menu). The second is
 to use the ParentalRelativity style. The third one is to use BackingStoreOff
 style, yes I say _off_ (for xft font and icon with tint/alpha).
 * Colorset may use XRrender, so link and init xrender with some modules
 * NOTE: Backing Store cause big problems with XRender and Xft. On my
 server it _seems_ that XRender and Xft does not respect the Backing Store
 attribute: with backing store XRender does not render on not visible
 part of the window (and it should/can as backing store is enabled),
 but no Expose event are generated when the part became visible (as
 backing store is enabled). I do not know yet a workaround ...
 This may cause problems with menus, but I do not yet understand the
 problem here ... Dominik, do menus use backing store if possible?

Something is wrong with Tint after this commit.

Without any config do:

  Colorset 5 fg white, bg average, TiledPixmap any-image
  MenuStyle * MenuColorset 5

Menu looks ok. Now:

  Colorset 5 fg white, bg average, TiledPixmap any-image, Tint yellow 30

Menu looks flat. Execute the first line without Tint, it is flat forever.
This behaviour Tint makes a colorset flat forever is not just in menus.

Regards,
Mikhael.
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


[Chung-chieh Shan [EMAIL PROTECTED]] Bug#161282: fvwm: core dumped by ssh-askpass

2002-09-18 Thread Alexander Kotelnikov
Hi.

And this is true :( Just ssh-askpass run makes fvwm cash.

---BeginMessage---
Package: fvwm
Version: 2.4.10-1
Severity: important

When I run ssh-askpass, fvwm crashes.  This did not use to happen with
the previous version of fvwm (2.4.9-1).  My ssh-askpass package is at
version 1:1.2.0-2.1.  For now, I have switched to ssh-askpass-gnome,
which does not crash fvwm.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux proper 2.4.19 #2 Wed Aug 28 01:32:40 EDT 2002 i686
Locale: LANG=C, LC_CTYPE=en_US

Versions of packages fvwm depends on:
ii  libc62.2.5-14.2  GNU C Library: Shared libraries an
ii  libglib1.2   1.2.10-6The GLib library of C routines
ii  libgtk1.21.2.10-14   The GIMP Toolkit set of widgets fo
ii  libncurses5  5.2.20020112a-8 Shared libraries for terminal hand
ii  libreadline4 4.3-4   GNU readline and history libraries
ii  libstroke0   0.5.1-2 support for mouse strokes like tho
ii  xlibs4.2.1-0pre1v1   X Window System client libraries

-- no debconf information


-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Please don't misrepresent my identity or violate any copyrights
or applicable legal restrictions, but otherwise, have fun.


pgpK4burBGbaQ.pgp
Description: PGP signature
---End Message---


-- 
Alexander Kotelnikov
Saint-Petersburg, Russia


Re: [Chung-chieh Shan [EMAIL PROTECTED]] Bug#161282: fvwm: core dumped by ssh-askpass

2002-09-18 Thread Dominik Vogt
On Wed, Sep 18, 2002 at 08:37:22PM +0400, Alexander Kotelnikov wrote:
 Hi.
 
 And this is true :( Just ssh-askpass run makes fvwm cash.
 
 Package: fvwm
 Version: 2.4.10-1
 Severity: important
 
 When I run ssh-askpass, fvwm crashes.  This did not use to happen with
 the previous version of fvwm (2.4.9-1).  My ssh-askpass package is at
 version 1:1.2.0-2.1.  For now, I have switched to ssh-askpass-gnome,
 which does not crash fvwm.

Is there a core file?  Please fetch us a stack trace:

  $ gdb fvwm core
  (gdb) where

 -- System Information:
 Debian Release: testing/unstable
 Architecture: i386
 Kernel: Linux proper 2.4.19 #2 Wed Aug 28 01:32:40 EDT 2002 i686
 Locale: LANG=C, LC_CTYPE=en_US
 
 Versions of packages fvwm depends on:
 ii  libc62.2.5-14.2  GNU C Library: Shared libraries 
 an
 ii  libglib1.2   1.2.10-6The GLib library of C routines
 ii  libgtk1.21.2.10-14   The GIMP Toolkit set of widgets 
 fo
 ii  libncurses5  5.2.20020112a-8 Shared libraries for terminal 
 hand
 ii  libreadline4 4.3-4   GNU readline and history 
 libraries
 ii  libstroke0   0.5.1-2 support for mouse strokes like 
 tho
 ii  xlibs4.2.1-0pre1v1   X Window System client libraries
 
 -- no debconf information

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: [Chung-chieh Shan [EMAIL PROTECTED]] Bug#161282: fvwm: core dumped by ssh-askpass

2002-09-18 Thread Alexander Kotelnikov
 On Wed, 18 Sep 2002 18:47:19 +0200
 DV == Dominik Vogt fvwm-workers@fvwm.org wrote:
DV 
DV On Wed, Sep 18, 2002 at 08:37:22PM +0400, Alexander Kotelnikov wrote:
 Hi.
 
 And this is true :( Just ssh-askpass run makes fvwm cash.
 
 Package: fvwm
 Version: 2.4.10-1
 Severity: important
 
 When I run ssh-askpass, fvwm crashes.  This did not use to happen with
 the previous version of fvwm (2.4.9-1).  My ssh-askpass package is at
 version 1:1.2.0-2.1.  For now, I have switched to ssh-askpass-gnome,
 which does not crash fvwm.
DV 
DV Is there a core file?  Please fetch us a stack trace:
DV 

Hmm. Rather simple to generate.

The stack is rather monotonous, even funny:

(gdb) bt 10
#0  0x08065292 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:632
#1  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#2  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#3  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#4  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#5  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#6  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#7  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#8  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#9  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
(More stack frames follow...)
(gdb) bt -20
#174670 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#174671 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#174672 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#174673 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#174674 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#174675 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#174676 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#174677 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#174678 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:682
#174679 0x08065425 in RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:772
#174680 0x08065250 in __restack_window (t=0x80ec730, do_lower=0, 
do_restack_transients=0, is_new_window=1) at stack.c:613
#174681 0x0806537f in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
---Type return to continue, or q return to quit---
allow_recursion=0, is_new_window=1) at stack.c:702
#174682 0x08065425 in RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=0, is_new_window=1) at stack.c:772
#174683 0x08064d17 in position_new_window_in_stack_ring (t=0x80ec730, 
do_lower=0) at stack.c:281
#174684 0x08081795 in AddWindow (w=25165833, ReuseWin=0x0) at add_window.c:1573
#174685 0x08067adf in HandleMapRequestKeepRaised (KeepRaised=0, ReuseWin=0x0)
at events.c:1158
#174686 0x08067a3d in HandleMapRequest () at events.c:1117
#174687 0x08069e3e in DispatchEvent (preserve_Tmp_win=0) at events.c:2991
#174688 0x08069ed8 in HandleEvents () at events.c:3044
#174689 0x08087e6f in main (argc=3, argv=0xba44) at fvwm.c:734

The crash point is

Program received signal SIGSEGV, Segmentation fault.
0x08065292 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
allow_recursion=1, is_new_window=0) at stack.c:632
632 {


DV   $ gdb fvwm core
DV   (gdb) where
DV 
 -- System Information:
 Debian Release: testing/unstable
 Architecture: i386
 Kernel: Linux proper 2.4.19 #2 Wed Aug 28 01:32:40 EDT 2002 i686
 Locale: LANG=C, LC_CTYPE=en_US
 
 Versions of packages fvwm depends on:
 ii  libc62.2.5-14.2  GNU C Library: Shared libraries 
 an
 ii  libglib1.2   1.2.10-6The GLib library of C routines
 ii  libgtk1.21.2.10-14   The GIMP Toolkit set of widgets 
 fo
 ii  libncurses5  5.2.20020112a-8 Shared libraries for terminal 
 hand
 ii  libreadline4 4.3-4   GNU readline and 

Re: CVS olicha: * A Transparent and clipping patch

2002-09-18 Thread Olivier Chapuis
On Wed, Sep 18, 2002 at 04:25:44PM +, Mikhael Goikhman wrote:
 
 Something is wrong with Tint after this commit.
 
 Without any config do:
 
   Colorset 5 fg white, bg average, TiledPixmap any-image
   MenuStyle * MenuColorset 5
 
 Menu looks ok. Now:
 
   Colorset 5 fg white, bg average, TiledPixmap any-image, Tint yellow 30
 
 Menu looks flat. Execute the first line without Tint, it is flat forever.
 This behaviour Tint makes a colorset flat forever is not just in menus.
 

So hi == sh? I cannot reproduce this (used fvwm-flying.xpm).
Is this average specific?

Olivier
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: CVS olicha: * A Transparent and clipping patch

2002-09-18 Thread Mikhael Goikhman
On 18 Sep 2002 23:01:29 +0200, Olivier Chapuis wrote:
 
 On Wed, Sep 18, 2002 at 04:25:44PM +, Mikhael Goikhman wrote:
  
  Something is wrong with Tint after this commit.
  
  Without any config do:
  
Colorset 5 fg white, bg average, TiledPixmap any-image
MenuStyle * MenuColorset 5
  
  Menu looks ok. Now:
  
Colorset 5 fg white, bg average, TiledPixmap any-image, Tint yellow 30
  
  Menu looks flat. Execute the first line without Tint, it is flat forever.
  This behaviour Tint makes a colorset flat forever is not just in menus.
  
 
 So hi == sh? I cannot reproduce this (used fvwm-flying.xpm).
 Is this average specific?

bg, hi and sh are just fine, but the colorset is Plain after Tint.
Just did again Restart fvwm -f no-rc and repeated these 3 commands
with fvwm-flying.xpm. It seems the first time I open a menu after Tint
I can see the image, but it disapears immediatelly.

Maybe a backing store problem?

  % xdpyinfo | grep back
  options:backing-store NO, save-unders NO

Regards,
Mikhael.
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Style * IconSize...

2002-09-18 Thread S. Anderson
greetings.
I might have some bugs for you guys.

Using fvwm 2.5.4 (from cvs) updated on Sep 18 2002
with support for: ReadLine, XPM, PNG, GNOME WM hints, EWMH hints, Shape,
SM, Xinerama, XFT

First of all when I issue a Style * IconSize 64 64 in FvwmConsole
nothing happens, to get it to work I have to put it in my .fvwm2rc
and restart, not sure if its supposed to work like that.

When I use a png Icon that is smaller than the IconSize, The png Icon
gets messed up.

You can reproduce this by putting just the following in your .fvwm2rc
(test.png attached to this mail)

Style * IconSize 64 64
Style * icon test.png
Mouse 0 2 A Iconify
Mouse 0 I A Iconify

thanks,
sa


test.png
Description: Binary data


Re: Style * IconSize...

2002-09-18 Thread Mikhael Goikhman
On 18 Sep 2002 18:00:25 -0600, S. Anderson wrote:
 
 Using fvwm 2.5.4 (from cvs) updated on Sep 18 2002
 with support for: ReadLine, XPM, PNG, GNOME WM hints, EWMH hints, Shape,
 SM, Xinerama, XFT
 
 First of all when I issue a Style * IconSize 64 64 in FvwmConsole
 nothing happens, to get it to work I have to put it in my .fvwm2rc
 and restart, not sure if its supposed to work like that.

It requires Recapture.

 When I use a png Icon that is smaller than the IconSize, The png Icon
 gets messed up.

Yes, I also saw this. But only if png has alpha channel, non-transparent
pngs seem to be ok.

Regards,
Mikhael.
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: Compile Issues

2002-09-18 Thread Eric Gillespie
Dominik Vogt fvwm-workers@fvwm.org writes:

 Currently:
 
  $ touch configure.in
  $ make CFLAGS=-Wall -Werror
  = make reruns configure
  = some configure test programs fail because of the warnings in
 some header files
  = features are detected/missed incorrectly (e.g. AC_C_CONST
 detects a non-ansi compiler and adds #define const to
 config.h)
  = bad surprises when compiling (in other words: BOOM)
  = lots of time wasted debugging imagined problems

Oh!  I thought it was bombing already, and that's what you were
trying to prevent.  Yes, what you describe looks pretty nasty.

--  
Eric Gillespie * [EMAIL PROTECTED]

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]