Re: Logo submission
On Thu, 2003-09-04 at 10:09, Uwe Pross wrote: http://www-user.tu-chemnitz.de/~uwp/fvwm_grill.jpg put this picture on the web site. It is funny, of course, It's hilarious but it's not a logo. I think it should go on the web page somewhere, maybe the cats page (erm - maybe not). How about a link to it on the links page. Cheers, Tim. Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and ARC International. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and telephone the above number. Incoming emails to ARC may be subject to monitoring other than by the addressee. -- 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 Logo submission
On Thu, 2003-09-04 at 10:09, Uwe Pross wrote: http://www-user.tu-chemnitz.de/~uwp/fvwm_grill.jpg put this picture on the web site. It is funny, of course, It's hilarious, but it's not a logo. I think it should go on the web page somewhere, maybe the cats page (erm - maybe not). How about a link to it on the links page. Cheers, Tim. Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and ARC International. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and telephone the above number. Incoming emails to ARC may be subject to monitoring other than by the addressee. -- 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: WindowStyle
Mikhael Goikhman wrote: There are some large issues with WindowStyle_proposal.txt to solve, like reduction of the StyleFunction otherwise it will grow infinitelly when switching themes, here the current Style is more optimal. Also currently multiple Style commands are queued and executed at once unless UpdateStyles is given. I really prefer the Olivier solution before 2.6.0. I am not even sure it is not the best for the long run. Style list with all its optimizations is not nessesarily a bad thing, so adding WindowStyle to it may be good. Thinking some more about this I think the patch should be applied. It doesn't stop us changing the internal format of the style list in the future and if it works well there will be no need anyway. Cheers, Tim. -- 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: StyleById patch voting thread
Mikhael Goikhman wrote: On 08 Jun 2003 14:24:58 +0100, Tim Phipps wrote: I've got some free time now and I was thinking of implementing the WindowStyle command that was proposed ages ago. I think this means I vote no (not very strongly) but I'd appreciate some help in reviewing the proposal in the light of the current state of Fvwm. Can you please provide some arguments? Do you see your proposed WindowStyle command any different (in terms of syntax and meaning) from the new command added by the posted patch? For me they are identical, so your ideas become more real in the long run. Or you mean that there may be the different implementation after 2.6.0? Because starting to replace Style now before 2.6.0 is not a possibility. I don't mean to change or remove the Style command so I don't want to wait until after 2.6.0. The old proposal is to create a new command WindowStyle that sets the style of the target window. It would be called as WindowStyle Sticky in which case it operates on the target window or as WindowID XXX (conditions) WindowStyle Sticky in which case it operates on the window XXX. The WindowStyle command would not do any pattern matching, It would use the pattern matching of WindowId so that if the WindowId command were to be upgraded to use a Class=pattern that syntax would be usable in the WindowStyle and Style commands for free. The old proposal is also to change the Style command to manipulate a StyleFunction function rather than have it maintain a style list. The StyleFunction would be run on every window that is created and would consist of a sequence of WindowId XXX (condition) WindowStyle YYY lines. The proposal would have to implement a command to delete lines from a function as a method of controlling the growth of the style list. As a debug aid there would be a PrintFunction command which would probably be useful on its own anyway. As I see it the new StyleByID proposal would complicate the (already complicated?) Style function and style list management. The old proposal would simplify the style list management. The new proposal would require extra code to handle the deletion of windows, the old proposal does not need to do this. The new proposal may change the behaviour of Recapture by making the StyleById settings more powerful than simple Style commands, I'm not sure if this is the intention. If it isn't then the Recapture command would have to delete all the Style id=XXX settings from the style list or do something clever. Cheers, Tim. -- 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: StyleById patch voting thread
Olivier Chapuis wrote: Seems that there is no conclusion here. It seems that there is two votes for it (me and Mikhael) one vote against (Dominik) and one unclear vote (Dan). So I ask for more votes and clarification I've got some free time now and I was thinking of implementing the WindowStyle command that was proposed ages ago. I think this means I vote no (not very strongly) but I'd appreciate some help in reviewing the proposal in the light of the current state of Fvwm. Cheers, Tim. -- 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: StyleById
Mikhael Goikhman wrote: Is this a final syntax we want to have? I prefer: Pick WindowStyle NoTitle, !Borders I think Tim suggested this syntax some years ago together with SetupFunction, but I can't verify this right now. I did, the spec is in WindowStyle_proposal.txt in CVS. I was waiting for the feature freeze to be over before starting on it. Cheers, Tim. -- 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: your say
Mikhael Goikhman wrote: Tim, everyone is patiently waiting for your say. Regards, Mikhael. Shite! I was keeping quiet. I wish I hadn't said anything. I don't consider myself an FVWM developer at the moment, I haven't done anything for years but if you want my opinion here it is: I didn't sign up to the message about the World Trade Center attack and I won't sign up to the anti-war message this time. I can't forsee me putting my name to anything ever actually, I'm not even in the AUTHORS file. I think the only trace of me is a copyright on one of the wacky gradients I gave to my (now dead) budgie. That's the way I am. That said I have no problem with the message being included in the next release and I promise to try to keep out of any future non-fvwm discussions on the fvwm mailing lists. I hope everyone who wants to sign up does so without regret, if you feel it's the right thing to do don't worry about what others may say. You have to be true to yourself. Cheers, Tim. -- 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: The fvwm Ethical License
[EMAIL PROTECTED] wrote: - COPYING --- Before using this software, every user is expected to read the statements in the file ETHICAL_LICENSE that comes with the fvwm distribution. - I don't agree with this, I don't expect users of fvwm to even know it's GPL code. I don't expect the crazy people who compile the fvwm source to even read the COPYING file. When I'm compiling stuff from source I usually scan the first screen full of all files starting with capitial letters, I don't care if it's GPL or BSD as long as I can use it for free. I would be OK with you adding this to COPYING: === Before using this software, please read the ETHICAL_LICENSE file that comes with the fvwm distribution. === I also think you should put a short introduction to the ETHICAL_LICENSE file that lists those who support it. Not me I'm afraid, I'm British and I agree with the war against the Iraqi dictatorship. Cheers, Tim. -- 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]
Core dump in FvwmIconBox
Hi All,
I was just trying to have a look at the new spangly mozilla icons
and found a core dump in FvwmIconBox. Patch attached.
Cheers,
Tim.
Index: modules/ChangeLog
===
RCS file: /u/phippst/share/cvsroot/fvwm/modules/ChangeLog,v
retrieving revision 1.31
diff -u -r1.31 ChangeLog
--- modules/ChangeLog 2002/08/27 11:46:33 1.31
+++ modules/ChangeLog 2002/08/28 11:32:24
@@ -1,3 +1,7 @@
+2002-08-28 Hippo
+ * FvwmIconBox/icons.c:
+ Fixed core dump
+
2002-08-26 Mikhael Goikhman [EMAIL PROTECTED]
* FvwmButtons/dynamic.c:
Index: modules/FvwmIconBox/icons.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/modules/FvwmIconBox/icons.c,v
retrieving revision 1.7
diff -u -r1.7 icons.c
--- modules/FvwmIconBox/icons.c 2002/08/14 13:14:57 1.7
+++ modules/FvwmIconBox/icons.c 2002/08/28 11:28:31
@@ -236,9 +236,15 @@
/
void GetIconFromFile(struct icon_info *item)
{
- char *path = NULL;
+ char *path = PictureFindImageFile(item-icon_file, imagePath, R_OK);
FvwmPictureAttributes fpa;
+ if (NULL == path)
+ {
+ fprintf(stderr, [FvwmIconBox] cannot find %s on ImagePath
%s\n,
+ item-icon_file, imagePath);
+ return;
+ }
fpa.mask = FPAM_NO_ALLOC_PIXELS; /* olicha why ? */
if (Iconcolorset = 0 Colorset[Iconcolorset].do_dither_icon)
{
Re: Core dump in FvwmIconBox
Dominik Vogt wrote: CVS, or 2.4.x or both? CVS, but it might be in older releases Cheers, Tim. -- 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: Is 257 some sort of magic number?
Dmitry Yu. Bolkhovityanov wrote:
On Thu, 8 Aug 2002, Tim Phipps wrote:
/257 will take ages on any processor, /256 will take one cycle on most.
257 is the correct scale factor for conversion between 8- and
16-bit colors: 257==0x101, so that e.g. 0xFF becomes 0x if multiplied
by 0x101, not 0x100. Most of XFree86 code uses 0x101 as conversion factor
(see xc/{lib/X11/LRGB.c,programs/xcmsdb/xcmsdb.c}. Of course, when
scaling from 16 down to 8 bits 256 will work almost as good as 257, but
unification-wise 257 is better.
OK, I see. Multiplying by 257 is OK anyway since the compiler should
spit out a shift-or sequence but the conversion from 16 bit to 8 bit
should be a shift (or /256 which the compiler will change to a shift).
Cheers,
Tim.
--
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]
Is 257 some sort of magic number?
OK-find . -name '*.h' -o -name '*.c' | xargs grep -n 257 ./fvwm/ewmh_icons.c:343:fg[0] = colors[0].blue/257; ./fvwm/ewmh_icons.c:344:fg[1] = colors[0].green/257; ./fvwm/ewmh_icons.c:345:fg[2] = colors[0].red/257; ./fvwm/ewmh_icons.c:346:bg[0] = colors[1].blue/257; ./fvwm/ewmh_icons.c:347:bg[1] = colors[1].green/257; ./fvwm/ewmh_icons.c:348:bg[2] = colors[1].red/257; ./fvwm/ewmh_icons.c:425: c_new_icon[l++] = colors[k].blue/257; ./fvwm/ewmh_icons.c:426: c_new_icon[l++] = colors[k].green/257; ./fvwm/ewmh_icons.c:427: c_new_icon[l++] = colors[k].red/257; ./fvwm/ewmh_icons.c:454:c_new_icon[k] = (unsigned short)c.blue/257; ./fvwm/ewmh_icons.c:455:c_new_icon[k+1] = (unsigned short)c.green/257; ./fvwm/ewmh_icons.c:456:c_new_icon[k+2] = (unsigned short)c.red/257; ./libs/PictureGraphics.c:352: c.red/257, ./libs/PictureGraphics.c:353: c.green/257, ./libs/PictureGraphics.c:354: c.blue/257); ./libs/PictureImageLoader.c:535:c.blue = b * 257; ./libs/PictureImageLoader.c:536:c.green = g * 257; ./libs/PictureImageLoader.c:537:c.red = r * 257; ./libs/PictureUtils.c:324: c-pixel = PictureRGBtoPixel(c-red/257, c-green/257, c-blue/257); ./libs/PictureUtils.c:415: c.red = r*257; ./libs/PictureUtils.c:416: c.green = g*257; ./libs/PictureUtils.c:417: c.blue = b*257; ./libs/PictureUtils.c:444: c-red/257, c-green/257, c-blue/257); I can't help feeling that 257 is the wrong number for all this stuff and 256 is the correct number. It might be better to just leave most of these things as unsigned shorts or pass XColor's around and convert to byte size pieces as late as possible. /257 will take ages on any processor, /256 will take one cycle on most. Cheers, Tim. -- 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: The great focus policy rewrite
Dominik Vogt wrote: Do you have additional suggestions? Did I miss anything that could be added (I left out auto raising when the pointer enters a window on purpose). What about when windows are created, mapped or generally change state or do you think FvwmEvent is the way to handle this? Cheers, Tim. -- 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: * Implemented a new color limit method
Dan Espen wrote: Olivier Chapuis [EMAIL PROTECTED] writes: Why you do not trust me? I run my Xserver with depth 8 and I get no problems with all the app I can run (including netscape -no-install). I trust you, I just never heard of an X Server that supported 8 bit that way. I've done some Google searches and I still don't know whats going on. It could be that Oliviers Xserver has standard colormaps created on it (by some startup script). They are created by xstdcmap I think, I'm not sure how to query the server for them but if they are there they will use up lots of color cells and many applications will use them. If this is the case maybe we should think about getting fvwm to support them. Cheers, Tim. -- 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: * Implemented a new color limit method
But, when I run my Xserver with depth 8 (and fvwm allocate these 216 colors) I *cannot* reproduce any problems, I can run netscape, xv, gimp, any gtk/gnome apps, any kde apps ..etc without any problems. You may be being helped by your graphics card/Xserver. If your setup allows other colormaps to be active without deactivating the root colormap then it could be that netscape etc have allocated a private colormap and you don't notice. Other people on less advanced hardware will. It could be that your apps are sophisticated enough to cope with low availability of colors. There are plenty of ancient CAD applications around that fall over in a big heap if they don't get every color they ask for. The old method reduce colors in the good way only for xpm. Now I think we need to reduce colors for png, tinting and gradient. Moreover, the most important thing concerning colors with a pseudo color visual is that color allocation MUST never fail. I do not see an other method that this color table method. Instead of allocating colors you can query the colormap and find a close match to the one you want and just use it. I'm not sure if it's possible to find out if a color cell is allocated to another client or not so it may be that picking color cells like this leaves you exposed to the color of the cell changing. Maybe allocing the color of the cell (rather than the original color) would fix the cell color. Cheers, Tim. -- 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]
Pager changes
A couple of bugs with the recent pager changes: 1) *FvwmPager: BalloonYOffset -1 This is legal and means the balloon is above the pager window. FvwmPager is now complaining about this and changing it to +3 2) *FvwmPager: HilightColorset * 2 The colorset isn't being stretched to fill the window. Colorset 2 is VGradient 100 #006400 #008b00. It looks like the colorset is being shrunk to fit the default size of the pager but FvwmButtons stretches FvwmPager when it swallows it and the new size doesn't take. Cheers, Tim. -- 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: builtin command aliases
Dominik Vogt wrote: Alias GotoDesk MyGotoDesk Builtin GotoDesk Unalias GotoDesk How would this be different to just reversing to order of command look up? i.e. look for functions before built in commands. Cheers, Tim. -- 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: Fixed bit_gravity problem
fvwm-workers@fvwm.org wrote: Tim, does my latest commit fix all the bit_gravity problems you encountered? Yes, Thanks. -- 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]
core dump in colorset.c
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-40 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.2 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.2 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: I get a core dump when executing this line: Colorset 0 DGradient 100 #0f0f9f #ff, bg Average, fg Contrast, sh #0f0f9f, hi #ff The stack trace is: (gdb) where #0 0x3028c in parse_colorset (n=0, line=0xc4f81 ) at colorset.c:665 #1 0x45174 in CMD_Colorset (cond_rc=0xefffe280, eventp=0xab02c, w=54, fw=0x0, context=8, action=0xc4f31 0 DGradient 100 #0f0f9f #ff, bg Average, fg Contrast, sh #0f0f9f, hi #ff, Module=0xefffe1e8) at builtins.c:2240 #2 0x5a504 in execute_function (efa=0xefffe1d0) at functions.c:1394 #3 0x5a6b8 in old_execute_function (cond_rc=0xefffe280, action=0xc5a00 Colorset 0 DGradient 100 #0f0f9f #ff, bg Average, fg Contrast, sh #0f0f9f, hi #ff, fw=0x0, eventp=0xab02c, context=8, Module=-1, exec_flags=0, args=0xa8c00) at functions.c:1467 #4 0x5b1c8 in execute_complex_function (cond_rc=0x0, eventp=0xab02c, w=0, fw=0x0, context=8, action=0xa8c00 , Module=0xefffe450, desperate=0xc4a90) at functions.c:1973 #5 0x5a560 in execute_function (efa=0xefffe438) at functions.c:1413 #6 0x5a6b8 in old_execute_function (cond_rc=0x0, action=0xefffe4d8 my_look_ramp, fw=0x0, eventp=0xab02c, context=8, Module=0, exec_flags=0, args=0xa8c00) at functions.c:1467 #7 0x66ff0 in run_command_stream (f=0xab430, eventp=0xab02c, fw=0x0, context=8, Module=0) at read.c:143 #8 0x67158 in run_command_file (filename=0x0, eventp=0xab02c, fw=0x0, context=8, Module=0) at read.c:218 #9 0x672c4 in CMD_Read (cond_rc=0x0, eventp=0xab02c, w=54, fw=0x0, context=8, action=0xba2cd '/u/phippst/.f/fvwm2rc.m4.log'\n, Module=0xefffeaf8) at read.c:270 #10 0x5a504 in execute_function (efa=0xefffeae0) at functions.c:1394 #11 0x5a6b8 in old_execute_function (cond_rc=0x0, action=0xb9f18 Read '/u/phippst/.f/fvwm2rc.m4.log'\n, fw=0x0, eventp=0xab02c, context=8, Module=0, exec_flags=0, args=0xa8c00) at functions.c:1467 #12 0x51e64 in ExecuteModuleCommand (w=0, module=0, text=0xb9f18 Read '/u/phippst/.f/fvwm2rc.m4.log'\n) at module_interface.c:680 #13 0x53740 in ExecuteCommandQueue () at module_interface.c:1678 #14 0x4bd78 in My_XNextEvent (dpy=0xaeb08, event=0xab02c) at events.c:3366 #15 0x4b980 in HandleEvents () at events.c:3171 #16 0x61cb4 in main (argc=1, argv=0xe2e4) at fvwm.c:718 (gdb) print cs $1 = (colorset_struct *) 0xbafc8 (gdb) print cs-pixmap $2 = 25165911 (gdb) print cs-picture $3 = (FvwmPicture *) 0x0 -- 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: Tear off menus stop module messages
fvwm-workers@fvwm.org wrote: Fixed. Thanks, that's much better. Cheers, Tim. -- 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: Tear off menus stop module messages
fvwm-workers@fvwm.org wrote: On Tue, Apr 23, 2002 at 06:05:06PM -0400, Dan Espen wrote: If I'm on the right track, then I think the menu would have to release the grab once the menu is torn off Well, it does release the grabs. But as it is now, whenever the pointer enters a tear off menu, fvwm makes the grabs again. As long as fvwm is in the menu loop it doesn't really matter if the grabs are made or not - it can't handle module input anyway in that code. I think there might be a bug in the grabbing and it may be the reason I'm seeing it as a problem. I don't mind fvwm stopping module messages when the pointer is on the torn-off menu but it seems to keep the grab when the pointer moves off and it only releases it when the pointer enters another window. Normally the grab is released when the pointer leaves the torn off menu but if you use the keyboard to go from the torn off menu to a sub-menu and the use the keyboard to go back to the torn off menu and then move the pointer off the torn off menu the grab remains. You can see the grab is active because the cursor stays the same as on the menu. Cheers, Tim. -- 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: Colorsets
[EMAIL PROTECTED] wrote: I do not think the use of the SizeWindow was correct, it causes problem when you create the static gc in parse_colorset. If you take a look at the code the SizeWindow is created after the config file is read. Sorry, that was my fault. My fvwmrc defines the colorsets as part of the start function so I couldn't see the problem. Also, since a long times it is the Scr.NoFocusWin which is used for loading FvwmPicture, so I used the Scr.NoFocusWin (which is created as soon as possible with the good parameters) and I saw no more FvwmErrorHandler error ... so I think the change is good :o) Me too. Does this mean the mono gc in colorsets.c isn't needed? If not it could use Scr.MonoGC. Is there anyone out there with a monochrome monitor that can test it? Cheers, Tim. -- 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]
test -e not supported on Solaris (configure.in perl test)
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: configure bombs out becasue /bin/sh on Solaris 2.5 doesn't do [ -e $PERL ] -f works for me but it's probably not the right thing because that just tests for a regular file. -- 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: large PipeReads
[EMAIL PROTECTED] wrote: On 18 Apr 2002 13:46:21 -0600, Gregg Dameron wrote: Bottom line - PipeRead is brilliant, indispensable - I'd like to see itbe more so. My guess is that calling many shell utilities (read: many processes) is sometimes more expensive than one perl script doing the work. Moreover in pre-2.5.1 you may embed perl in fvwmrc without any additional processes to be called at all. You should only start FvwmPerl once and do 'SendToModule FvwmPerl eval perl-code' as many times as you want. Does this operate synchronously? One of the main reasons I use PipeRead is to do maths in fvwm functions i.e.: PipeRead bash -c 'echo some_fvwm_function $(($w * 10))' which will call some function with the windowid times 10. If FvwmPerl could do this it would be very useful to me (even though I'd have to learn perl first :-\ ) Cheers, Tim. -- 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]
Tear off menus stop module messages
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: When the pointer is on a tear off menu item fvwm stops processing module messages. The same thing happens when a normal menu is popped up but it's less noticeable since the menu is short lived. Repeat-By: Arrange for a shell script to update an FvwmButtons title every second via FvwmCommand. Tear off a menu. Put the mouse over then torn off menu item. Look at the button which should be updating. Move the pointer off. Watch the button catch up with the updates. -- 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: Colorsets
[EMAIL PROTECTED] wrote:
I still don't use fvwm-themes but I can confirm core dumps at least a
few times. However only if the config file contains the gradients, if I
use FvwmConsole to dump in the colorsets I get same errors, and the
gradients are changed, but they are not really gradients, more random
color masks. Also works the same if I use *FvwmTheme: Colorset.
Another patch that fixes my problems. It was due to running out of
colors on 8bit while having ReadWriteColors turned on.
This patch also initializes monochrome pixmaps to have a gray
background. It does three types for colorsets 0, 1 2 and then repeats
for any more. These pixmaps correspond to the ones fvwm uses by default
in mono for normal, focused and sticky windows. If modules are to use
them the colorsets the modules use must be referred to by fvwm before
the module starts e.g. put Colorset 2 in the StartFunction before the
modules are started.
This probably won't fix your problems, if it doesn't you should be able
to get a core dump by starting fvwm with the -debug flag to get
synchronous behaviour and then putting abort(); in the error handler
routine (fvwm.c line 1762).
Hope this helps,
Tim.
Index: libs/Colorset.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/libs/Colorset.c,v
retrieving revision 1.1
diff -u -r1.1 Colorset.c
--- libs/Colorset.c 2002/04/18 10:47:18 1.1
+++ libs/Colorset.c 2002/04/19 13:56:35
@@ -50,21 +50,15 @@
Colorset = (colorset_struct *)saferealloc((char *)Colorset,
++n * sizeof(colorset_struct));
- /* zero out the new members */
- memset(Colorset[nColorsets], 0, (n - nColorsets) * sizeof(colorset_struct));
-
- /* copy colorset 0 pixels into new members so that if undefined ones are
- * referenced at least they don't give black on black */
- if (n 1)
- {
+ /* zero out colorset 0
+ it's always defined so will be filled in during module startup */
+ if (n == 0)
+memset(Colorset[nColorsets], 0, (n - nColorsets) *
sizeof(colorset_struct));
+ else
+/* copy colorset 0 into new members so that if undefined ones are
+ * referenced at least they don't give black on black */
for ( ; nColorsets n; nColorsets++)
-{
- Colorset[nColorsets].fg = Colorset[0].fg;
- Colorset[nColorsets].bg = Colorset[0].bg;
- Colorset[nColorsets].hilite = Colorset[0].hilite;
- Colorset[nColorsets].shadow = Colorset[0].shadow;
-}
- }
+ memcpy(Colorset[nColorsets], Colorset, sizeof(colorset_struct));
nColorsets = n;
}
Index: fvwm/colorset.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/colorset.c,v
retrieving revision 1.3
diff -u -r1.3 colorset.c
--- fvwm/colorset.c 2002/04/19 10:27:23 1.3
+++ fvwm/colorset.c 2002/04/19 15:07:53
@@ -275,7 +275,7 @@
Window win = Scr.SizeWindow;
static GC gc = None, monoGC = None;
- /* initialize statucs */
+ /* initialize statics */
if (gc == None)
{
gc = fvwmlib_XCreateGC(dpy, win, 0, xgcv);
@@ -283,67 +283,7 @@
}
/* make sure it exists and has sensible contents */
- if (nColorsets = n) {
- Colorset = (colorset_struct *)saferealloc(
- (char *)Colorset, (n + 1) * sizeof(colorset_struct));
- memset(
- Colorset[nColorsets], 0,
- (n + 1 - nColorsets) * sizeof(colorset_struct));
- }
-
- /* initialize new colorsets to black on gray */
- while (nColorsets = n)
- {
- colorset_struct *ncs = Colorset[nColorsets];
-
- have_pixels_changed = True;
- if (privateCells XAllocColorCells(
- /* grab four writeable cells */
- dpy, Pcmap, False, NULL, 0, (ncs-fg), 4))
- {
- XColor *colorp;
-
- /* set the fg color */
- MyXParseColor(black, color);
- color.pixel = ncs-fg;
- XStoreColor(dpy, Pcmap, color);
- /* set the bg */
- MyXParseColor(gray, color);
- color.pixel = ncs-bg;
- XStoreColor(dpy, Pcmap, color);
- /* calculate and set the hilite */
- colorp = GetHiliteColor(ncs-bg);
- colorp-pixel = ncs-hilite;
- XStoreColor(dpy, Pcmap, colorp);
- /* calculate and set the shadow */
- colorp = GetShadowColor(ncs-bg);
- colorp-pixel = ncs-shadow;
- XStoreColor(dpy, Pcmap, colorp);
- }
- else
- {
- /* grab four shareable
Re: colorsets are now completely broken
fvwm-workers@fvwm.org wrote: Wasn't it planned to make the new code complatible with the old FvwmTheme way? Now, all my colour sets are gone. Bye Dominik ^_^ ^_^ Yes, I don't know what's gone wrong. The differences between FvwmTheme.c and colorset.c are fairly minor and I didn't have a problem with a TrueColor display. I've switched to a PseudoColor and things are going wrong. Things that have changed are: * The error handler, it used to core dump on just a few and was silent on the rest, now it prints a message * The cleanup routine that is used after a colorset pixmap is changed, it used to wait for a period of inactivity before deleting it, now it just waits 3 seconds for the change. Neither of these should have broken things badly, is it possible to get an equivalnce check between the current colorset.c and the one I sent in? I don't think the reformatting could have broken anything. Cheers, Tim. -- 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: Colorsets
[EMAIL PROTECTED] wrote:
[FVWM][FvwmErrorHandler]: ERROR *** internal error ***
[FVWM][FvwmErrorHandler]: ERROR Request 56, Error 13, EventType: 0
[FVWM][FvwmErrorHandler]: ERROR *** internal error ***
[FVWM][FvwmErrorHandler]: ERROR Request 72, Error 13, EventType: 0
I think these are being caused by parse_colorset() using a GC that has
not been created. I just assumed that Scr.MonoGC would be OK. Here's a
patch that makes parse_colorset() create it's own mono GC. It also
includes a debug message that you should see excatly once
Index: fvwm/colorset.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/colorset.c,v
retrieving revision 1.1
diff -u -r1.1 colorset.c
--- fvwm/colorset.c 2002/04/18 12:18:58 1.1
+++ fvwm/colorset.c 2002/04/18 14:08:49
@@ -273,7 +273,7 @@
XGCValues xgcv;
static char *name = parse_colorset;
Window win = Scr.SizeWindow;
- static GC gc = None;
+ static GC gc = None, monoGC = None;
/* make sure it exists and has sensible contents */
if (nColorsets = n) {
@@ -343,7 +343,9 @@
cs = Colorset[n];
if (gc == None)
{
+ fvwm_msg(DBG, name, Creating GCs);
gc = fvwmlib_XCreateGC(dpy, win, 0, xgcv);
+ monoGC = fvwmlib_XCreateGC(dpy, Scr.ScratchMonoPixmap,0, xgcv);
}
/* -- Parse the options -- */
@@ -444,18 +446,18 @@
{
XCopyArea(
dpy, cs-picture-mask,
- cs-mask, Scr.MonoGC,
+ cs-mask, monoGC,
0, 0,
cs-width, cs-height,
0, 0);
/* Invert the mask. We use it
to draw the background. */
XSetFunction(
- dpy, Scr.MonoGC,
GXinvert);
+ dpy, monoGC, GXinvert);
XFillRectangle(
dpy, cs-mask,
- Scr.MonoGC, 0, 0,
+ monoGC, 0, 0,
cs-width, cs-height);
- XSetFunction(dpy, Scr.MonoGC,
GXcopy);
+ XSetFunction(dpy, monoGC,
GXcopy);
}
}
}
@@ -520,7 +522,7 @@
dpy, mask,
picture-width, picture-height, 1);
if (cs-shape_mask !=
None)
{
- XCopyPlane(dpy,
mask, cs-shape_mask, Scr.MonoGC, 0, 0,
+ XCopyPlane(dpy,
mask, cs-shape_mask, monoGC, 0, 0,
picture-width, picture-height, 0, 0, 1);
}
}
Re: Colorsets
[EMAIL PROTECTED] wrote:
[FVWM][FvwmErrorHandler]: ERROR *** internal error ***
[FVWM][FvwmErrorHandler]: ERROR Request 56, Error 13, EventType: 0
[FVWM][FvwmErrorHandler]: ERROR *** internal error ***
[FVWM][FvwmErrorHandler]: ERROR Request 72, Error 13, EventType: 0
(EventType may be 19.)
Tim, can you please take a look at this?
There is a problem with ReadWriteColors on a PseudoColor display,
attached is a patch. I could not get the above errors to appear and I
get no errors unless I run out of colors. Even then things work OK.
I'll try to get mono to have a pixmap tomorrow.
Cheers,
Tim.
Index: configure.in
===
RCS file: /u/phippst/share/cvsroot/fvwm/configure.in,v
retrieving revision 1.2
diff -u -r1.2 configure.in
--- configure.in2002/04/18 12:18:57 1.2
+++ configure.in2002/04/18 12:20:03
@@ -73,7 +73,7 @@
dnl added -Wall for gcc, what about for others?
if test x$GCC = xyes; then
- CFLAGS=$CFLAGS -Wall
+ CFLAGS=$CFLAGS -Wall -Wno-implicit-int
fi
dnl Help finding POSIX functions on some systems
Index: fvwm/colorset.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/colorset.c,v
retrieving revision 1.2
diff -u -r1.2 colorset.c
--- fvwm/colorset.c 2002/04/18 14:37:56 1.2
+++ fvwm/colorset.c 2002/04/18 17:15:08
@@ -275,6 +275,13 @@
Window win = Scr.SizeWindow;
static GC gc = None, monoGC = None;
+ /* initialize statucs */
+ if (gc == None)
+ {
+ gc = fvwmlib_XCreateGC(dpy, win, 0, xgcv);
+ monoGC = fvwmlib_XCreateGC(dpy, Scr.ScratchMonoPixmap,0, xgcv);
+ }
+
/* make sure it exists and has sensible contents */
if (nColorsets = n) {
Colorset = (colorset_struct *)saferealloc(
@@ -288,6 +295,7 @@
while (nColorsets = n)
{
colorset_struct *ncs = Colorset[nColorsets];
+
have_pixels_changed = True;
if (privateCells XAllocColorCells(
/* grab four writeable cells */
@@ -317,36 +325,27 @@
/* grab four shareable colors */
if (Pdepth 2) {
/* monochrome monitors get black on white */
- /* FIXME: add a gray pixmap background */
- Colorset[nColorsets].fg = GetColor(black);
- Colorset[nColorsets].bg = GetColor(white);
- Colorset[nColorsets].hilite = GetColor(white);
- Colorset[nColorsets].shadow = GetColor(black);
+ /* FIXME: with a gray pixmap background */
+ ncs-fg = GetColor(black);
+ ncs-bg = GetColor(white);
+ ncs-hilite = GetColor(white);
+ ncs-shadow = GetColor(black);
}
else
{
- Colorset[nColorsets].fg = GetColor(black);
- Colorset[nColorsets].bg = GetColor(gray);
- Colorset[nColorsets].hilite =
- GetHilite(Colorset[nColorsets].bg);
- Colorset[nColorsets].shadow =
- GetShadow(Colorset[nColorsets].bg);
+ ncs-fg = GetColor(black);
+ ncs-bg = GetColor(gray);
+ ncs-hilite = GetHilite(ncs-bg);
+ ncs-shadow = GetShadow(ncs-bg);
}
/* set flags for fg contrast, bg average */
/* in case just a pixmap is given */
- Colorset[nColorsets].color_flags =
- FG_CONTRAST | BG_AVERAGE;
+ ncs-color_flags = FG_CONTRAST | BG_AVERAGE;
}
nColorsets++;
}
cs = Colorset[n];
- if (gc == None)
- {
- fvwm_msg(DBG, name, Creating GCs);
- gc = fvwmlib_XCreateGC(dpy, win, 0, xgcv);
- monoGC = fvwmlib_XCreateGC(dpy, Scr.ScratchMonoPixmap,0, xgcv);
- }
/* -- Parse the options -- */
while (line *line)
@@ -951,30 +950,10 @@
/* do nothing if it already exists */
if (n nColorsets)
return;
-
- /* increment n to get the required array size, get a new array */
- Colorset = (colorset_struct *)saferealloc(
- (char *)Colorset, ++n * sizeof(colorset_struct));
-
- /* zero out the new members */
- memset(
- Colorset[nColorsets], 0,
- (n - nColorsets) *
Re: Colorsets
[EMAIL PROTECTED] wrote: On 16 Apr 2002 15:13:30 +0100, Tim Phipps wrote: Is it time to move the colorset handling from FvwmTheme to fvwm? Actually moving the FvwmTheme code and replacing it with a pass-through module was on my todo list, near the top. But if you may do it, fine. I didn't plan to break any existing configs at this stage though. OK, I'll do a patch that moves FvwmTheme into fvwm, I'll leave removing stuff for later. We should also add DeleteColorset somewhen to emulate DestroyModuleConfig. There are problems with deleting colorsets that modules may be using since they share the resources rather than copy them. Would it be acceptable for DeleteColorset to reset the colorset to a simple default rather than really delete it? *) strip out every color type command from fvwm and all the modules Advantages: *) Much less code in the modules for color handling so less bugs *) Smaller man pages for the modules *) Initializing colorset 0 to black/white with a stipled pixmap background will enable monochrome monitors to have a 3d look and we can lose all the if (Pdepth 2) code *) by default fvwm and the modules won't alloc any color cells I don't know. I think this is 2 independent tasks. FvwmTheme may be obsoleted now without anyone noticing, but maybe removing non colorset color functionality may be done after 2.6.x, i.e. in 2.9.x? OK, I just thought that now might be a good time since we've just changed fvwm2 to fvwm. The main problem here is still TitleStyle, ButtonStyle, BorderStyle. Yes, I don't know what to do about these. I think these things are too complex at the moment what with add..style and decors. I am not sure about the last 2 advantages, maybe I don't understand it, but monochrome monitors don't really need to dictate the (ugly) default. There are lots of instances of code that only get used on monochrome monitors, do a grep for Pdepth and count the number of if (Pdepth 2)s. If fvwm's default colorset worked well on monochrome monitors we could remove all this code. The other point about not alloc'ing any color cells will only help users on PseudoColor displays. It means that fvwm would by default only alloc black and white. These are always there on PseudoColor displays so fvwm would not reduce the number of color cells available. Cheers, Tim. -- 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: Colorsets
fvwm-workers@fvwm.org wrote:
On Wed, Apr 17, 2002 at 01:02:25PM +, Mikhael Goikhman wrote:
Why not to have one if (Pdepth 2) when defining colorset 0 or any
unused/deleted colorset? The default for normal depths could be as it is
now, 4 colors: black on rgb:be/be/be and its shadow/hilight.
Good idea.
OK here's a patch that does the following:
* Replaces FvwmTheme with a dummy module that just sends the
Colorset and ReadWriteColors commands to fvwm
* Adds the new commands Colorset and ReadWriteColors to fvwm
* Initializes colorsets to black on gray for color screens and black
on white for mono
There's two files attached as well that need to go in the fvwm
directory. I haven't updated any man pages, could someone else do this
please?
Cheers,
Tim.
/* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#define FVWMTHEME_PRIVATE
#include libs/Colorset.h
#undef FVWMTHEME_PRIVATE
void set_readwrite_colors();
void parse_colorset(int n, char *line);
void cleanup_colorsets();
void alloc_colorset(int n);
/* Copyright (C) 2002 the late Joey Shutup.
*
* http://www.streetmap.co.uk/streetmap.dll?postcode2map?BS24+9TZ
*
* No guarantees or warranties or anything are provided or implied in any way
* whatsoever. Use this program at your own risk. Permission to use this
* program for any purpose is given, as long as the copyright is kept intact.
*/
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#define FVWMTHEME_PRIVATE
#include config.h
#include libs/fvwmlib.h
#include externs.h
#include fvwm.h
#include cursor.h
#include functions.h
#include misc.h
#include screen.h
#include colorset.h
#include module_interface.h
#include commands.h
#include libs/FShape.h
#include libs/Picture.h
extern int nColorsets; /* in libs/Colorset.c */
/* Globals */
static Bool privateCells = False; /* set when read/write colors used */
static Bool sharedCells = False;/* set after a shared color is used */
static char *black = black;
static char *white = white;
static char *gray = gray;
/* When fvwm destroys pixmaps it puts them on a list and only destroys them
* after some period of inactivity. This is necessary because changing colorset
* options rapidly may result in a module redrawing itself due to the first
* change while the second change is happening. If the module renders something
* with the colorset affected by the second change there is a chance it may
* reference pixmaps that FvwmTheme has destroyed, bad things would happen */
struct junklist {
struct junklist *prev;
Pixmap pixmap;
};
static struct junklist *junk = NULL;
static Bool cleanup_scheduled = False;
static void add_to_junk(Pixmap pixmap)
{
struct junklist *oldjunk = junk;
junk = (struct junklist *)safemalloc(sizeof(struct junklist));
junk-prev = oldjunk;
junk-pixmap = pixmap;
if (!cleanup_scheduled) {
CMD_Schedule(NULL, NULL, 0, NULL, 0, 3000 CleanupColorsets, NULL);
cleanup_scheduled = True;
}
}
void cleanup_colorsets()
{
struct junklist *oldjunk = junk;
while (junk)
{
XFreePixmap(dpy, junk-pixmap);
oldjunk = junk;
junk = junk-prev;
free(oldjunk);
}
cleanup_scheduled = False;
}
static void MyXParseColor(
char *spec, XColor *exact_def_return)
{
if (!XParseColor(dpy, Pcmap, spec, exact_def_return))
{
fvwm_msg(ERR, MyXParseColor, can't parse color \%s\,
(spec) ? spec : );
exact_def_return-red = 0;
exact_def_return-green = 0;
exact_def_return-blue = 0;
exact_def_return-flags |= DoRed | DoGreen | DoBlue;
}
return;
}
void CMD_ReadWriteColors(F_CMD_ARGS) {
static char *name = ReadWriteColors;
if (sharedCells)
Colorsets
Hi All, Is it time to move the colorset handling from FvwmTheme to fvwm? What I'm thinking of is: *) copy most of modules/FvwmTheme/FvwmTheme.c to fvwm/colorset.c *) new command Colorset that calls fvwm/colorset.c *) new command ReadWriteColors to replace *FvwmThemeReadWriteColors *) a very simple replacement for FvwmTheme that just turns config lines into Colorset commands and prints a warning. *) strip out every color type command from fvwm and all the modules Advantages: *) Much less code in the modules for color handling so less bugs *) Smaller man pages for the modules *) Initializing colorset 0 to black/white with a stipled pixmap background will enable monochrome monitors to have a 3d look and we can lose all the if (Pdepth 2) code *) by default fvwm and the modules won't alloc any color cells Disadvantages: *) lots of configs would break but the result would just be that everything uses colorset 0 so it would just look a bit boring. Cheers, Tim. -- 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]
fwvm2.1 symlink in wrong place
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: The symlink put in place to point the old man page to the new is in the wrong place. And xpmroot.1 too. Repeat-By: -find ~/share/man -name fvwm\* /u/phippst/share/man/man1/fvwm.1 /u/phippst/share/man/man1/fvwm-root.1 /u/phippst/share/man/man1/fvwm-config.1 /u/phippst/share/man/man1/fvwm-bug.1 /u/phippst/share/man/man1/fvwm-convert-2.2.1 /u/phippst/share/man/man1/fvwm-convert-2.4.1 /u/phippst/share/man/man1/fvwm-convert-2.6.1 /u/phippst/share/man/man1/fvwm-menu-xlock.1 /u/phippst/share/man/man1/fvwm-menu-directory.1 /u/phippst/share/man/man1/fvwm-menu-desktop.1 /u/phippst/share/man/man1/fvwm-menu-headlines.1 /u/phippst/share/man/fvwm2.1 -- 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: FvwmWinList scrambled by window closing
fvwm-workers@fvwm.org wrote:
On Tue, Apr 02, 2002 at 03:54:24PM +0100, Tim Phipps wrote:
I think this might be a bit_gravity problem. I can't get FvwmWinList to
have a gravity of anything other than NorthWest. Does fvwm2 force this?
Yes, it's essential to reduce redraws with opaque resize. I could
restore the bit_gravity if that helps. But for me, the problem
begins earlier: The FvwmWinList window does not resize at all.
The following patch removes the bit_gravity setting that fvwm does and
it fixes the problem with FvwmWinList. I don't think we should be
changing a clients bit gravity since I don't think there is a way to
tell the client we have done so. I don't know what the ICCCM has to say
about it.
The problem only occurs when FvwmWinList resizes itself. Is it possible
to only force the bit gravity when fvwm is doing the resizing?
Cheers,
Tim.
Index: fvwm/frame.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/frame.c,v
retrieving revision 1.10
diff -u -r1.10 frame.c
--- fvwm/frame.c2002/04/02 08:59:39 1.10
+++ fvwm/frame.c2002/04/10 09:07:57
@@ -525,12 +525,10 @@
int i;
/* using bit gravity can reduce redrawing dramatically */
- valuemask = CWWinGravity | CWBitGravity;
+ valuemask = CWWinGravity;
xcwa.win_gravity = grav-client_grav;
- xcwa.bit_gravity = grav-client_grav;
XChangeWindowAttributes(dpy, FW_W(fw), valuemask, xcwa);
xcwa.win_gravity = grav-parent_grav;
- valuemask = CWWinGravity;
XChangeWindowAttributes(dpy, FW_W_PARENT(fw), valuemask, xcwa);
if (!HAS_TITLE(fw))
{
Fpng.h Fxpm.h missing from libs/Makefile.am
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: Todays snapshot doesn't compile: FImageLoader.c:43: Fxpm.h: No such file or directory FImageLoader.c:44: Fpng.h: No such file or directory -- 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]
PNG stuff require libpng = 1.0.3b
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: The new PNG loading code requires libpng 1.0.3b or later due to it using png_set_gray_1_2_4_to_8(). I may be the only person on the planet using an older libpng, but if I'm not I think a configure check might be useful. png.h defines PNG_LIBPNG_VER if that helps. It should be 10005 or greater (10004 could be version 1.0.3a) -- 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 menu items drawn wrong outside the active area
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: The test of items is drawn with the ActiveColorset even though some parts of the text are outside the active area defined by the ItemFormat. This means the coordinate part of the windowlist is unreadable for the active item. Repeat-By: Set colorset 0 to be black on gray Set colorset 1 to be gray on black MenuStyle * HilightBack MenuStyle * MenuColorset 0 MenuStyle * ActiveColorset 1 MenuStyle * GreyedColorset 3, MenuStyle * Hilight3DThick MenuStyle * Animation MenuStyle * PopupOffset 0 100 MenuStyle * TrianglesSolid MenuStyle * ItemFormat %.4s%.5i%.1|%.5l%|%5.5r%.5r%5.5i%2.3 MenuStyle * AutomaticHotkeys WindowList I think there might be something wrong with the triangles too, the solid active triangle is drawn in what looks like the hilight color of the MenuColorset -- 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: window not hilighted
[EMAIL PROTECTED] wrote: On Thu, Mar 28, 2002 at 09:39:26AM +, Tim Phipps wrote: AddToFunc test + I MoveToDesk 0 -1 + I MoveTodesk 0 Current test 3) Probably the reason for (1) and (2): Although the window is unmapped and moved to another desk, fvwm still thinks it holds the current desk's focus. This is why it receives focus when it's moved back to the current desk. In my eyes, this is a bug. The function above should remove focus from the window. Opinions? In the function above the window is coming back so I want it to keep the focus. It wouldn't be a problem to add a FlipFocus though so changing the focus when the windows goeas to another desk would be OK. Cheers, Tim. -- 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: Idea for windowlist handling
[EMAIL PROTECTED] wrote: Hi, Key F11 A M Next (*) Focus This doesn't work with FlipFocus, but the Focus command spoils the most-recently-focused order of the windowlist. Ideally, the wm should know when we cycled to a window that we want focused, and move it to the start of the list, in contrast to the windows we only had to 'cycle over' to get there. I think it depends on what you want the one window list to do. For some purposes the most-recently-focused order is best (e.g. Alt-tab), for others the order of creation is best (e.g. Key F11 above). It may be that two lists are appropriate (same list, different linkages to get different order) but I like the way it is possible to order the windowlist with the mouse and then cycle around in a fixed order with the keyboard. To make this work, I had to do the following changes to Fvwm: Focus: don't alter the internal windowlist at all This was not the case, instead the newly focused window was rotated to front of the list. I eliminated this rotation (in function DoSetFocus in focus.c). This doesn't seem to have any bad effects (The displayed windowlist starts with the focused window anyway). Does FvwmWinList still match the WindowList menu? 2. I invented a new command ReshuffleWindows. It puts the window to the front of the internal window list, just as FlipFocus does. In contrast to FlipFocus it works on already focused windows. I think it might be better to make FlipFocus work on already focused windows rather than invent a new command, is this possible? Cheers, Tim. -- 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]
FvwmWinList scrambled by window closing
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: FvwmWinList gets messed up when the window at the top of the list closes. It looks like the old window names are not erased when the windowlist is redrawn. Repeat-By: *FvwmWinList: FollowWindowList Start several windows with different names Close one -- 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: FvwmWinList scrambled by window closing
[EMAIL PROTECTED] wrote: Description: FvwmWinList gets messed up when the window at the top of the list closes. It looks like the old window names are not erased when the windowlist is redrawn. Repeat-By: *FvwmWinList: FollowWindowList Start several windows with different names Close on I think this might be a bit_gravity problem. I can't get FvwmWinList to have a gravity of anything other than NorthWest. Does fvwm2 force this? Cheers, Tim. -- 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]
window not hilighted
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: The new window code sometimes does not hilight the focused window. Repeat-By: AddToFunc test + I MoveToDesk 0 -1 + I MoveTodesk 0 Current test The focused window is moved to desk -1 and then back, the focus doesn't change but the window borders are drawn as though it is unfocused. -- 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: Todays snapshot does not compile for me
[EMAIL PROTECTED] wrote: I hope that the next snapshot will compile. Tim what is the version of your Xlib? Is there, some where in your X11 headers, an XOpenOM declaration? There is no mention of XOpenOM in /usr/openwin/include, X11 is /usr/openwin/lib/libX11.so.4 if that helps. uname -a: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 Cheers, Tim. -- 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: Enh request: Silent something for non-existant something
[EMAIL PROTECTED] wrote: Ah, do you have a use for this in mind? Why would a user want to not be informed about syntax errors in his commands? Yes, I have a couple of instances where and event calls a function that may or may not exist. I have to do an AddToFunc my_destroy_$w I NOP before I call my_destroy_$w just in case my_destroy_$w hasn't been created. Cheers, Tim. -- 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]
Window State settings aren't saved across sessions/restarts
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: I'm having to use State 31 as a flag to indicate a window is the mozilla mail window. I can't use anything else as it changes it's name and the class/resource are useless. If I restart fvwm2 it doesn't restore the state bits and I lose track of the mozilla mail window. -- 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: rounding the window size
[EMAIL PROTECTED] wrote: Tim, can you remember the logic behind rounding the window size up or down? Shouldn't it always be rounded down except for interactive resizing? Yes. The reason for rounding up with interactive is to keep the pointer in the window when the resize is done so you don't get the focus changing to windows underneath the one being resized (nasty with sloppyfocus and autoraise). There is some extra logic to prevent the rounding up from moving the window border past the edges of the screen. Cheers, Tim. -- 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]
Enh request: Silent something for non-existant something
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR: /u/phippst/sunos/share/fvwm
FVWM_USERDIR: /u/phippst/.fvwm
Description:
FvwmCommand pants:
[FVWM][execute_function]: ERROR No such command 'pants'
FvwmCommand Silent pants:
[FVWM][execute_function]: ERROR No such command 'pants'
It would be nice if the second one was quiet.
Patch:
Index: fvwm/functions.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/functions.c,v
retrieving revision 1.26
diff -u -r1.26 functions.c
--- fvwm/functions.c2002/03/18 12:47:11 1.26
+++ fvwm/functions.c2002/03/21 16:07:50
@@ -1414,7 +1414,7 @@
{
if (executeModuleDesperate(
efa-cond_rc, efa-eventp, w, efa-fw, efa-context, runaction,
- efa-module) == -1 *function != 0)
+ efa-module) == -1 *function != 0 !set_silent)
{
fvwm_msg(
ERR, execute_function, No such command '%s', function);
Index: fvwm/fvwm2.1
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/fvwm2.1,v
retrieving revision 1.62
diff -u -r1.62 fvwm2.1
--- fvwm/fvwm2.12002/03/21 12:35:02 1.62
+++ fvwm/fvwm2.12002/03/21 16:13:47
@@ -7900,6 +7900,9 @@
.BR Key , PointerKey and Mouse ,
this disables error messages.
+.B Silent
+also disables the error message for non-existant commands.
+
Examples:
.EX
Silent Move 0 0
--
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: Opinions on new frame layout code?
fvwm-workers@fvwm.org wrote:
On Tue, Mar 19, 2002 at 03:26:24PM +, Tim Phipps wrote:
Nearly, you have to specify a colormap and a border pixel when creating
non-root visual windows, and the gcs used to fill the borders have to be
created from an fvwm visual window. I've attached a patch from todays
snapshot but it may be out of date already.
Hm, I'm not sure I understand this well enough. Can you remake
the patch with the next snapshot please?
Yur tizIndex: fvwm/add_window.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/add_window.c,v
retrieving revision 1.35
diff -u -r1.35 add_window.c
--- fvwm/add_window.c 2002/03/20 14:07:02 1.35
+++ fvwm/add_window.c 2002/03/20 14:07:33
@@ -1173,10 +1173,13 @@
pattributes-background_pixmap = None;
}
- *pvaluemask |= CWBackingStore | CWCursor | CWSaveUnder;
+ *pvaluemask |= CWBackingStore | CWCursor | CWSaveUnder
+ | CWBorderPixel | CWColormap;
pattributes-backing_store = NotUseful;
pattributes-cursor = Scr.FvwmCursors[CRS_DEFAULT];
pattributes-save_under = False;
+ pattributes-border_pixel = 0;
+ pattributes-colormap = Pcmap;
return;
}
@@ -1407,10 +1410,13 @@
{
return;
}
- valuemask = CWEventMask | CWBackingStore | CWSaveUnder | CWWinGravity;
+ valuemask = CWEventMask | CWBackingStore | CWSaveUnder | CWWinGravity
+ | CWBorderPixel | CWColormap;
attributes.event_mask = XEVMASK_BORDERW;
attributes.backing_store = NotUseful;
attributes.save_under = False;
+ attributes.border_pixel = 0;
+ attributes.colormap = Pcmap;
/* Just dump the windows any old place and let frame_setup_window take
* care of the mess */
for (i = 0; i 4; i++)
Index: fvwm/borders.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/borders.c,v
retrieving revision 1.23
diff -u -r1.23 borders.c
--- fvwm/borders.c 2002/03/20 14:07:02 1.23
+++ fvwm/borders.c 2002/03/20 14:07:33
@@ -1426,7 +1426,7 @@
{
XGCValues xgcv;
- tile_gc = fvwmlib_XCreateGC(dpy, FW_W_FRAME(fw), 0, xgcv);
+ tile_gc = fvwmlib_XCreateGC(dpy, Scr.SizeWindow, 0, xgcv);
}
ret_gcs-tile = tile_gc;
/* setup the tile gc*/
Re: Opinions on new frame layout code?
[EMAIL PROTECTED] wrote: Apart from the apparent bugs (windowshade doesn't do anything, the border layout of small windows is screwed, window corners sometimes flash above the parent during opaque resizing), what do you think about the now code (mostly in terms of speed, but feel free to comment on other aspects too)? I didn't think it was worth the hassle of a rewrite to get opaque resizing to look nice but now I've seen it I'm convinced it was. Nice one. The -visual option for fvwm2 now doesn't work, well it works but the borders, buttons and titles are left empty. Are you going to remove the option? Cheers, Tim. -- 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]
CursorStyle hangs fvwm
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: CursorStyle seems to set fvwm2 and the Xserver in an endless loop. It doesn't when reading the config in the first time but executing it from FvwmConsole causes the hang. This started with snap-20020218. The Xserver consumes most of the cpu, fvwm2 gets a bit. Repeat-By: CursorStyle root top_left_corner #ff #0 -- 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: Patch to prevent spurious M_NEW_PAGE being broadcast
[EMAIL PROTECTED] wrote: I think it's the PipeRead but I'm not sure, anyway a sensible fix is to not send an M_NEW_PAGE if the page hasn't changed and the attached patch is very simple. Is there any reason to send M_NEW_PAGE when the page doesn't change? Yes. It's necessary to force a M_NEW_PAGE packet when the desk changes but the viewport does not move. Some of the modules need the message in this case. I can't remember which modules. I had a trawl through the recent module code and found the following uses of M_NEW_PAGE and M_NEW_DESK: FvwmAnimate: just stashes the desk and page numbers, it deals with M_NEW_DESK in the same way so doesn't need the redundant M_NEW_PAGE. The strange thing is that FvwmAnimate doesn't ask for M_NEW_PAGE or M_NEW_DESK in the message mask??? FvwmBacker: stashes the new page and desk and then calls the same function as it does when M_NEW_DESK arrives. This looks like it's OK. FvwmButtons: only processes M_NEW_PAGE in an #ifdef DEBUG_FVWM section to print out the message contents. It's OK FvwmCommand: uses the message to print out the new page. It's OK unless someone has a script built on this that doesn't handle the M_NEW_DESK output. FvwmDebug: just prints out the new page/desk. It's OK. FvwmIconMan: already has code in it to avoid processing redundant M_NEW_PAGE messages so it's OK and that bit of code could be stripped out (grep for Useless NEW_PAGE received\n). FvwmPager: handles both M_NEW_PAGE and M_NEW_DESK with the same function for desk changes so it's OK. FvwmSave: doesn't understand desks so it's OK. FvwmSaveDesk: doesn't parse the desk field of M_NEW_PAGE so it's broken already, it relies on M_NEW_DESK for the current desk. FvwmTaskBar: doesn't ask for and ignores M_NEW_PAGE messages so it's OK. So unless someone has a buggy FvwmCommand based script to do stuff on desk/page changes the patch won't affect anything. Cheers, Tim. -- 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: *FvwmIconMan: TitleColorset doesn't work
[EMAIL PROTECTED] wrote:
An empty FvwmIconMan displays a button with the Title string in it
but it doesn't use the TitleColorset properly, it seems to just
draw a flat button using the colorset background, shadow and hilight
colors. If the colorset has a pixmap it is ignored.
The problem really is that tranparent colrosets don't work in the title
button, here's a patch.
Cheers,
Tim.Index: modules/FvwmIconMan/xmanager.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/modules/FvwmIconMan/xmanager.c,v
retrieving revision 1.11
diff -u -r1.11 xmanager.c
--- modules/FvwmIconMan/xmanager.c 2002/03/13 13:43:00 1.11
+++ modules/FvwmIconMan/xmanager.c 2002/03/15 10:17:47
@@ -1488,22 +1488,27 @@
clear_empty_region (man);
get_title_geometry (man, g);
- if (len 0)
-XFillRectangle (theDisplay, man-theWindow, man-backContext[state],
-g.button_x, g.button_y, g.button_w, g.button_h);
+ if (len 0) {
+if (man-colorsets[state] = 0
+ Colorset[man-colorsets[state]].pixmap == ParentRelative) {
+ XClearArea (theDisplay, man-theWindow, g.button_x, g.button_y,
+ g.button_w, g.button_h, False);
+} else {
+ XFillRectangle (theDisplay, man-theWindow, man-backContext[state],
+ g.button_x, g.button_y, g.button_w, g.button_h);
+}
+ }
if (Pdepth 2) {
get_gcs (man, state, 0, context1, context2);
draw_relief (man, state, g, context1, context2);
}
- else {
- }
ClipRectangle (man, state, g.text_x, g.text_y, g.text_w, g.text_h);
- FwinString-str = man-titlename;
+ FwinString-str = man-titlename;
FwinString-win = man-theWindow;
FwinString-gc = man-hiContext[state];
FwinString-x = g.text_x;
FwinString-y = g.text_base;
- FlocaleDrawString(theDisplay, man-FButtonFont, FwinString, 0);
+ FlocaleDrawString (theDisplay, man-FButtonFont, FwinString, 0);
XSetClipMask (theDisplay, man-hiContext[state], None);
}
PipeRead requires quotes, Exec doesn't
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: I just got locked out of X for several hours because I changed an Exec to a Piperead in StartFunction: + I Exec display -window root ~/.backing.png + I PipeRead display -window root ~.backing.png I did this to get the root background set before starting any fvwm modules. Since I forgot the quotes Piperead just ran display which tried to open a window. It was blocked waiting for fvwm to reparent the window and fvwm was blocked waiting for display to quit: deadlock with no timeout: very annoying Is it possible to change PipeRead to work like Exec? -- 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]
Patch to prevent spurious M_NEW_PAGE being broadcast
Hi All,
I tracked down an endless loop with FvwmIconMan caused by
*FvwmIconMan: *Action Select SendCommand FlipFocus
*FvwmEvent: new_page my_geom_record_all
my_geom_record_all has a PipeRead bash -c ' echo AddToFunc...' in and
I think fvwm has recently started to grab the pointer with PipeRead.
The loop starts when you move the pointer to a button in FvwmIconMan. A
FlipFocus is performed which results in an M_NEW_PAGE - FvwmEvent -
my_geom_record_all - PipeRead - grab - leave/eneter event to
FvwmIconMan - FlipFocus.
I think it's the PipeRead but I'm not sure, anyway a sensible fix is to
not send an M_NEW_PAGE if the page hasn't changed and the attached patch
is very simple. Is there any reason to send M_NEW_PAGE when the page
doesn't change?
Cheers,
Tim.
Index: fvwm/virtual.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/virtual.c,v
retrieving revision 1.26
diff -u -r1.26 virtual.c
--- fvwm/virtual.c 2002/03/13 13:42:59 1.26
+++ fvwm/virtual.c 2002/03/15 13:52:19
@@ -991,11 +991,11 @@
}
Scr.Vx = newx;
Scr.Vy = newy;
- BroadcastPacket(
-M_NEW_PAGE, 5, Scr.Vx, Scr.Vy, Scr.CurrentDesk, Scr.VxMax, Scr.VyMax);
if (deltax || deltay)
{
+BroadcastPacket(
+ M_NEW_PAGE, 5, Scr.Vx, Scr.Vy, Scr.CurrentDesk, Scr.VxMax, Scr.VyMax);
/*
* RBW - 11/13/1998 - new: chase the chain bidirectionally, all
at once!
Re: PipeRead requires quotes, Exec doesn't
[EMAIL PROTECTED] wrote: That's because someone thought it would be a good idea to add the quiet option after the command string. I agree that this is most unfortunate. Should we break compatibility here? I vote yes since I've never used the quiet option, it only puts messages in the log file and you can easily get the same effect with /dev/null. Cheers, Tim. -- 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: *FvwmIconMan: TitleColorset doesn't work
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: The problem really is that tranparent colrosets don't work in the title button, here's a patch. I'll apply the patch. Is this 2.5.0 only or should it be changed in 2.4.7 too? I guess so, I can't check cvs easily but if 2.4.7 has transparent colorset support in FvwmIconMan it probably has the same bug and fix. Cheers, Tim. -- 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]
Missing , in Parse.c
Hi All, NorthEast was going South due to some missing commas, here's a patch. Cheers, Tim. Index: libs/Parse.c === RCS file: /u/phippst/share/cvsroot/fvwm/libs/Parse.c,v retrieving revision 1.7 diff -u -r1.7 Parse.c --- libs/Parse.c2002/03/11 09:52:13 1.7 +++ libs/Parse.c2002/03/13 11:30:20 @@ -783,9 +783,9 @@ E, East, Right, Right, S, South, Bottom, Down, W, West, Left,Left, - NE, NorthEast, TopRight UpRight, + NE, NorthEast, TopRight,UpRight, SE, SouthEast, BottomRight, DownRight, - SW, SouthWest, BottomLeft DownLeft, + SW, SouthWest, BottomLeft, DownLeft, NW, NorthWest, TopLeft, UpLeft, NULL };
fvwmdebug.h refrenced by fvwm.h
How come no-one using CVS has noticed this? Cheers, Tim. Index: fvwm/fvwm.h === RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/fvwm.h,v retrieving revision 1.24 diff -u -r1.24 fvwm.h --- fvwm/fvwm.h 2002/03/11 09:52:11 1.24 +++ fvwm/fvwm.h 2002/03/13 11:38:10 @@ -720,10 +720,6 @@ void *pscratch; } FvwmWindow; -/* include this down here because FvwmWindows must be defined when including - * this header file. */ -#include fvwmdebug.h - void SetMWM_INFO(Window window); #endif /* _FVWM_ */
Re: *FvwmIconMan: TitleColorset doesn't work
[EMAIL PROTECTED] wrote: Description: An empty FvwmIconMan displays a button with the Title string in it but it doesn't use the TitleColorset properly, it seems to just draw a flat button using the colorset background, shadow and hilight colors. If the colorset has a pixmap it is ignored. Tim, can you please try to fix that and have a look at the looping too? I'm too busy with the frame layout changes for the next days or even weeks. OK, I'll have a go. Cheers, Tim. -- 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: ideas about future frame layout?
[EMAIL PROTECTED] wrote: On Mon, Mar 11, 2002 at 04:29:50PM +, Tim Phipps wrote: If we remove the decor window the frame window will have to change to the fvwm visual. Why? I don't intend to draw into the frame window, only to reparent the individual sub windows of the decor_w to the frame. Sorry, I misunderstood. I thought your comment on pixmap borders meant that the pixmap would be drawn in the frame window and the sub windows would only be used for the 3d reliefs (so only 1 or 2 pixels wide/high). Cheers, Tim. -- 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]
FvwmIconMan looping
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: I have FvwmIconMan set up to change the focus by just moving the mouse to the FvwmIconMan button. This used to work OK but now I get and endless loop of Focus events. Repeat-By: *FvwmIconMan: *Action Select SendCommand FlipFocus FlipFocus causes a new_page message even if it is not necessary and I think fvwm also grabs the pointer even if the focus is not actually changing. The grab results in FvwmIconMan thinking that the pointer has moved and it sends the FlipFocus command again... Fix: FvwmIconMan could be fixed to not do a Select command if the pointer has not actaully moved, or fvwm could not do som much page moving/grabbing if not necessary. -- 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]
Learning pointer warping scheme
Morning all, A feature request: 1) Could I have $[pointer.x]/$[pointer.y] variables to return the pointer position relative to the window frame? I would use this to create a WarpToWindow function so the number should be pixels from the top-left of the fvwm frame. It might be useful for WindowId Root $[pointer.x] to return the absolute position (not sure about xinerama). What I'm trying to do is to implement a learning cursor warping scheme. What I want is for fvwm to remember where the cursor was in each window when it was warped away so that if the cursor is warped back to a window it gets warped to the old location. At the moment I have a semi intelligent function to warp the cursor to sensible places but the function is going to get very large: # functions to warp cursor to somewhere useful depending on window type NewFunc(my_conditional_cursorwarp) + ICurrent (Transient) WarpToWindow 50 50 + I Cond (NoMatch) Current (XTerm) WarpToWindow -10p -70p + I Cond (NoMatch) Current (Fvwm*) WarpToWindow 50 50 + I Cond (NoMatch) Current WarpToWindow 35p 40p What I'd like is something like this NewFunc(my_NEW_conditional_cursorwarp) + I PointerWindow my_record_warp + I AddToFunc my_warp_$w I my_conditional_cursorwarp + I AddToFunc my_warp_$w I Break + I my_warp_$w NewFunc(my_record_warp) + I DestroyFunc my_warp_$w + I AddToFunc my_warp_$w I WarpToWindow $[pointer.x]p $[pointer.y]p + I AddToFunc my_warp_$w I Break I would end up with a lot of functions called my_warp_xxx but I can destroy each one when the window closes. If a window is warped-to that hasn't been warped-from the function for that window would look like: AddToFunc my_warp_1234 I my_conditional_cursorwarp + I Break and the default warping would occur. If the window had been warped-from it would look like: AddToFunc my_warp_1234 I WarpToWindow 56p 78p + I Break + I my_conditional_warp + I Break Cheers, Tim. -- 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: Learning pointer warping scheme
Done. Try pointer.x, pointer.y (position in root window), pointer.wx, pointer.wy (position in frame) and pointer.cx, pointer.cy position in client window. See man page for details. Thanks, it's working nicely now. very useful when you middle-click a link in mozilla to get a new window, when you close the new window the pointer gets warped back to the link you pressed. The functions truned out like this: # functions to warp pointer to somewhere useful depending on window type AddToFunc my_default_pointerwarp + IThis (Transient) WarpToWindow 50 50 # transients = centre + I Cond (NoMatch) This (XTerm) WarpToWindow -10p -70p # rxvt = scrollbar + I Cond (NoMatch) This (Fvwm*) WarpToWindow 50 50 # modules = centre + I Cond (NoMatch) WarpToWindow 35p 40p # default to menu bar # this creates a function for each window to remember where to warp the pointer AddToFunc my_record_warp + I DestroyFunc my_warp_$w + I This AddToFunc my_warp_$w I WarpToWindow $[pointer.wx]p $[pointer.wy]p + I AddToFunc my_warp_$w I Break # prevents falling through to default warping # AI: This function learns the old location of the pointer and records it for later use AddToFunc my_pointerwarp + I PointerWindow my_record_warp + I AddToFunc my_warp_$w I This (CurrentDesk !Iconic) my_default_pointerwarp + I my_warp_$w + I my_record_warp # removes the default from the end of the function The This in my_record_warp was necessary to get the $[pointer.wx] to expand when my_record_warp is executed rather than getting passed to my_warp_$w and being expanded when my_warp_$w is executed. Is this a feature of variable expansion? Cheers, Tim. -- 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: FvwmButtons - weirdness with panels that have borders
[EMAIL PROTECTED] wrote: Mail manually forwarded from Dominik: [EMAIL PROTECTED] wrote: Description: I have a panel that hangs on a window with a border and titlebar. When the panel is up it looks fine but shading it leaves something behind. Lowering the window leaves bits on top of other windows. Repeat-By: *Buttons: (Title (Side) Icon mini/mail.xpm Panel (Respawn Steps 0 \ Position Module Left 25 0) Mail Newsgroups Exec mozilla -mail) More info: Setting the step count higher than 1 gets rid of most of the problems but the titlebar of the panel seem to be above other windows even when the panel is lowered beneath others. Can you make a screenshot? I just tried and the problem has gone away. The only thing I've done is restart the X server so it looks like that is the source of the weirdness (it was very wierd, I've never seen just parts of a window overlap others) Cheers, Tim. -- 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 domivogt: * FvwmBUttons: Added a new way to specify the button that title or icon is to
On 09 Feb 2002 08:00:53 -0600, FVWM CVS wrote: SendToModule FvwmButtons Title row column ... This is causing me problems when I try to set a button title to a number. I have three buttons in a container to display the day, date and time. This new syntax doesn't work with containers so I have to use the old style. Unfortunaltely the date and time are interpreted as numbers and so the new syntax is used. Could we have +row+column for the new method? Cheers, Tim. -- 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]
FvwmButtons patch for changing icons
Hi All,
Another patch, this one adds the ability to do
SendToModule FvwmButtons Icon 7 AIcons/appl/mail/xmail_new.xpm
No documentation yet since I'm not sure if this syntax is any good.
Cheers,
Tim.
Index: modules/FvwmButtons/FvwmButtons.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/modules/FvwmButtons/FvwmButtons.c,v
retrieving revision 1.19
diff -u -r1.19 FvwmButtons.c
--- modules/FvwmButtons/FvwmButtons.c 2002/02/04 09:37:14 1.19
+++ modules/FvwmButtons/FvwmButtons.c 2002/02/07 11:34:35
@@ -3084,16 +3084,59 @@
}
/* SendToModule options */
-static void parse_title(char *line)
+static void change_title(button_info *b, char *line)
{
+ if (!(b-flags b_Title)) {
+fprintf(stderr, %s: cannot create a title, only change one\n, MyName);
+return;
+ }
+ free(b-title);
+ CopyString(b-title, line);
+ RedrawButton(b, 2);
+ return;
+}
+
+static void change_icon(button_info *b, char *line)
+{
+ Picture *new_icon;
+ if (!(b-flags b_Icon)) {
+fprintf(stderr, %s: cannot create an icon, only change one\n, MyName);
+return;
+ }
+ if (LoadIconFile(line, new_icon) == 0) {
+fprintf(stderr, %s: cannot load icon %s\n, MyName, line);
+return;
+ }
+ free(b-icon_file);
+ CopyString(b-icon_file, line);
+ DestroyPicture(Dpy, b-icon);
+ XDestroyWindow(Dpy, b-IconWin);
+ b-IconWin = None;
+ b-icon = new_icon;
+ CreateIconWindow(b);
+ ConfigureIconWindow(b);
+ XMapWindow(Dpy, b-IconWin);
+ RedrawButton(b, 2);
+ return;
+}
+
+static char *message_options[] = {Title, Icon, NULL};
+
+void parse_message_line(char *line)
+{
+ char *rest;
+ int type;
int n, count, i;
button_info *b, *ub = UberButton;
- /* find out which button */
- if (GetIntegerArguments(line, line, n, 1) != 1)
+ type = GetTokenIndex(line, message_options, -1, rest);
+ if (type == -1) {
+fprintf(stderr, %s: Message not understood: %s\n, MyName, line);
return;
- if (n 0)
- {
+ }
+
+ /* find out which button */
+ if (GetIntegerArguments(rest, rest, n, 1) != 1 || n 0) {
fprintf(stderr, %s: button number must not be negative\n, MyName);
return;
}
@@ -3103,31 +3146,17 @@
if (++count == n)
break;
}
- if (count != n) {
+ if (count != n || b == NULL) {
fprintf(stderr, %s: button number %d not found\n, MyName, n);
return;
- }
- if (b) {
-if (!b-flags b_Title) {
- fprintf(stderr, %s: cannot create a title, only change one\n, MyName);
- return;
-}
-free(b-title);
-CopyString(b-title, line);
-RedrawButton(b, 2);
}
- return;
-}
-
-static char *message_options[] = {Title, NULL};
-
-void parse_message_line(char *line)
-{
- char *rest;
-
- switch(GetTokenIndex(line, message_options, -1, rest)) {
+
+ switch(type) {
case 0:
-parse_title(rest);
+change_title(b, rest);
+break;
+ case 1:
+change_icon(b, rest);
break;
}
}
Re: FvwmButtons - weirdness with panels that have borders
[EMAIL PROTECTED] wrote: Description: I have a panel that hangs on a window with a border and titlebar. When the panel is up it looks fine but shading it leaves something behind. Lowering the window leaves bits on top of other windows. Repeat-By: *Buttons: (Title (Side) Icon mini/mail.xpm Panel (Respawn Steps 0 \ Position Module Left 25 0) Mail Newsgroups Exec mozilla -mail) More info: Setting the step count higher than 1 gets rid of most of the problems but the titlebar of the panel seem to be above other windows even when the panel is lowered beneath others. Does FvwmButtons mess with the fvwm_windows? Could any of the sub-windows be reparented back to the root? Cheers, Tim. -- 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]
FvwmButtons - weirdness with panels that have borders
Configuration Information [Automatically generated, do not change]: uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10 Compiler: gcc Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int prefix: /u/phippst/sunos FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: I have a panel that hangs on a window with a border and titlebar. When the panel is up it looks fine but shading it leaves something behind. Lowering the window leaves bits on top of other windows. Repeat-By: *Buttons: (Title (Side) Icon mini/mail.xpm Panel (Respawn Steps 0 \ Position Module Left 25 0) Mail Newsgroups Exec mozilla -mail) It's not mozilla, xterms have the same problem. It's like some of the fvwm windows around the client are getting seperated from the parent. -- 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]
Tear off menus
Hi Dominik, I'm just wondering if tear of menus would be better off in a module? Making fvwm create its own top level windows makes it more vulnerable to being killed (try xkill when you don't have anything important on screen). I seem to remember scwm having the same problem, I'm not sure what they did. Is it possible to fork and reopen the display? Cheers, Tim. -- 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: Patch to enable dynamic FvwmButton button titles
[EMAIL PROTECTED] wrote: On 2 Feb, Dominik Vogt wrote: I lika that patch :-) Consider it applied. The next logical thing to do would be to change the pixmap of a button. I think a man page change is the next thing to do ;-) Does this patch work if you have multiple instances of FvwmButtons running? Yes, just use the alias name instead of FvwmButtons to send the change to only one of them. Cheers, Tim. -- 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]
Patch to enable dynamic FvwmButton button titles
Hi All,
Here's a patch to make FvwmButtons understand this:
FvwmCommand SendToModule FvwmButtons Title 5 You have Mail!
Buttons are numbered from 0 and are in the order in your config file
(containers don't count). It only works with buttons that have a title
in the config file (could be ) and I haven't tested it with anything
other than a simple button (just a title, no icon or swallows).
I've stuffed the new code into FvwmButtons.c which is probably the wrong
place.
Cheers,
Tim.
PS I think I can get rid of all my swallowed (non-fvwm) apps except
xload with this.
Index: modules/FvwmButtons/FvwmButtons.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/modules/FvwmButtons/FvwmButtons.c,v
retrieving revision 1.18
diff -u -r1.18 FvwmButtons.c
--- modules/FvwmButtons/FvwmButtons.c 2002/02/01 14:28:11 1.18
+++ modules/FvwmButtons/FvwmButtons.c 2002/02/01 16:01:53
@@ -110,6 +110,7 @@
void process_message(unsigned long type,unsigned long *body);
extern void send_clientmessage (Display *disp, Window w, Atom a,
Time timestamp);
+void parse_message_line(char *line);
void CheckForHangon(unsigned long*);
static Window GetRealGeometry(
Display*,Window,int*,int*,unsigned int*,unsigned int*, unsigned int*,
@@ -936,7 +937,7 @@
SetMessageMask(fd, M_NEW_DESK | M_END_WINDOWLIST | M_MAP | M_WINDOW_NAME
| M_RES_CLASS | M_CONFIG_INFO | M_END_CONFIG_INFO | M_RES_NAME
-| M_SENDCONFIG | M_ADD_WINDOW | M_CONFIGURE_WINDOW);
+| M_SENDCONFIG | M_ADD_WINDOW | M_CONFIGURE_WINDOW | M_STRING);
SetMessageMask(fd, MX_PROPERTY_CHANGE);
/* request a window list, since this triggers a response which
@@ -2618,6 +2619,9 @@
swallowed = body[1];
}
break;
+ case M_STRING:
+parse_message_line((char *)body[3]);
+break;
default:
break;
}
@@ -3076,5 +3080,54 @@
}
break;
}
+ }
+}
+
+/* SendToModule options */
+static void parse_title(char *line)
+{
+ int n, count, i;
+ button_info *b, *ub = UberButton;
+
+ /* find out which button */
+ if (GetIntegerArguments(line, line, n, 1) != 1)
+return;
+ if (n 0)
+ {
+fprintf(stderr, %s: button number must not be negative\n, MyName);
+return;
+ }
+ i = count = -1;
+ /* find the button */
+ while (NextButton(ub, b, i, 0)) {
+if (++count == n)
+ break;
+ }
+ if (count != n) {
+fprintf(stderr, %s: button number %d not found\n, MyName, n);
+return;
+ }
+ if (b) {
+if (!b-flags b_Title) {
+ fprintf(stderr, %s: cannot create a title, only change one\n, MyName);
+ return;
+}
+free(b-title);
+CopyString(b-title, line);
+RedrawButton(b, 2);
+ }
+ return;
+}
+
+static char *message_options[] = {Title, NULL};
+
+void parse_message_line(char *line)
+{
+ char *rest;
+
+ switch(GetTokenIndex(line, message_options, -1, rest)) {
+ case 0:
+parse_title(rest);
+break;
}
}
0 delay for Schedule locks up shedule queue
Configuration Information [Automatically generated, do not change]: uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10 Compiler: gcc Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int prefix: /u/phippst/sunos FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: Schedule 0 FvwmBanner prevents any other Schedule command working Repeat-By: Schedule 1 FvwmBanner Schedule 0 FvwmBanner Schedule 1 FvwmBanner -- 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: * Use gnu libiconv in priority against the system iconv
fvwm-workers@fvwm.org wrote: Log message: * Use gnu libiconv in priority against the system iconv Thanks, all my UTF error messages have gone. Cheers, Tim. -- 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: changes to fvwm that have not been included in 2.4.5 for unknown reasons
[EMAIL PROTECTED] wrote: Alexander Kotelnikov [EMAIL PROTECTED] writes: # -*-perl-*- Dan That line is in the file in order to make emacs go into perl mode. The disadvantage of the #! line is that it contains a hard-coded path. On my HP-UX machine, Perl is not in /usr/bin. In fvwm24_convert, the lines right after the first line invoke Perl without a hard-coded path. Since fvwm24_convert is generated from fvwm24_convert.in nobody should be editing fvwm24_convert. fvwm-menu-* all have the correct path to perl inserted by configure. Is it possible to have the Emacs mode magic in the .in file and still have #!path-to-perl appear in the first line of the final script? Cheers, Tim. -- 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 domivogt: * New commands Any and PointerWindow.
fvwm-workers@fvwm.org wrote: Log message: * New commands Any and PointerWindow. So what's the difference between Any and Next? Cheers, Tim. -- 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: [Fwd: Re: 2.5.0 problems]
[EMAIL PROTECTED] wrote: On Mon, Jan 28, 2002 at 12:27:35PM +, Tim Phipps wrote: Part of this problem is that UTF8 isn't a valid charset. The GNU libiconv documentation says UTF-8 is the correct name. Does anyone know what the correct name for glibc is? The glibc support UTF8 and UTF-8 (= 2.1.x). At least iconv --list gives the two names. I will be surprised that the gnu libiconv does not understand the two names too. http://www.gnu.org/software/libiconv only mentions UTF-8. Since glibc does both could you patch ewmh_names.c to use UTF-8? Cheers, Tim. -- 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]
Cannot make fvwm link with libiconv
Configuration Information [Automatically generated, do not change]: uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10 Compiler: gcc Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int prefix: /u/phippst/sunos FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: On Solaris 2.5.1 iconv support is pants. I downloaded libiconv, compiled and installed. Now I can't get fvwm to compile. Repeat-By: Any of ./configure ./configure --with-iconv-library=/u/phippst/sunos/lib ./configure --with-iconv-library=/u/phippst/sunos/lib/libiconv.so All result in: ewmh_names.c:56: #error libiconv not in use but included iconv.h is from libiconv I think this is because I have an iconv.h on my include path, put there by libiconv but ./configure is detecting the Solaris iconv and not looking at --with-iconv-library Fix: Make ./configure take note of the --with-iconv-library and try to use -liconv in it's test compilation before it tries the system iconv. I think this would be best since not many people would install a libiconv if they didn't need it. Maybe trying libiconv first would be best, it's not likely to be worse than the system iconv. -- 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: Remaining issues in Transparency
I sent this direct to Olivier, here it is to the mailing list. [EMAIL PROTECTED] wrote: I am afraid to do not understand. what I would like to implement is automatic configuration. An alternative to atom is a new (undocumented) _command_, say, ParentRelative. If a module has a transparent background then it send to fvwm2 ParentRelative On to force the ParentalRelativity and WindowShadeShrinks styles. If the colorset change and the background become non transparent the modules then send ParentRelative Off. Why not wait until the WindowStyle command is implemented and then have the module send WindowId xxx WindowStyle ParentRelative On ? A solution here, is again a new command similar to Colorset. When a FvwmButton change the background of a swallowed window with X-id ID (and if the swallowed app is an Fvwm module, see the next paragraph) it can send the command BackgroundChange. Then fvwm2 will send the string ROOT_BG_CHANGE_STRING ID to modules and the module with X-id ID may be able to update its background if it is transparent (fvwm2 already send ROOT_BG_CHANGE_STRING when fvwm2 detects that the root background change). BTW, it will be maybe better to send a MX_ROOT_BG_CHANGE message as we have now some places? Also it will be useful for FvwmButtons to know if the swallowed window is a FVWM Module or a normal X application. The only solution I see is to claim in the FvwmButtons man page that if the swallow command begin with Fvwm or Module then FvwmButtons will consider that it will swallow a Fvwm module. So if a complex function is used to launch a swallowed app the name of this complex function have some importance. Is this acceptable? The only thing a transparent window needs to do when the root window changes is a refresh. Why not have FvwmButtons do a refresh on each swallowed window if the button that holds the window is transparent? // end of resend // On playing a bit with this I think the correct way to handle transparent colorsets and the root window changinf is for FvwmTheme to look for changes to the root window and for it to resend the Colorset command to fvwm. The following line in FvwmConsole fixes up all the transparent modules with a background change: sendtomodule FvwmTheme Colorset 0 transparent Obviously this only works with colorset 0 being transparent and FvwmTheme should do the necessary for each colorset with a transparent background. I don't think there is any need to have any code in the modules to handle root changes, they all already have code to cope with colorset changes so let's use that mechanism. Cheers, Tim. -- 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]
PlacementOverlapPenalities not working
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int
prefix: /u/phippst/sunos
FVWM Version: 2.5.0
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0
FVWM_DATADIR: /u/phippst/sunos/share/fvwm
FVWM_USERDIR: /u/phippst/.fvwm
Description:
The PlacementOverlapPenalities style doesn't work for me,
whatever I try I get:
[FVWM][CMD_Style]: ERROR Bad style option: PlacementOverlapPenalities
The man page states that up to six positive or null decimal
arguments may be used but the code has this (style.c):
float f[6] = {-1, -1, -1, -1, -1, -1};
Bool bad = False;
found = True;
num = 0;
if (rest != NULL)
{
num = sscanf(rest, %f %f %f %f %f %f,
f[0], f[1], f[2], f[3], f[4], f[5]);
for(i=0; i num; i++)
{
if (f[i] 0)
bad = True;
}
}
if (bad)
{
fvwm_msg(ERR, CMD_Style,
Bad argument to PlacementOverlapPenalties: %s, rest);
break;
}
Repeat-By:
Style * PlacementOverlapPenalities 1 10 0 1 0.5 10
--
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: PlacementOverlapPenalities not working
fvwm-workers@fvwm.org wrote: Works fine for me, at least if I correct the typo in the style name: Repeat-By: Style * PlacementOverlapPenalities 1 10 0 1 0.5 10 ^^^ Works for me too, sorry about that. Cheers, Tim. -- 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: PlacementOverlapPenalities not working
fvwm-workers@fvwm.org wrote: [FVWM][CMD_Style]: ERROR Bad style option: PlacementOverlapPenalities Hm, that doesn't explain the error message you get. BTW, is there a specific reason why negative penalties are not allowed? It does, the error has gone away and it now does what I want. I'm not sure what you'd want negative penalties to do, you can have 0 to ignore certain types altogether and you can have large numbers to avoid certain types altogether. Cheers, Tim. -- 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]
FvwmIconBox quits with badly written clients
Configuration Information [Automatically generated, do not change]: uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10 Compiler: gcc Compilation CFLAGS: -g -O2 -Wall prefix: /u/phippst/sunos FVWM Version: 2.5.0 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: Some clients provide invalid (by ICCCM's definition) icon pixmaps. Fvwm handles these but FvwmIconBox quits. Repeat-By: Run X with the default visual set to 8 bits but with a 24 bit visual available. Run mozilla. Run FvwmIconBox. fvwm reports: [FVWM][GetIconBitmap]: ERROR Bad client icon pixmap depth 24 [FVWM][GetIconWindow]: ERROR Help! Bad Icon Window! FvwmIconBox reports: FvwmIconBox: Cause of next X Error. Error: 8 (BadMatch) Major opcode of failed request: 62 (CopyArea) Minor opcode of failed request: 0 Resource id of failed request: 0x3800024 Leaving a core dump now -- 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: WindowShade and more
fvwm-workers@fvwm.org wrote: In the end all I have to do is to reactivate the code that we had before I introduced the decor_w. Don't do that, there were lots of minor bugs with the drawing of FvwmBorders and noinset and hiddenhandles. I seem to remeber this all started when someone (possibly me) removed the 1 pixel border (X-window border not FVWM border) around the fvwm frame window for FVWMBorder style windows. That was done to get rid of some of the wandering window features of the 2.0 series of FvwmWinlist etc. Removing the x-window border caused FvwmBorder windows to be drawn wrong and the easiest way to fix the mess was to do all the drawing in one window. Maybe it's time to ditch FvwmBorder style (I don't think it was ever designed, it just turned out like it did and some people liked it). This won't give you perfect unshade looks because the side handle windows height will have to be the height required for unshaded looks and so some of the handle marks won't show up. No, this should work fine. If I set a tiled background pixmap, the server always knows what to draw. We don't even need to select Expose events on the border. Agreed, not getting Expose events would be good. If the corner handles are set to normal size it will look a bit screwy in the first steps of unshading. The handle marks would have to be drawn into the corners. The horizontal marks must be disabled when the window is shaded. Oh I see. I thought that the sides would have a top and bottom shadow around them. If the mark is drawn competely in the corners then it all works fine. The only problem I can think of is that the corners will have to be made slightly bigger than they are. It will look the same but the point at which the cursor changes from side to corner will be changed (no-one will notice ;-) Cheers, Tim. -- 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: conditional styles
fvwm-workers@fvwm.org wrote: I like that idea. The only thing I can't imagine is: how can we begin to implement such a monster of a feature? Yes, it would simplify a *lot* of code. But to me it looks like a much greater challenge than the infamous GSFR (Great Style Flag Rewrite) several years ago. Well, the GSFR was a great success! maybe a trial is on order: * Write a WindowStyle command that just understands Sticky/Slippery, copy/paste from the Style command. * Write a NewStyle command that manipulates the StyleFunction function, don't worry about DestroyStyle and optimizing the function yet. * Write a wrapper for Style that strips out any Sticky/Slippery options and passes them to a NewStyle command, Pass the other options to the old style command (this may be quite hard and will be thrown away later so maybe just a really simple version would be OK e.g. only pass to NewStyle if the command is just Style pattern Sticky) * Add the dynamic update of Sticky/Slipppery to the NewStyle command. This should result in the Style commands with Sticky/Slippery bahaving exactly as the old way. If nothing unexpected turns up then we can proceed as follows: * Add all the other style flags to the WindowStyle command. * Add multiple comma-seperated options to the WindowStyle command. * Remove the old Style command. * Remove the Style wrapper and rename NewStyle to Style. * Work out a method for DestroyStyle. * Use the above method to optimize the StyleFunction. * Test it to bits. I'm sure I've missed out something important, hopefully doing a simple trial will make it obvious. Cheers, Tim. -- 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: conditional styles
[EMAIL PROTECTED] wrote:
This is not the only problem. Here are related ones.
Currently Style list is always optimized. It is not obvious how to do this
with this new StyleFunction. The function functionality just does not
allow to do everything we may want to do with StyleFunction.
I just replied to Dominik with an idea for implementing this. Optimizing
the StyleFucntion would be part of the plan and would require some
way of deleting lines from a function. Is this optimization sufficient?
For each style flag given to the Style command {
For each line of StyleFunction {
Delete any line with a matching pattern that sets/clears that flag
}
Add the pattern and style flags to the end of the StyleFunction
}
This would result in the StyleFunction being quite simple e.g.
Style Fvwm* Sticky, Layer 4
gives a StyleFunctions that looks like
+ I WindowId $0 (Fvwm*) WindowStyle Sticky
+ I WindowId $0 (Fvwm*) WindowStyle Layer 4
Maybe it could use a simplified version of WindowStyle that only works
on one style flag and doesn't actually do any visual updates until the end
( like the style function does ).
The matching patterns to delete is not just a straight string match but
a match
of any subset e.g. F* would delete any Fvwm* patterns. I don't know how
hard that would be.
Examples. I want a solution for these two problems.
1) Being able to switch normal icons on and off. Currently the only
solution is to issue Style * NoIcon to switch it off and hundreds of
Style pattern Icon image to switch them on again. Of course, the
solution to this is to add aditional Style flag HasIcon/NoIcon, so Icon is
stored for a window even it has NoIcon. But you may get the point. If
currently switching icons on and off two times is the same as doing this
10 times (because there is merging), with StyleFunction thousand of
new lines would be added, unless there is a way to optimize a function.
In this case it will not be a function in a normal sence.
You're right, it would not be a normal function. There may be no point
in exposing
it to users so maybe a hidden one would be better. But it would use the same
function creation routines we already have plus a special line-deletion
routine.
Line deletion from functions may be useful anyway so maybe
DeleteFromFunction StyleFunction I WindowId \$0 (Fvwm*) Sticky
DeleteFromFunction StyleFunction I WIndowId \$0 (Fvwm*) Slippery
would be the way to go.
2) It would be nice to have a way to do and undo style changes. This may
be useful for Style GUIs with ability to try/cancel style options. Or if
someone wants to enter to some temporary mode, i.e. to remember the way a
window (or windows) start now, apply some changes (say, iconify all new
windows) and then return to the previous state (with only some windows
started iconified). I see two possible solutions to this. First:
StartStyleGroup, EndStyleGroup, DeleteStyleGroup commands and disable
merging with styles inside the group. Second: DumpStyle / RestoreStyle.
In any case, to implement this, more operations over StyleFunction needed.
A really nice way to do this would be for the GUI to embed an XNest
window and have it
run a captive fvwm inside with a couple of example windows (term,
mozilla, transients etc.)
Dumping any function contents would be useful for debug anyway and
dumping StyleFunction
would give the equivalent of DumpStyle, Restore Style would be a read of
the file.
Cheers,
Tim.
Off for Christmas, See you In Jan.
--
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: conditional styles
Is it time for a rethink of the style system? It seems that the style command and a few builtin commands manipulate a windows appearance and behaviour but they don't do a complete job. We could generalize them and provide a means to do more selective control with some additional commands. Commands like Stick alter the windows sticky behaviour. Style pattern Sticky does the same thing for a set of windows and also maintains a list of patterns to apply to newly created windows. A lot of style types do not have matching builtin commands. How about a new command: WindowStyle? It would apply to the current window or could be used as part of a selective command e.g. WindowStyle Sticky All (*Buttons*) WindowStyle Layer 5 WindowId ??? WindowStyle Iconic The simple built-ins like Stick could be aliases e.g. Stick On = WindowStyle Sticky Stick Off = WindowStyle Slippery The Style command could be aliased also e.g. Style pattern ResizeOpaque = All (pattern) WindowStyle ResizeOpaque Style pattern style-args = All (pattern) WindowStyle style-args plus the pattern to apply to new windows could be written as a function AddToFunc StyleFunction I WindowId $0 (pattern) WindowStyle ResizeOpaque The StyleFunction function would be called with the newly-created window's id as the first parameter. Additional style commands would just add to StyleFunction in a similar way to the way the style list build up. I think we may be able to remove the style list altogether with this. The only problem being the DestroyStyle command which would have to selectively remove parts of StyleFunction! DestroyStyle * would be the same a DestroyFunc StyleFunction. Doing this would require moving most of the style parsing code from the Style command to the new WindowStyle command and rewriting the simple commands like Stick. Benefits: * possible to control every style on a per window basis * extending the conditions for Next/All also extends the ability to set styles e.g. `All (class=*Fvwm*) WindowStyle Sticky' is better than `style *Fvwm* Sticky' * possible to obsolete commands like Stick in the future * Larrys suggestion for conditions would work with this e.g. `Style (Condition=Terminal) Colorset 2' is aliased to `All (Condition=Terminal) WindowStyle Colorset 2' Cheers, Tim. -- 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]
Fvwm doesn't compile without iconv
Configuration Information [Automatically generated, do not change]: uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10 Compiler: gcc Compilation CFLAGS: -g -O2 -Wall prefix: /u/phippst/sunos FVWM Version: 2.5.0 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: If iconv isn't available fvwm/ewmh.c doesn't compile Fix: I'll reply with a patch. -- 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 doesn't compile without iconv
Here's a path that fixes the problem.
Cheers,
Tim.
Index: fvwm/ewmh.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/ewmh.c,v
retrieving revision 1.3
diff -u -r1.3 ewmh.c
--- fvwm/ewmh.c 2001/11/26 15:37:37 1.3
+++ fvwm/ewmh.c 2001/12/05 11:44:27
@@ -151,8 +151,8 @@
{
ENTRY(_NET_WM_ICON, XA_CARDINAL, ewmh_WMIcon),
ENTRY(_NET_WM_ICON_GEOMETRY, XA_CARDINAL, ewmh_WMIconGeometry),
- ENTRY(_NET_WM_ICON_NAME, None,EWMH_WMIconName),
- ENTRY(_NET_WM_NAME, None,EWMH_WMName),
+ ENTRY(_NET_WM_ICON_NAME, None,EWMH_WMIconName_func),
+ ENTRY(_NET_WM_NAME, None,EWMH_WMName_func),
ENTRY(_NET_WM_STRUT, XA_CARDINAL, ewmh_WMStrut),
{NULL,0,0,0}
};
Index: fvwm/ewmh.h
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/ewmh.h,v
retrieving revision 1.3
diff -u -r1.3 ewmh.h
--- fvwm/ewmh.h 2001/11/26 15:37:37 1.3
+++ fvwm/ewmh.h 2001/12/05 11:42:23
@@ -69,11 +69,15 @@
#ifdef HAVE_ICONV
void EWMH_SetVisibleName(FvwmWindow *fwin, Bool is_icon_name);
int EWMH_WMName(FvwmWindow *fwin, XEvent *ev, window_style *style);
+#define EWMH_WMName_func EWMH_WMName
int EWMH_WMIconName(FvwmWindow *fwin, XEvent *ev, window_style *style);
+#define EWMH_WMIconName_func EWMH_WMIconName
#else
#define EWMH_SetVisibleName(x,y)
#define EWMH_WMName(x,y,z) 0
+#define EWMH_WMName_func 0
#define EWMH_WMIconName(x,y,z) 0
+#define EWMH_WMIconName_func 0
#endif /* HAVE_ICONV */
#else /* HAVE_EWMH */
Snapshots not being built
Hi All, The latest snapshot is dated Nov 7th. Cheers, Tim. -- 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: coredump from FvwmCommand Current RecaptureWindow
fvwm-workers@fvwm.org wrote: Can you reproduce this and send the relevant parts of your config? fvwm2rc: = AddToFunc my_destroy_event + I Current WarpToWindow *FvwmEvent: destroy_window my_destroy_event FvwmEvent FvwmCommandS = In an xterm run FvwmCommand Current RecaptureWindow I'm not sure what the best fix is, ideally RecaptureWindow would not send a destroy event but it may not be possible to change that without breaking a lot of modules. Maybe Current should not operate during RecaptureWindow. If the function is just + I WarpTowindow you get the selection cursor and you can't crash fvwm. Cheers, Tim. (gdb) where #0 0x3b778 in remove_window_from_stack_ring (t=0x9da90) at stack.c:171 #1 0x3c040 in RaiseOrLowerWindow (t=0x9da90, do_lower=0, allow_recursion=1, is_new_window=0) at stack.c:588 #2 0x3c300 in RaiseWindow (t=0x9da90) at stack.c:737 #3 0x326ac in warp_to_fvwm_window (eventp=0x8c45c, t=0x9da90, warp_x=321, x_unit=0, warp_y=484, y_unit=0) at focus.c:527 #4 0x3288c in CMD_WarpToWindow (eventp=0x8c45c, w=0, tmp_win=0x9da90, context=1, action=0x9a0ac , Module=0xefffd7ac) at focus.c:572 #5 0x4e50c in execute_function (efa=0xefffd798) at functions.c:1103 #6 0x4e6a4 in old_execute_function (action=0xa2910 WarpToWindow, tmp_win=0x9da90, eventp=0x8c45c, context=1, Module=-1, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #7 0x45ee4 in CMD_Current (eventp=0x8c45c, w=54, tmp_win=0x0, context=8, action=0xa2910 WarpToWindow, Module=0xefffd96c) at conditional.c:543 #8 0x4e50c in execute_function (efa=0xefffd958) at functions.c:1103 #9 0x4e6a4 in old_execute_function ( action=0xa2748 Current WarpToWindow, tmp_win=0x0, eventp=0x8c45c, context=8, Module=-1, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #10 0x4f128 in execute_complex_function (eventp=0x8c45c, w=0, tmp_win=0x0, context=8, action=0x8ac00 , Module=0xefffdbcc, desperate=0xa2708) at functions.c:1666 #11 0x4e564 in execute_function (efa=0xefffdbb8) at functions.c:1120 #12 0x4e6a4 in old_execute_function ( action=0xefffdcd8 my_destroy_event, tmp_win=0x0, eventp=0x8c45c, context=8, Module=1, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #13 0x39830 in ExecuteModuleCommand (w=0, module=1, text=0xefffdcd8 my_destroy_event) at module_interface.c:643 #14 0x39718 in HandleModuleInput (w=0, module=1, expect=0x796d8 NOP UNLOCK, queue=0) at module_interface.c:608 #15 0x3ac08 in PositiveWrite (module=1, ptr=0x0, size=-268443328) at module_interface.c:1388 #16 0x39bf8 in BroadcastPacket (event_type=1, num_datum=7) at module_interface.c:844 #17 0x5e3cc in destroy_window (tmp_win=0x9da90) at add_window.c:2014 #18 0x5ea54 in CaptureOneWindow (fw=0x9da90, window=0, keep_on_top_win=0, parent_win=0, is_recapture=1) at add_window.c:2314 #19 0x5f0d0 in do_recapture (eventp=0x1, w=0, tmp_win=0x9da90, context=1, action=0x99f5f , Module=0xefffe944, fSingle=1) at add_window.c:2555 #20 0x5f168 in CMD_RecaptureWindow (eventp=0x8c45c, w=0, tmp_win=0x9da90, context=1, action=0x99f5f , Module=0xefffe944) at add_window.c:2578 #21 0x4e50c in execute_function (efa=0xefffe930) at functions.c:1103 #22 0x4e6a4 in old_execute_function (action=0xa28d0 RecaptureWindow, tmp_win=0x9da90, eventp=0x8c45c, context=1, Module=2, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #23 0x45ee4 in CMD_Current (eventp=0x8c45c, w=54, tmp_win=0x0, context=8, action=0xa28d0 RecaptureWindow, Module=0xefffeb04) at conditional.c:543 #24 0x4e50c in execute_function (efa=0xefffeaf0) at functions.c:1103 #25 0x4e6a4 in old_execute_function ( action=0x989f8 Current RecaptureWindow, tmp_win=0x0, eventp=0x8c45c, context=8, Module=2, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #26 0x39830 in ExecuteModuleCommand (w=0, module=2, text=0x989f8 Current RecaptureWindow) at module_interface.c:643 #27 0x3aedc in ExecuteCommandQueue () at module_interface.c:1547 #28 0x417d0 in My_XNextEvent (dpy=0x8f868, event=0x8c45c) at events.c:2685 #29 0x41b34 in HandleEvents () at events.c:2835 #30 0x641ec in main (argc=1, argv=0xe2e4) at fvwm.c:718 -- 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]
coredump from FvwmCommand Current RecaptureWindow
Configuration Information [Automatically generated, do not change]: uname output: SunOS silver 5.5.1 Generic_103640-37 sun4u sparc SUNW,Ultra-5_10 Compiler: gcc Compilation CFLAGS: -g -O2 prefix: /u/phippst/sunos FVWM Version: 2.5.0 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: fvwm-snap-20011105 Repeat-By: typed FvwmCommand Current RecaptureWindow and bang (gdb) where #0 0x3b778 in remove_window_from_stack_ring (t=0x98bb0) at stack.c:171 #1 0x3c040 in RaiseOrLowerWindow (t=0x98bb0, do_lower=0, allow_recursion=1, is_new_window=0) at stack.c:588 #2 0x3c300 in RaiseWindow (t=0x98bb0) at stack.c:737 #3 0x326ac in warp_to_fvwm_window (eventp=0x8c45c, t=0x98bb0, warp_x=356, x_unit=100, warp_y=524, y_unit=100) at focus.c:527 #4 0x32870 in CMD_WarpToWindow (eventp=0x8c45c, w=0, tmp_win=0x98bb0, context=1, action=0xb81c5 35p 40p # default to file button on menu bar, Module=0xefffd2ec) at focus.c:570 #5 0x4e50c in execute_function (efa=0xefffd2d8) at functions.c:1103 #6 0x4e6a4 in old_execute_function ( action=0xa5ba8 WarpToWindow 35p 40p # default to file button on menu bar, tmp_win=0x98bb0, eventp=0x8c45c, context=1, Module=-1, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #7 0x4f128 in execute_complex_function (eventp=0x8c45c, w=50331885, tmp_win=0x98bb0, context=1, action=0x8ac00 , Module=0xefffd54c, desperate=0xa5748) at functions.c:1666 #8 0x4e564 in execute_function (efa=0xefffd538) at functions.c:1120 #9 0x4e6a4 in old_execute_function ( action=0xd12cd my_conditional_cursorwarp, tmp_win=0x98bb0, eventp=0x8c45c, context=1, Module=-1, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #10 0x45ee4 in CMD_Current (eventp=0x8c45c, w=54, tmp_win=0x0, context=8, action=0xd12b8 (CurrentDesk !Iconic) my_conditional_cursorwarp, Module=0xefffd70c) at conditional.c:543 #11 0x4e50c in execute_function (efa=0xefffd6f8) at functions.c:1103 #12 0x4e6a4 in old_execute_function ( action=0xa5d08 Current (CurrentDesk !Iconic) my_conditional_cursorwarp, tmp_win=0x0, eventp=0x8c45c, context=8, Module=-1, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #13 0x4f128 in execute_complex_function (eventp=0x8c45c, w=0, tmp_win=0x0, context=8, action=0x8ac00 , Module=0xefffd96c, desperate=0xa5848) at functions.c:1666 #14 0x4e564 in execute_function (efa=0xefffd958) at functions.c:1120 #15 0x4e6a4 in old_execute_function (action=0xa6d28 my_cursorwarp, tmp_win=0x0, eventp=0x8c45c, context=8, Module=-1, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #16 0x4f128 in execute_complex_function (eventp=0x8c45c, w=0, tmp_win=0x0, context=8, action=0x8ac00 , Module=0xefffdbcc, desperate=0xa9390) at functions.c:1666 #17 0x4e564 in execute_function (efa=0xefffdbb8) at functions.c:1120 #18 0x4e6a4 in old_execute_function ( action=0xefffdcd8 my_destroy_event 0x8c3, tmp_win=0x0, eventp=0x8c45c, context=8, Module=8, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #19 0x39830 in ExecuteModuleCommand (w=0, module=8, text=0xefffdcd8 my_destroy_event 0x8c3) at module_interface.c:643 #20 0x39718 in HandleModuleInput (w=0, module=8, expect=0x796d8 NOP UNLOCK, queue=0) at module_interface.c:608 #21 0x3ac08 in PositiveWrite (module=8, ptr=0x0, size=-268443328) at module_interface.c:1388 #22 0x39bf8 in BroadcastPacket (event_type=8, num_datum=7) at module_interface.c:844 #23 0x5e3cc in destroy_window (tmp_win=0x98bb0) at add_window.c:2014 #24 0x5ea54 in CaptureOneWindow (fw=0x98bb0, window=0, keep_on_top_win=0, parent_win=0, is_recapture=1) at add_window.c:2314 #25 0x5f0d0 in do_recapture (eventp=0x1, w=0, tmp_win=0x98bb0, context=1, action=0xcf2df , Module=0xefffe944, fSingle=1) at add_window.c:2555 #26 0x5f168 in CMD_RecaptureWindow (eventp=0x8c45c, w=0, tmp_win=0x98bb0, context=1, action=0xcf2df , Module=0xefffe944) at add_window.c:2578 #27 0x4e50c in execute_function (efa=0xefffe930) at functions.c:1103 #28 0x4e6a4 in old_execute_function (action=0xc53c0 recapturewindow, tmp_win=0x98bb0, eventp=0x8c45c, context=1, Module=1, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #29 0x45ee4 in CMD_Current (eventp=0x8c45c, w=54, tmp_win=0x0, context=8, action=0xc53c0 recapturewindow, Module=0xefffeb04) at conditional.c:543 #30 0x4e50c in execute_function (efa=0xefffeaf0) at functions.c:1103 #31 0x4e6a4 in old_execute_function ( action=0xb7b48 current recapturewindow, tmp_win=0x0, eventp=0x8c45c, context=8, Module=1, exec_flags=0 '\000', args=0x8ac00) at functions.c:1172 #32 0x39830 in ExecuteModuleCommand (w=0, module=1, text=0xb7b48 current recapturewindow) at module_interface.c:643 #33 0x3aedc in ExecuteCommandQueue () at module_interface.c:1547 #34 0x417d0 in My_XNextEvent
Re: Several things
[EMAIL PROTECTED] wrote: While both of these screenshots are 1px less tall than their yesterday's AnotherLevel-based analogs (due to lack of buttons?), the picture is the same -- 2.4 is 2px wider and 1px taller than 2.2.4. However, I didn't check 2.2.5 yet (in fact, I never used it). The extra hilited pixel is also there. 2.2.5 looks like Style * mwmBorder is the default and 2.4 looks like Style * FvwmBorder is the default. COuld you try both of these versions with the line Style * mwmBorder in the config file? Cheers, Tim. -- 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]
No snapshots this month
Hi All, Just gone to update to the latest and there are no snapshots for September. Cheers, Tim. -- 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: --prefix include dir problem
[EMAIL PROTECTED] wrote: Have XPM support? no: Can't find required X11/xpm.h Does setting $CPPFLAGS to -I/sup/include help? Cheers, Tim. -- 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]
fvwm-menu-directory doesn't escape special chars
Configuration Information [Automatically generated, do not change]: uname output: SunOS silver 5.5.1 Generic_103640-35 sun4u sparc SUNW,Ultra-5_10 Compiler: gcc Compilation CFLAGS: -g -O2 prefix: /u/phippst/sunos FVWM Version: 2.4.1_beta1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.4.1_beta1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: fvwm-menu-directory produces syntax errors from fvwm when it tries to create a menu with a file that has two %'s in its name. It also doesn't handle * very well. @ and ^ in directory names needs fixing too but not in file names. Repeat-By: touch 1amp 1%perc 1*star touch 'doublequote' touch 2%perc% 2amp 2*star* mkdir 1^circ [EMAIL PROTECTED] 2^circ^ [EMAIL PROTECTED]@ touch 1^circ/file [EMAIL PROTECTED]/file 2^circ^/file [EMAIL PROTECTED]@/file Fix: Replace with etc. ^ is difficult with submenus as some shells interpret it as a |. It should be \ escaped by the time fvwm Exec's fvwm-menu-directory. -- 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: Incompatible change to FvwmBacker?
[EMAIL PROTECTED] wrote: Did I miss something when I concluded that FvwmBacker can no longer do what it did before? No, if FvwmBacker does what the man page says: *FvwmBackerCommand (Desk d, Page x y) command Specifies the command to execute when the viewport matches the arguments for the desk d, page x coordinate and y coordinate. Any or all of these three numeric arguments can be replaced with an asterisk (*) to indi- cate that any value matches, in this case Desk or Page parts can be skipped. Note these three lines are equivalent: *FvwmBackerCommand (Page * *, Desk *) -solid navy *FvwmBackerCommand () -solid navy *FvwmBackerCommand -solid navy plus this: There is continued support for the now deprecated option: *FvwmBackerDesk d command It is functionally equivalent to using an asterisk for both page coordinates with *FvwmBackerCommand. So *FvwmBackerDesk 0 ... gets translated to *FvwmBackerCommand (Page * *, Desk 0) ... which isn't quite the same thing. There seems to be no way to stop FvwmBacker doing its thing when the page changes and the desk matches. I think we should change the behaviour of FvwmBacker when the Page specifers are not included so that it _doesn't_ do its thing if only the page changes. Similarly if the Desk specifier is not included it _shouldn't_ do its thing when only the desk changes. Then translating *FvwmBackerDesk 0 ... into *FvwmBackerCommand (Desk 0) ... would work in the old way. Cheers, Tim. -- 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: FvwmButtons core dump
fvwm-workers@fvwm.org wrote: On Wed, Aug 15, 2001 at 08:06:42AM +0200, Olivier Chapuis wrote: I get a FvwmButtons core dump when I change colorsets and the buttons contains swallowed shaped app. FvwmButtons-WMakerApplets: Cause of next X Error. Error: 4 (BadPixmap) Major opcode of failed request: 54 (FreePixmap) Minor opcode of failed request: 0 Resource id of failed request: 0x2a2 Leaving a core dump now This core dump isn't very helpful. Obviously an X error occured that was not handled and then the routine that should generate the core dump crashed (probably by accessing an array index of (unsigned char)-1 ). I think the routine worked correctly i.e. it called abort(). The X-error is included above. Where it originates is another matter, you have to run in synchronous mode or guess. From the description it sounds like FvwmButtons is trying to free the shape mask (which belongs to the swallowed app) Cheers, Tim. -- 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: FvwmButtons doesn't like multiple Actions with whitespace separation
fvwm-workers@fvwm.org wrote: I don't think this is a bug. Omitting the commas between the options is not officially supported. This happens because OK then can we change the FvwmButtons man page and add a note in NEWS: *FvwmButtons: (options) [title icon command] Specifies the contents of a button in the buttonbox. The following options, separated by commas or whi- tespace, can be given a button: Cheers, Tim. -- 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]
FvwmButtons doesn't like multiple Actions with whitespace separation
Configuration Information [Automatically generated, do not change]: uname output: SunOS silver 5.5.1 Generic_103640-35 sun4u sparc SUNW,Ultra-5_10 Compiler: gcc Compilation CFLAGS: -g -O2 prefix: /u/phippst/sunos FVWM Version: 2.4.1-beta1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.4.1-beta1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Repeat-By: *Xloads: (Title pomeranian Action my_host_panel_launch pomeranian Action (Mouse 2) echo button 2 pomeranian) Xloads: Illegal button option echo button 2 pomeranian Workaround: Separation with commas works OK *Xloads: (Title pomeranian, Action my_host_panel_launch pomeranian, Action (Mouse 2) echo button 2 pomeranian) -- 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]
fvwmrect.h
Hi All, I can't find fvwmrect.h in the snapshots. The mail archive has it being added on 01/08/06. Cheers, Tim. -- 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]
