Re: make rpm-dist and deb-dist both fail with the same error
On Sun, Jan 15, 2006 at 09:44:49PM +, Mikhael Goikhman wrote: Just tested. Mere make is broken on the released fvwm-2.5.15 tarballs. Hrmpf, why didn't make distcheck catch this? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: bell on failed grab
On Sun, Jan 15, 2006 at 10:24:01PM +, Tavis Ormandy wrote: Hello, I would really like to appeal for the removal of the XBell() at line 1029 in fvwm/functions.c, part of execute_complex_function(). It doesnt serve any purpose as it is impossible to determine even if it was fvwm that rang the bell, and as no message is printed to stderr to indicate what the bell means there is no way for a user to find out what failed or what function was trying to execute when it failed. Additionally, it really drives me crazy as it makes a lot of the events supported by FvwmEvent totally unusable for me, as some of them may be triggered while the server is grabbed. Replacing the XBell() with a message to stderr stating failed to grab server in function FooBar or similar would be much more helpful to users who want to find out why their configuration isnt working, and much less annoying to users who realise that some commands may fail during a grab but want it anyway :) That's fine with me, so if someone makes a patch I'd apply it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: MenuStyle ActiveColorset and the need of HilightBack/ActiveFore
On Wed, Jan 18, 2006 at 10:45:08AM +0100, Viktor Griph wrote: On Wed, 18 Jan 2006, Viktor Griph wrote: Hi When using the ActiveColorset menustyle, you also have to specify HiglightBack and/or ActiveFore (without arguments) in order to make the style use the colorset. Just using ActiveAcolorset has no effect what-so-ever. I think it would be good to make ActivColorset imply ST_DO_HILIGHT_FORE and ST_DO_HILIGHT_BACK. I don't think many users use a colorset, of which they only want to use one (or no) color. By leaving the ability to turn off the use of the colors the current behaviour could be restored with a minor addition to a config file. Alternatively one could make ActiveCColorset imply ST_DO_HILIGHT_FORE and ST_DO_HILIGHT_BACK as long as none of those stiles have been used, which would only change behaviour for the few users that have an active colorset not used at the cost of one extra bit per menustyle. Ok, I just realized why HilightBack can't be on by default, so I guess I'll have to withdraw my opinion. Yeah, if I had the chance to write all the menu styles from scratch, I'd do it in a different way. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: make rpm-dist and deb-dist both fail with the same error
On 18 Jan 2006 12:45:21 +0100, Dominik Vogt wrote: On Sun, Jan 15, 2006 at 09:44:49PM +, Mikhael Goikhman wrote: Just tested. Mere make is broken on the released fvwm-2.5.15 tarballs. Hrmpf, why didn't make distcheck catch this? No matter how smart make distcheck is, it is always possible to fool it so that make in the subtree created by make dist works, but make in the same dist tree outside of the source tree fail. This was the case, a new Makefile.am code specifically used the files from the outer tree. Regards, Mikhael.
Re: bell on failed grab
On Wed, Jan 18, 2006 at 12:44:26PM +0100, Dominik Vogt wrote:
On Sun, Jan 15, 2006 at 10:24:01PM +, Tavis Ormandy wrote:
Hello, I would really like to appeal for the removal of the XBell()
at line 1029 in fvwm/functions.c, part of execute_complex_function().
That's fine with me, so if someone makes a patch I'd apply it.
Ciao
Dominik ^_^ ^_^
Great! How about this oneliner
--- functions.c 19 Oct 2005 06:25:18 - 1.270
+++ functions.c 18 Jan 2006 12:37:56 -
@@ -1026,7 +1026,10 @@
if (!GrabEm(CRS_NONE, GRAB_NORMAL))
{
func-use_depth--;
- XBell(dpy, 0);
+ fvwm_msg(ERR,
+ ComplexFunction,
+ Grab failed in function %s, unable to execute immediate
action,
+ action);
__cf_cleanup(depth, arguments, cond_rc);
return;
}
Thanks, Tavis.
--
-
[EMAIL PROTECTED] | finger me for my pgp key.
---
Patch: HasTitle and HasBorders
Hello, I'd been meaning to send these in for a while, but University work always seems to get in the way. :) I've created two patches[1] --- very minor ones that add two new conditionals: HasTitle -- Checks to see whether a window has a titlebar or not. HasBorders -- Checks to see whether a window has a border or not. I know they're trivial, but I find them really useful. Especially with things like FvwmEvent and FvwmAuto to conditionally apply styles to windows when they lose/receive focus. (I always thought it odd why there has always been a 'HasHandles' condition, and never anything else). I know I ought to update the manpage. I haven't, in case these patches are rejected. -- Thomas Adam [1] http://edulinux.homeunix.org/fvwm/patches/hastitle_hasborders.patch -- I'm brutal, honest, and afraid of you.
Re: Patch: HasTitle and HasBorders
On 18 Jan 2006 18:53:58 +, Thomas Adam wrote: I'd been meaning to send these in for a while, but University work always seems to get in the way. :) I've created two patches[1] --- very minor ones that add two new conditionals: HasTitle -- Checks to see whether a window has a titlebar or not. HasBorders -- Checks to see whether a window has a border or not. I am all for adding these conditions, but implementation is incorect. HasBorders can't work, since you do not use any window info for it. Hint: you may use has_no_borders window flag for this. Do you want to submit a correct patch (with all documentation too)? Regards, Mikhael.
Re: Patch: HasTitle and HasBorders
On Thu, Jan 19, 2006 at 12:57:18AM +, Mikhael Goikhman wrote: I am all for adding these conditions, but implementation is incorect . HasBorders can't work, since you do not use any window info for it . Hint: you may use has_no_borders window flag for this. Ah. But I did add a flag to fvwm.h for this: has_borders. I would have used has_no_borders, and I probably should. I'll change it, if you like? Do you want to submit a correct patch (with all documentation too)? OK. I'll do this in the morning, after I have slept. Thanks. -- Thomas Adam -- I'm brutal, honest, and afraid of you.
Re: Patch: HasTitle and HasBorders
On 19 Jan 2006 01:16:28 +, Thomas Adam wrote: On Thu, Jan 19, 2006 at 12:57:18AM +, Mikhael Goikhman wrote: I am all for adding these conditions, but implementation is incorect . HasBorders can't work, since you do not use any window info for it . Hint: you may use has_no_borders window flag for this. Ah. But I did add a flag to fvwm.h for this: has_borders. I would have used has_no_borders, and I probably should. I'll change it, if you like? You added a flag that noone sets (it is always zero). Another side effect after applying your patch is Move becomes Outline instead of Opaque after Restart --dont-preserve-state. Please test the patches thoroughly. Regards, Mikhael.
Re: Patch: HasTitle and HasBorders
On 19 Jan 2006 01:16:28 +, Thomas Adam wrote: OK. I'll do this in the morning, after I have slept. We are not really in hurry. In fact, I would feel more comfortably before applying any patch if its author tells that he runs fvwm with this patch applied for several days without problems and that he verified all new (and some old) functionality in variety of ways. Thanks for contributing. Regards, Mikhael.
