Subject: FvwmBanner shapes

From: Dan Espen <[email-masked]>
Date: Tue, 18 Sep 2001 08:48:31 -0400

I'm using current CVS.

This morning FvwmBanner using the default image isn't shaped anymore.

I'd guess this test is failing:

  if (FHaveShapeExtension && view.mask != None)
    FShapeCombineMask(dpy, win, FShapeBounding, 0, 0, view.mask, FShapeSet);

In libs/FShape.h I see 2 definitions of FHaveShapeExtension:

/* Shapes supported by server? */
#define FHaveShapeExtension 0

/* Shapes compiled in? */
#define FHaveShapeExtension      0

This is Solaris 8, the X Server supports shapes.

-- 
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: Alex Wallis <[email-masked]>
Date: Wed, 19 Sep 2001 01:43:06 +0930

> This morning FvwmBanner using the default image isn't shaped anymore.
Same here on redhat7.1

Alex

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 19 Sep 2001 09:25:37 +0200

> This is Solaris 8, the X Server supports shapes.

It's my fault.  The macro FHaveShapeExtension in libs/FShape.h is
always zero.  I think I'll just stop making releases.  Most of the
time, I'm under high pressure when making them and thus make a lot
of unnecessary mistakes.  This might be acceptable for beta
releases, but 'stable' releases with the current quality are
unacceptable.  Consider the fix for the shape problem commited.  I
think the 2.4.3 release should be built soon, but I'll stay out of
this discussion now.  Dan, could you again decide when the release
should be built?

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Dan Espen <[email-masked]>
Date: Wed, 19 Sep 2001 22:56:11 -0400

Dominik Vogt <[email-masked]> writes:
> I think the 2.4.3 release should be built soon, but I'll stay out of

The shape changes seemed to work, I tested xeyes, shaped icons in
the builtin icon box, FvwmIconBox, and FvwmBammer with shapes enabled.

Did you do any tests with shape support disabled at configure?
If not, I'll rebuild and give it a shot.

I'd imagine it would be hard to find an XServer without shape support
so if anyone has one, the tests  don't take long.  If no one has
one, I don't think its workh worring about since they can be disabled.

Anything else in the FShape change you think should be tested?

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 20 Sep 2001 11:38:52 +0200

> If not, I'll rebuild and give it a shot.

Judging from the recent problem, I did more tests with shapes
disabled that with shapes enabled.

> one, I don't think its workh worring about since they can be disabled.

I didn't test this, but perhaps it's possible to rename the
libXext... files?

This is how FShape.[ch] works:  THe header file is responsible for
including the shape.h header file if present.  Otherwise all the
objects defined in shape.h are defined in FShape.h.  Then, all
these macros, typdefs, functions etc. are aliased to a macro with
the same name, but a capital 'F' instead of the 'X'.

The FShapeInit() function queries the X server for the shape
extension and sets FShapesSupported, FShapeEventBase and
FShapeErrorBase accordingly.  The FHaveShapeExtension macro is set
to 1 if SHAPE is defined and to 0 if not (that's what caused the
FvwmBanner problem: it was always 0).  Without SHAPE defined, all
the functions are replaced with empty macros and FShapesSupported
is defined to 0.

With these definitions one can now simply write

  if (FHaveShapeExtension)
  {
     /* lots of code */
     if (FShapesSupported)
     {
        FShapeCombineRegion(...);
     }
  }

instead of using "ifdef SHAPE".  One big advantage is that the
syntax of all this code is always checked, even without SHAPE
defined.  The optimizer should remove the unnecessary code as

  if (FHaveShapeExtensinon/FShapesSupported)

is replaced by

  if (0)

> Anything else in the FShape change you think should be tested?

Basically, all modules with Colorset support also need the shape
extension.  They should all work with a shaped colorset.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Fri, 21 Sep 2001 15:44:37 -0400

> this discussion now.  Dan, could you again decide when the release

This weekend seems like a good time.

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 23 Sep 2001 09:05:53 +0200

> This weekend seems like a good time.

It seems good (now) for me too. One may check my IconMan
geometry fix, but it should be ok in the average ...

Regards, Olivier