Re: FVWM: Re: planning the 10th fvwm birthday event
Dominik Vogt wrote: 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? shaped windows decorations? erik -- Visit the official FVWM web page at 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
Dominik Vogt 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 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: Style * IconSize...
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 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...
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: CVS olicha: * A Transparent and clipping patch
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 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
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 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
> On Wed, 18 Sep 2002 18:47:19 +0200
> "DV" == Dominik Vogt 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 to continue, or q 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
Re: [Chung-chieh Shan <[EMAIL PROTECTED]>] Bug#161282: fvwm: core dumped by ssh-askpass
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 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
Hi. And this is true :( Just ssh-askpass run makes fvwm cash. --- Begin Message --- 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: CVS olicha: * A Transparent and clipping patch
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 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
Dominik Vogt writes: > On Wed, Sep 18, 2002 at 08:35:22AM -0400, Dan Espen wrote: > > Dominik Vogt 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 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
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 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
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 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)
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 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
On Wed, Sep 18, 2002 at 08:35:22AM -0400, Dan Espen wrote: > Dominik Vogt 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 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).
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 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
On Wed, Sep 18, 2002 at 08:33:32AM -0500, Eric Gillespie wrote: > Dominik Vogt 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 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
Dominik Vogt 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 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
Dominik Vogt 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 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
On Wed, Sep 18, 2002 at 01:27:09PM +0200, Ulrich Fahrenberg wrote:
> On Wed, 18 Sep 2002, Dominik Vogt wrote:
>
> > --- warn.c ---
> > #include
> > 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 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
On Wed, 18 Sep 2002, Dominik Vogt wrote:
> --- warn.c ---
> #include
> 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 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.
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 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
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 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
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
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 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
On Tue, Sep 17, 2002 at 02:00:27PM -0500, Eric Gillespie wrote:
> Dominik Vogt 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 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
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 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
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,
