Re: travis-ci - fvwm.git master branch is "protected"
Den 24 mar 2016 5:22 em skrev "Thomas Adam": > > Hi all, > > I've to document this formally, but I wanted to let you know of a few options > I've enabled for the "master" branch on the main fvwm Git repository. > > All pushes by default (across all branches) will now have Travis CI ran > against them. Travis is a Continuous Integration tool[1] which allows the > code to be compiled. If there's any errors, an email is sent out indicating > where the logs can be found[2]. Cool. Would it be possible to stick some unit test framework to it as well? > Additionally, the master branch (which is where all the stable code intended > for releases ends up) now has protection enabled, which means code will not be > merged there by default, should Travis CI be unable to build it. This should > help things be more robust, and provides a much more powerful alternative to > the old snapshot mechanisms of yesteryear. This also means commits directly > on master are discouraged---but that's OK because we've discussed that before. Is our strategy for handling of branches and pull requests summarized anywhere? /Viktor
Re: CVS domivogt: * Fixed the TitleWarp menu style.
On Wed, 25 Oct 2006, Tavis Ormandy wrote: On Wed, Oct 25, 2006 at 10:34:08PM +0200, Dominik Vogt wrote: Hello, I really liked this behaviour, is it possible to re-enable it as an option? Ever since this was introduced I've been launching the wrong applications :) What's the problem? The pointer used to warp to the first entry, but now it it doesnt move. It's not a problem, I just preferred the old behaviour! I'm having to re-learn my menu-using habits :) Thanks, Tavis. You can add the special option WarpTitle to the menu commands you want to warp to the title. /Viktor
todo-2.6: C.23 XForms sliderall demo
I've been doing some tests, and the problem is partly fixed in the current version. Keybindings no longer stop working as in the bug description, but the focused window decorations are still incorrect in the same way as reported. sliderall is an unmannaged window that takes focus on EnterNotify, and keeps the focus until any other window takes focus, or the wm gives focus away to some other window. When fvwm detects an unmannaged window stealing focus it does not change the decoration of the focused window, and if the unmanaged window gives away the focus fvwm sends it back to the window that had focus before. With SloppyFocus, as in the case of the report the focus will not be taken by fvwm if the mouse enters the root window, but fvwm will still show the earlier focused window as focused. What is the desired behaviour in this case? a) defocus the window when an unmannaged window takes focus b) always refocus the last focused window if the mouse enters the root window when focus is stolen by an unmanaged window? c) something else? /Viktor
Re: MapWindow directly after UnmapWindow
On Tue, 29 Aug 2006, Dominik Vogt wrote: On Mon, Aug 28, 2006 at 08:07:31PM +0200, Viktor Griph wrote: On Mon, 28 Aug 2006, Andreas Ehliar wrote: I have a problem with fpga_editor as reported in bug 4062. With some help from #fvwm I managed to find something suspicious. fpga_editor does an UnmapWindow request and a MapWindow request right after each other. An example program that does the same is located at http://www.da.isy.liu.se/~ehliar/priv/map_unmap.c . The example program will show a window for 1 second and it will then disappear if running under fvwm. The bug seems very similar to the bug reported in this thread: http://www.mail-archive.com/fvwm@hpc.uh.edu/msg08195.html This bug is related to the handling of MapRequests in fvwm. (See http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15491.html.) I know of three different ways to address it, but don't know if there is any downside to them. The different approches are 1) Change AddWindow to look at the trigger event for the mapped window if the window in the execution context is gone. I think this is too late in the line to address this. 2) Change the Handling of MapRequest to call AddWindow with the window being mapped in the execution context. (I think this is better than 1) I don't actually understand the problem or the suggested solutions. Can you explain it a bit? The problem is that, if the program calls MapWindow before the window has been reparented to the root it will get a XMapRequest with window= old decoration parent window and window set to the client. Handle event sets the window of the execution context to xany.window (parent in this case) if the parent window is not root. When this is a destroyed decoration it will be passed to AddWindow in the function called from HandleMapRequest. the suggested fix would be to modify the context to have the window of the MapRequest event set to the context before calling AddWindow if the trigger event is a MapRequest. (I'm not entirely sure on how CaptureAllWindows works, but I believe this logic would be ennouh to keep it working correctly.) 3) Decide that Maps following Unmaps is a bad application behaviour and have the handling of Unmap check if the window is about to remap before deciding to destroy it. That's wrong. If a window is unmapped the window structure must be destroyed. There is no reliable way to find out if the window is remapped or if it was destroyed and a different window got the same id. The idea was to check for a MapRequest of FW_W_PARENT before reparenting the window, while the server is grabbed, and if sush event exists not unparent it. The problem is only if the window is mapped again before the client is reparented to root. I'm most interested in knowing if there would be any downside with solution 3, in which case solution 2 is the one to take. /Viktor
Re: MapWindow directly after UnmapWindow
On Mon, 28 Aug 2006, Andreas Ehliar wrote: I have a problem with fpga_editor as reported in bug 4062. With some help from #fvwm I managed to find something suspicious. fpga_editor does an UnmapWindow request and a MapWindow request right after each other. An example program that does the same is located at http://www.da.isy.liu.se/~ehliar/priv/map_unmap.c . The example program will show a window for 1 second and it will then disappear if running under fvwm. The bug seems very similar to the bug reported in this thread: http://www.mail-archive.com/fvwm@hpc.uh.edu/msg08195.html This bug is related to the handling of MapRequests in fvwm. (See http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15491.html.) I know of three different ways to address it, but don't know if there is any downside to them. The different approches are 1) Change AddWindow to look at the trigger event for the mapped window if the window in the execution context is gone. I think this is too late in the line to address this. 2) Change the Handling of MapRequest to call AddWindow with the window being mapped in the execution context. (I think this is better than 1) 3) Decide that Maps following Unmaps is a bad application behaviour and have the handling of Unmap check if the window is about to remap before deciding to destroy it. I'm most interested in knowing if there would be any downside with solution 3, in which case solution 2 is the one to take. /Viktor
Re: CVS griph: * use ewmh allowed actions to track window movability
On Thu, 10 Aug 2006, Dominik Vogt wrote: On Thu, Aug 10, 2006 at 04:24:48AM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/08/10 04:24:48 Modified files: . : NEWS modules: ChangeLog modules/FvwmPager: FvwmPager.h x_pager.c Log message: * use ewmh allowed actions to track window movability in pager Hm, I guess that works, but it ties pager actions to the configuration of the ewmh stuff. I have long been planning to allow the user to disable specific ewmh features. If a user did that, the pager would break. Would an option to disable allowed actions really be useful to a user? All it does it to tell applications what actions are possible on a window. The only thing I can think of that can break it is if a EWMHFixedPosition style was added, that makes the ewmh allowed actions differ from the fvwm allowed actions. In event of that allowed actions could be made part of the configure window package. If that's the only pitfall, then currently a comment in is_function_allowed warning about it would be ennough to avoid unintended breakage. /Viktor
Re: CVS griph: * use ewmh allowed actions to track window movability
On Thu, 10 Aug 2006, Dominik Vogt wrote: On Thu, Aug 10, 2006 at 12:58:06PM +0200, Viktor Griph wrote: On Thu, 10 Aug 2006, Dominik Vogt wrote: On Thu, Aug 10, 2006 at 04:24:48AM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/08/10 04:24:48 Modified files: . : NEWS modules: ChangeLog modules/FvwmPager: FvwmPager.h x_pager.c Log message: * use ewmh allowed actions to track window movability in pager Hm, I guess that works, but it ties pager actions to the configuration of the ewmh stuff. I have long been planning to allow the user to disable specific ewmh features. If a user did that, the pager would break. Would an option to disable allowed actions really be useful to a user? I meant an option to disallow window movement via EWMH messages. EWMH applications could be disallowed to move windows this way, but the pager should still be allowed to. The reason why I did the ewmh implementation in the pager was that it was simple, and I didn't have to mess with the configure message. I'm not yet comfortable with the module interface code, and don't really know the best way to send allowed actions. Straightforward would be to just add them to window_flag, but that feels wrong. Another way would be to add a struct with allowed actions to the package and send it after the flags part of the message. Both these ways should I probably be able to do. I'm not sure if it's possible to add some function call result directly to the CONFIGARGS package, and that was when I started to look at other 'easier' solutions. The change to the pager is minimal to move it to use flags sent by fvwm instead of read via ewmh once the flags are sent. /Viktor
Extending the ways for modules to request information back
I've been wanting a way to have fvwm perform tests for modules and respond to the module for some time now. While it's possible to use SendToModule with an argument 6 alias, or the program name, that may lead to the reply being sent to more modules than the originating module. To allow this kind of talkback I want to have a way to send a M_STRING (or a new similar message) to the module in current execution context. This could be done with an option to SendToModule, but that would risk breaking some configs or modules using a name or alias matching the literal option. The other way would be to add a new command, only usable form modules (similar to Send_WindowList and Send_ConfigInfo). I think that Send_Reply is a suitable name. Another similar thing that would be very useful is a Send_Rc prefix command with the following syntax: Send_Rc token command That should generate a package with the token and the return-code of the command along with the usual window context to the originating command. Another way to allow similar functionality for modules would be to the returncode preserved for each module, so that it's possible to send TestRc commands without having to define a function to do so. What do you think? Which of these are useful, and which ways are the best. /Viktor
Re: CVS griph: * make non-icon mode pager use fvwm command for moving
On Wed, 9 Aug 2006, seventh guardian wrote: On 8/9/06, Viktor Griph [EMAIL PROTECTED] wrote: On Wed, 9 Aug 2006, FVWM CVS wrote: * don't add title height and border width to coordinates on pager move I think that this chagen is correct. I did some tests without it, and is seems as if high-title windows would slip down the screen without it. At least it was definately wrong for TitleAtLeft/Right styles. I #if 0:ed the code, so someone else can look at it and see if I'm correct in that it was incorrect before. I've noticed another problem with my icons. They are usually on the bottom left corner of the screen, and in the pager they are a bit lower (partialy in the screen bellow). This may mean the coordinates sent from fvwm are not being correctly used by the pager. This may be part of the problem above. My icons seems to be at the right position in the pager, altough the scaling makes things tricky to test. If it were possible to make a 1:1 scale pager testing would be easy. Maybe I should look into what limits the pager size to a quarter of a pager and remove it for debugging purpose. /Viktor
moving icons across desks with Move breaks drawing
With a blank config the following produces some erractic behaviour: Style * Icon SOME_ICON AddToFunc BreakIcon + I Iconify on + I MoveToDesk 1 + I Move 0 0 Next BreakIcon results in a non-updated (icon match background and can be moved as such with Move, and icon title blank until the icon is highlighted) icon window at the top left corner. I've no idea where the error is. I don't even know the expected result of the above function. (Are Move ever supposed to bring a window (or it's icons) to the active desk? /Viktor
Re: Tracking flag changes from modules
On Tue, 8 Aug 2006, seventh guardian wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. Well, it could work properly. Just ask for a null move (move the window to its current position) as soon as the user tries to move the miniwindow. If the command was rejected fvwm issues a simple error packet. The Pager now knows it can't move the window. If the command wasn't rejected then the pager can send the real Move command, to move the window to its new position. While this could work, it probably requires a largeer rewrite of the pager code to allow it to wait for a response from fvwm before starting the move. This resoponse can come mixed with several other messages that has to be taken care of in the normal way. What about adding a command to check for movement ability (CanMove or something like this)? This way fvwm would tackle the multiple style conflicts, and the pager needed to know nothing about the actual flags and stuff. Also, no new packet would be required. It would work the same way as the above solution, so the above could be simpler. A CanMove command is not needed, and not desireable. Instead it should be a 'Movable' conditional, which probably is quite easy to add. There is still one problem, that already affects the code somewhat: The SendToModule command can be used to send instructions back to the module on a successful test. However, it can only direct the messages by name, which mean that they might get to multiple instances of a module. Properly designed messages, in combination with the module knowing which messages it's waiting for can solve this, but it would be nice for a way for a module to uniqely define itself to fvwm as a recipent in a SendToModule command. /Viktor
Tracking flag changes from modules
Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? /Viktor
icon movement tracking
Should the flag tracking icon movement be set by MoveToPage? Currently it's not, which makes icons jump back to the initial page if do for example 'Style * IconTitle' if an icon has been moved to another page by MoveToPage. On a sidenote the same problem exists whenever moving icons with the pager, even if they are kept on the same page. /Viktor
Re: Tracking flag changes from modules
On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. /Viktor
Re: Documentation for module developers
On Sun, 30 Jul 2006, Thomas Adam wrote: On Mon, 31 Jul 2006 00:19:51 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Sun, Jul 30, 2006 at 06:02:51PM +0100, Thomas Adam wrote: On Sun, 30 Jul 2006 14:40:50 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hi, Are http://www.fvwm.org/documentation/dev_modules.php is the only module related documentation available? BTW, I found an error on this page: in section 'Colorset support' InitPictureCMap() should be PictureInitCMap() instead (this function was renamed on 2002-04-22 according to main ChangeLog). Other than that minor fix, was there some specific information not listed on that page you were after? Yes. I want full FVWM API description. For example, FScreenInit, FRenderInit and many other functions used in modules aren't described there. Tutorials are also welcome. Of course I can figure out all missing details by reading source code, but this cost time. Currently there isn't any such documentation about those. Do what you can by reading the source code and sporadic comments therein where applicable. This is all I do. If you feel like documenting it yourself as you go, that too would be good. :) -- Thomas Adam There is '[C]Modules from scratch'[1] which gives a quick introduction to the module communication, but it's not using the fvwm libs. There is however one thing in there that is worth noting, either as a bug in the module communication or in the documentation: | Basically you have to send the command NOP FINISHED STARTUP to FVWM | before it will start talking to your module. This isn't mentioned | anywhere on the module page, and is barely eluded to in the fvwm man | page. /Viktor [1] http://fvwm.lair.be/viewtopic.php?t=260
Re: Flags - is negation prefered?
On Mon, 17 Jul 2006, Thomas Adam wrote: On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote: Yes, but then the 2.5 manual should be updated. I'll start doing that.. Don't be too hasty. :) Things like: Style foo !Icon Won't work. Another thing to remember is that all options that still are supported, but not preferred should still be documented, or someone searching for what an option in a config file does might not find it. /Viktor
Re: Flags - is negation prefered?
On Mon, 17 Jul 2006, Dominik Vogt wrote: On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. The ! negation style is preferred. I coded it for exactly the reasons you describe. There are so many different typed of on/off syntax. Should the old style negation options be deprecated in the code (give warnings) before 2.6? /Viktor
Re: CVS griph: * add variable filters
On Sun, 16 Jul 2006, Dominik Vogt wrote: On Fri, Jul 14, 2006 at 05:30:03PM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/07/14 17:30:03 Modified files: . : ChangeLog NEWS fvwm : expand.c fvwm.1.in libs : Strings.c Strings.h Log message: * add variable filters * make backslash escape character within $[...] expressions If you write such patches that are monitored by several developers it would be nice to explain what you are doing and how. We have to be very careful with big changes in the parsing code because it has the potential to break everything. Personally I want to proofread such changes. I'll do so in the future. The changes are quite isolated. Most additions are done in new functions. Appart from that the start of the filters are registered in the parsing of the variable name and sent to the expansion functions. They have some code added for when the filters are non-NULL. With filters==NULL the same code as before is executed. I can understand that you want to proofread the changes. The syntax I quoted that Mikhael suggested has not really been thought about a lot. It's just an ad-hoc idea. Now that you implemented it, I think it has several general issues: The best way to see limitations in a (simple) system is to implement it and play around with it. It's not mush work put down into the implementaion. I mainly needed the single and quote filter myself when the ranged positional parameters changed expansion and thought I'd give it a try. * There is currently no way to quote a literal string, which is a very important feature. It would allow users to write monsters like this more easily: + I PipeRead 'cd $HOME/.fvwm/palettes; /bin/ls *.pal | sed -e \s:\\(.*\\)\\(\\.pal\\):+ \\1 Function SetPalette \\1\\2:\' I see your point. I aslo thought about the gettext expansion, and possible problems of changing the ':' meaning. * The syntax is too verbose. The strings you have to write eat up too much space. Also, the name filters is misleading. In almost all syntax in fvwm is verbose. Why should this be an exception? Except for the fact that the way it is done now makes the filters to be parsed several times. I'm sure it's possible to optimize that by preparsing the filter-string and invent some easier to deal with representation. However I didn't want to try to do that since I thought that the patch might have to be reverted anyway. I suggest to follow zsh's example: $[(flags)name] Where name is the parameter name itself and flags describes the modifications to apply to the expansion process. Thinking of this compared to the one currently implemented I must say that this has several advances: * it will most likely not break anything existing (at least I've never seen an environment variable containing braces. * it's easier to preparse the flags since the order doesn't matter. Flags: qstyle[n] (quote) Quote the string n times using the given style. style can be one of q quote normally for use as a token mi quote for use as a menu item label mt quote for use as a menu title l (literal) Quote a literal string, i.e. everything up to the closing brace. r0 (recursive expansion off, default) r1 (recursive expansion on) Enable or disable recursive expansion ($[$[X]]) Note: If the flags l and r1 are present, recursive expansion takes place first, and the result is used as literal input for further processing - it is *not* interpreted as a variable name. s[n] (split) Split string into individual tokens (by removing n levels of quotes and whitespace). n defaults to 1. t (tokenize) Treat the resulting string as a single token (Useful in ranges). Examples: With X=foo`bar`, $0=0, $1=1, ... (without the quotes): $[(qq)X] -- 'foo`bar`' $[(s1qq)X] -- 'foo' 'bar' $[(lqq2)foo`bar`] -- 'foo`bar`' $[(lr1)X] -- foo`bar` $[(qq)1-3] -- '1' '2' '3' $[(tqq)1-3] -- '1 2 3' Maybe flags should be separated by colons to allow more and longer flag names like $[(literal:qq)foo bar] Thinks that are not good in the current patch: * I think we shouldn't have different styles of quoting filters. Just quote: should be enough. This is because quoting is just meant to be used *internally by fvwm*. And fvwm does not care wether tokens are quoted by , ', ` or \. Fvwm could just choose the type of quotes that has the shortest result. A string quoted this way can *not* be passed to a shell for example. What I did regarding filters was to try implement the ones in todo-vars based on what was given there. * It should be possible to add multiple levels of quotes in a single filter (usefull in
Re: FVWM crashes with $[0]
On Fri, 14 Jul 2006, Scott Smedley wrote: I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] Is this supposed to be fixed? FVWM still crashes on my system when I type Echo $[0] in FvwmConsole. I am using current version of CVS. Scott. There is something wrong with __eae_parse_range. I'm not that good on sscanf, but I think that it will match %u-%n even for 0 and return a good number, meaning that n will have a random value. Then it might segfaut later on *input == 0 since input += n /Viktor
Re: FVWM crashes with $[0]
On Fri, 14 Jul 2006, Dominik Vogt wrote: On Fri, Jul 14, 2006 at 09:07:21AM +0200, Viktor Griph wrote: On Fri, 14 Jul 2006, Scott Smedley wrote: I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] Is this supposed to be fixed? FVWM still crashes on my system when I type Echo $[0] in FvwmConsole. I am using current version of CVS. There is something wrong with __eae_parse_range. I'm not that good on sscanf, but I think that it will match %u-%n even for 0 and return a good number, meaning that n will have a random value. Yes, one big problem is that %n may or may not increase the return code by one, so if rc = scanf(..., %u-%n, ...); returns one, this can mean is parsed just the integer and stopped, or it parsed the integer, found a '-' and assigned the %n too. Fixed. sscanf seems to not be very restrictive when it comes to unsigned integers. It seems as if it accepts signed integers as well. At least $[-1] hang fvwm now. /Viktor
Re: more on expansion behaviour
On Fri, 14 Jul 2006, Scott Smedley wrote: Hi all, Help please. addtofunc fn + i echo executing $[0-] + i $[0-] fn echo hello How come fn doesn't print out hello? After some time debuging it turns out to be problem with the parse function usage. I'm not sure the best way to fix it, but this is what happens: in functions.c the functon to execute is peeked from the action string. It's then passed to expand_vars. Before expand_args_extended no parsefunctions were used in expand_vars, so everything was good. With expand_args_extended using PeekToken the input to expand_vars gets overwritten and the expansion fails. expand_vars is only called from functions.c, once with a peeked token and once on the entire action string. Looking at the code I'm not even sure why it can't do things the other way around. (First expand and then peek the function name.) In fact the curent behaviour seems wrong as per this example: AddToFunc TestFunc + I Echo Hello hello + I $* TestFunc Echo Hello hello This will print hello and produce an error. If expansion was made before the function token is peeked it will produce the exact same result. /Viktor
Re: CVS domivogt: * Removed ifdefs from fifos.c.
On Wed, 12 Jul 2006, FVWM CVS wrote: Log message: * Removed ifdefs from fifos.c. * Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat issues. Is it really neccessary to defene everything with FVWM_ as a prefix? If it's not already defined, why not define it using the expected name? /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. /Viktor Can you see if the fix I comitted for the above fixes your error as well? It's possible that it's the same error if your strlen doesn't segfault on NULL-input (and you did call Echo $[0] from within a funcion called by a trailing space or something else to form an argument string with no tokens). /Viktor
Re: CVS domivogt: * Removed ifdefs from fifos.c.
On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 09:16:24AM +0200, Viktor Griph wrote: On Wed, 12 Jul 2006, FVWM CVS wrote: Log message: * Removed ifdefs from fifos.c. * Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat issues. Is it really neccessary to defene everything with FVWM_ as a prefix? If it's not already defined, why not define it using the expected name? I use the fvwm prefix to document that we modified its meaning. If we had just #define O_NOFOLLOW 0 someone might rely ona that flag although it's just a dummy to make the compiler happy. Well, you didn't define it FVWM_O_NOFOLLOW in configure.ac, so it's just O_NOFOLLOW in there as well. It was all the stat-wrappers that I was concerned about. The code use many of them unwrapped already, so if there is a chance that some of them might not be defined it would be better to provide them, with the assumed values you did, under the name expected by the programmer. /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. There are several bugs/crashes in expand_args_extended(): 1) It does not check the range of the positional parameters. It happily parses and uses for example $[999]. I didn't try it, but I guess it causes random memory access. I believe that SkipNTokens just stops when there is no more to consume. Then $[999] will be empty if there are less then 1000 words in the string. 2) In the if (is_single_arg) it uses the token returned by PeekToken as the base for further parsing functions. This is strictly forbidden because PeekToken returns a pointer to a static buffer. Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. 3) As I said in an earlier message, PeekToken never returns an empty string. Calling PeekToken(, ...) returns a NULL pointer which the code accessed later. This was the error I fixed already. /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. There are several bugs/crashes in expand_args_extended(): 1) It does not check the range of the positional parameters. It happily parses and uses for example $[999]. I didn't try it, but I guess it causes random memory access. I believe that SkipNTokens just stops when there is no more to consume. Then $[999] will be empty if there are less then 1000 words in the string. Checking the code again I see no reason to have a limit to only work with 10 arguments. The main purpose of expand_args_extended was to allow access to parameters beyond the 10th. That's why it's using parse-functions to find the selected parameters rather than looking them up in the arguments array that $0-$9 expansion does. 2) In the if (is_single_arg) it uses the token returned by PeekToken as the base for further parsing functions. This is strictly forbidden because PeekToken returns a pointer to a static buffer. Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. I think that, for readability some change is needed, but I don't think it's neccessary to use GetNextToken instead of PeekToken. It just adds an extra free in an extra if. For readability it would probably be nicer to add !is_single_arg to the if (upper = 0) /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 05:07:17PM +0200, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? Probably because I didn't think of it as I added is_single_arg later to deal with the fact that $0 should be the same as $[0]. -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. [snip] * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. The old variables also work in this way, so it's only trying to mimic the old behaviour. All my tests make $[0] identical to $0. In what way are they different? Heck, you're right. I still don't it this is good: destroyfunc bar addtofunc foo + i addtofunc bar i $0 If you now invoke foo echo $1 bar 0 1 2 It should print '1', but currently it prints an empty string. It's just the way the other $-Variables (like $w) work: If it can not be expanded, keep the Variable reference. Anyway, it's too risky to change now. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. The deepest nestings are in the actual parsing of the parameters, and that's hard to do without the nesting. Regarding the actual parameter extraction I treid to write useful comments to tell what's going on and why. I'm not sure what more can be done. Look at the code I've committed. It uses a subfunction to parse the parameter range and reduces the number of nesting levels by two. It also properly unquotes argument ranges. Note that I did not test anything. I don't have much time now, but two random test results: Echo $[-0] should print the first argument but prints $[-0] This construct is not in the manpage (and thus never implemented (at lest not in my version. I've not checked the newcode yet.)) Echo $[1-0] (or any other invalid range) should be just copied, but it is replaced with an empty string. This worked with my version. The function should return -1 when it should be copied and 0 when it should be replaced with an empty string. /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? Probably because I didn't think of it as I added is_single_arg later to deal with the fact that $0 should be the same as $[0]. -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. $* has always worked they way it works as well. I for sure have some functions that rely on passing arguments to other functions, so changing the behaviour of $* would break my config. Also reading the todo-vars file it states that $[number] should be unquoted for backwardscompability. The $[range] can be treated differently as that is a new feature. I see use for both the 'raw' style and the unquoted style, but as I understand the todo it really should be single-quoted as they are niether $[number] not $[range], which are the only exceptions to that rule listed. Regarding the dequoting of the positional parameters I belive the best thing would be to make a function to unquote an entire string. I'm not sure how optimized it is to peek every token just to get rid of the quotings. Also the most flexible code for the argument expansion would be keeping the raw string as long as possible, and then dequote it and possible requote it depending on filter-selection. Maybe the best thing is to remove the $[range] alltogether until the filter-system is ready to not add another exception to how things work. I'd really like to hear Mikhael's opinion on this. [snip] * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. The old variables also work in this way, so it's only trying to mimic the old behaviour. All my tests make $[0] identical to $0. In what way are they different? Heck, you're right. I still don't it this is good: destroyfunc bar addtofunc foo + i addtofunc bar i $0 If you now invoke foo echo $1 bar 0 1 2 It should print '1', but currently it prints an empty string. It's just the way the other $-Variables (like $w) work: If it can not be expanded, keep the Variable reference. Anyway, it's too risky to change now. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. The deepest nestings are in the actual parsing of the parameters, and that's hard to do without the nesting. Regarding the actual parameter extraction I treid to write useful comments to tell what's going on and why. I'm not sure what more can be done. Look at the code I've committed. It uses a subfunction to parse the parameter range and reduces the number of nesting levels by two. It also properly unquotes argument ranges. Note that I did not test anything. I'll take a look at the code more later. Currenlty I've only looked at the diff to get some idea of what you are doing. /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 05:00:27PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 02:55:24PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. There are several bugs/crashes in expand_args_extended(): 1) It does not check the range of the positional parameters. It happily parses and uses for example $[999]. I didn't try it, but I guess it causes random memory access. I believe that SkipNTokens just stops when there is no more to consume. Then $[999] will be empty if there are less then 1000 words in the string. 2) In the if (is_single_arg) it uses the token returned by PeekToken as the base for further parsing functions. This is strictly forbidden because PeekToken returns a pointer to a static buffer. Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? Probably because I didn't think of it as I added is_single_arg later to deal with the fact that $0 should be the same as $[0]. -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. * Currently, $* is broken too as it does not remove quoting but just copies the input string. See above. * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. The old variables also work in this way, so it's only trying to mimic the old behaviour. All my tests make $[0] identical to $0. In what way are they different? * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. The deepest nestings are in the actual parsing of the parameters, and that's hard to do without the nesting. Regarding the actual parameter extraction I treid to write useful comments to tell what's going on and why. I'm not sure what more can be done. Waiting for a responce I've done some minor cleanup as suggested, and removed the range-checks again. One thing that still looks weird to me, (that wrote it) is the argument_string = SkipSpaces( SkipNTokens(argument_string, lower), NULL, 0); The token parser stops after the first non-token character, e.g. a space. In your old code, SkipSpaces was necessary, in the patch I just committed it isn't. args_end = SkipNTokens(argument_string, upper - lower + 1); while (argument_string args_end isspace(*(args_end - 1))) { args_end--; } which seems to assume that SkipNTokens can end with any number of spaces before or after the next token in the list. Is that so? Or is either SkipSpaces or the while-loop unneeded? If the tokens are copied dequoted, trailing spaces have to be removed. If $[*] does not dequote, it should keep trailing whitespace. The only time it removed the trailing whitespace was in ranges with closed upper end. It kept them for $[*] and $[2-] etc. /Viktor
using lstat
Is there some define to check for systems that have lstat? /Viktor
Re: CVS griph: fix tempfile vulnerabilities in FvwmCommand (bug
On Tue, 11 Jul 2006, Dominik Vogt wrote: On Tue, Jul 11, 2006 at 10:16:09AM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/07/11 10:16:09 Modified files: . : ChangeLog NEWS configure.ac modules: ChangeLog modules/FvwmCommand: FvwmCommand.1.in FvwmCommand.c FvwmCommandS.c fifos.c Log message: fix tempfile vulnerabilities in FvwmCommand (bug #2791). Can you explain what you actually did, please? Sure. First: When deciding on the default path the three files that are to be used are tested with lstat (or stat if lstat is unavalable) to have the same owner as the process owner, not have nore than one hard link and not be a directory nor a symbolic link. If any of the tests fail the path will be redirected to $FVWM_USERDIR instead of /var/tmp to avoid attacks blocking the module. If some tests are impossible to do they are concidered OK. Second: All open() calls use O_NOFOLLOW if that flag is defined. I believe this should be ennough, but if one are really paranoid one could add checks of the opened files in FvwmCommand.c to verify that they are fifos with correect permissions. /Viktor
Re: Periodic command
On Wed, 5 Jul 2006, Scott Smedley wrote: Hi Dominik, Can you have multiple peridic commands or just one? Multiple. I suggest to replace the command Periodic with some option to the Schedule command The current specification for Schedule is: Schedule delay_ms [command_id] command So, would something like the following do? Schedule delay_ms [command_id] [Periodic] command Perhaps someone has a better suggestion? I think the above is good. The only problem with it is that if someone has a function named Periodic and use to execute that with Schedulte the above will break that config. One way to avoid that, and also give room for more possible options to Schedule in the future, is to put options before the delay. That way any string before the delay number could be read as an option. So Schedule [Periodic] delay_ms [command_id] command would be a possible easier to parse syntax. /Viktor
Matlab figure window refusing to move
I believe this to be a bug in matlab, but I report it here as someone might know of a workaround for i. It seems as if an obscured matlab figure will refuse to be moved, unless some not yet completely known conditions are met on the final destionation. It just bounce back to the original position. In some cases when moving it from obscured by one window to obscured by another window it seems to sometimes generate some race conditing in moving between the both positions. The following two files contain output from xev tied to a matlab figure: http://www.dd.chalmers.se/~griph/matlab-refuse-move.txt http://www.dd.chalmers.se/~griph/matlab-race.txt Anyone got any idea of what's behind this and if tere is any way to make fvwm work around the problem? /Viktor
Re: What are the hide windows in frame.c?
On Fri, 5 May 2006, Dominik Vogt wrote: On Thu, May 04, 2006 at 08:54:25PM +0200, Viktor Griph wrote: When are the hide windows useful in frame.c? The call to frame_reparent_hide_windows in frame_create_move_resize_args casue X to generate extra VisibilityNotify events to clients during capture and redecoration (bug #3977). The hide windows are emtpy windows (with a None background pixmap). I introduced them to reduce flickering of the window decorations when a window is resized, and - more important - shaded or unshaded. The problem is that when you resize a window, you can tell X which border its subwindows should stick to. But you can not tell it where the subwindows of subwindows should go, and it's not possible to resize subwindows in the same operation. Because of this, I use the hide windows to cover some parts of the decorations, resize the window, redraw the the changed parts of the decorations windows (using a background pixmap, not using the foreground), then unmap the hide windows to uncover the changed decorations. Usually, the hide windows stay invisible because htey have no contents and just show what was below them until they are covered by something else. Now I understand the need for them for resize operations. Would it be possible to narrow down the need for that function call to some specific case? I don't see any way but at the expense of flickering decorations and subwindows, especially with opaque resizing. Am I right if I say that the hide windows do no good if it is a setup request and the frame size has not changed? I'm not sure how the initial mapping is treated, but I believe they do no good for that either. It's just a little harder to seed that condition from withing the function. Actually, if applications like xdvi have a below par redraw algorithm (i.e. they redraw whenexer they receive an Expose event), that's the applications' problem and not the problem of the window manager. It's true that the application may be behaving badly, but there are several application that show similar flickering due to the exrtra events on a redecoration. if it's possible to work around the events with the window mannager it's a good thing to do, but not at the expense of some other functionality. Just for reference the thing that annoys me most about this is the fact that my titleless pager and xbuffy flash whenever I redecorate (including even disable an already disabled title bar button) /Viktor
Re: What are the hide windows in frame.c?
On Tue, 9 May 2006, Viktor Griph wrote: On Fri, 5 May 2006, Dominik Vogt wrote: On Thu, May 04, 2006 at 08:54:25PM +0200, Viktor Griph wrote: When are the hide windows useful in frame.c? The call to frame_reparent_hide_windows in frame_create_move_resize_args casue X to generate extra VisibilityNotify events to clients during capture and redecoration (bug #3977). The hide windows are emtpy windows (with a None background pixmap). I introduced them to reduce flickering of the window decorations when a window is resized, and - more important - shaded or unshaded. The problem is that when you resize a window, you can tell X which border its subwindows should stick to. But you can not tell it where the subwindows of subwindows should go, and it's not possible to resize subwindows in the same operation. Because of this, I use the hide windows to cover some parts of the decorations, resize the window, redraw the the changed parts of the decorations windows (using a background pixmap, not using the foreground), then unmap the hide windows to uncover the changed decorations. Usually, the hide windows stay invisible because htey have no contents and just show what was below them until they are covered by something else. Now I understand the need for them for resize operations. Would it be possible to narrow down the need for that function call to some specific case? I don't see any way but at the expense of flickering decorations and subwindows, especially with opaque resizing. Am I right if I say that the hide windows do no good if it is a setup request and the frame size has not changed? I'm not sure how the initial mapping is treated, but I believe they do no good for that either. It's just a little harder to seed that condition from withing the function. Actually, if applications like xdvi have a below par redraw algorithm (i.e. they redraw whenexer they receive an Expose event), that's the applications' problem and not the problem of the window manager. It's true that the application may be behaving badly, but there are several application that show similar flickering due to the exrtra events on a redecoration. if it's possible to work around the events with the window mannager it's a good thing to do, but not at the expense of some other functionality. Just for reference the thing that annoys me most about this is the fact that my titleless pager and xbuffy flash whenever I redecorate (including even disable an already disabled title bar button) I just checked it and the pager flashing is caused by some other thing, and probably will have to be taken care of wfrom within the pager code. /Viktor
What are the hide windows in frame.c?
When are the hide windows useful in frame.c? The call to frame_reparent_hide_windows in frame_create_move_resize_args casue X to generate extra VisibilityNotify events to clients during capture and redecoration (bug #3977). Would it be possible to narrow down the need for that function call to some specific case? /Viktor
Re: Inconsistency during resizing shaded windows
On Sat, 15 Apr 2006, Mikhael Goikhman wrote: On 14 Apr 2006 19:32:16 +0200, Viktor Griph wrote: On Fri, 14 Apr 2006, Serge (gentoosiast) Koksharov wrote: 2) If this problem can't be solved without much hassle I think we should make it clear in documentation that ResizeOpaque style don't applies to shaded windows. I like it the way it is. I'm really not interested in the content of shaded windows. Vote for a change of documentaion Yes. possible together with an option to the WindowShade command to use the last shade direction. Ok, but adding this feature (storing the last shade direction per window) is not urgent. A user may implement this using custom functions. I believe, but haven't checked it up, that the shading direction isn't overwritten when unshading a window, so it would really just be some option to use whatever value already in there. Possible with addition to make sure that the default value for windows that haven't been shaded before make sence. /Viktor
Re: Inconsistency during resizing shaded windows
On Fri, 14 Apr 2006, Serge (gentoosiast) Koksharov wrote: Hi, Yesterday I've noticed little inconsistency during resizing shaded windows under fvwm 2.5.16 and current CVS version: I have in my ~/.fvwm/config `Style * ResizeOpaque'. But during resizing of any shaded window this style ignored and window resized as rubberband outline. I propose two possible solutions: 1) Solve this inconsistency. Maybe unshade the window before resizing, resize it, then shade it again. You can actually do this yourself, given that you don't use different shading directions. Just define your own resize function: AddToFunc ResizeFunc + I ThisWindow (Shaded) WindowShade off + I Resize + I TestRc (Match) WindowShade on 2) If this problem can't be solved without much hassle I think we should make it clear in documentation that ResizeOpaque style don't applies to shaded windows. I like it the way it is. I'm really not interested in the content of shaded windows. Vote for a change of documentaion, possible together with an option to the WindowShade command to use the last shade direction. /Viktor
Re: On my recent commits.
On Sat, 15 Apr 2006, Serge (gentoosiast) Koksharov wrote: On Thu, Apr 13, 2006 at 05:56:52PM +0200, Viktor Griph wrote: * should the options be allowed in any order. Now Reverse has to precede UseStack. If I understood your changes correctly, UseStack and Reverse options are not directly related to each other. In this case I think they should be allowed in any order. If I'm wrong, leave it as is, but please make a note about order in the `fvwm' manpage. The options are not depending on each other. However the reason for the current order requirement was that it was easier to write up in the man page. All [Reverse] [UseStack] [(Conditions)] command implies an order. To allow any order requires some more generic means of documenting the options. Something like All [options] [(Conditions)] command and then state the possible values for options. /Viktor
Re: style matching in current CVS
On Thu, 6 Apr 2006, Dominik Vogt wrote: On Thu, Apr 06, 2006 at 11:13:03AM +0200, Dominik Vogt wrote: First, this code from style.c generates a warning: if (SID_GET_HAS_NAME(s_id) (fw-style_name == NULL (matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) == TRUE || matchWildcards(SID_GET_NAME(s_id), fw-class.res_name) == TRUE || matchWildcards(SID_GET_NAME(s_id), fw-name.name) == TRUE)) || matchWildcards(SID_GET_NAME(s_id), fw-style_name ) == TRUE) { return True; } style.c: In function `fw_match_style_id': style.c:176: warning: suggest parentheses around within || Second, the code may access a NULL pointer style_name if neither of the first three matchWildcards is true. I just noticed this warning and logic error myself and were about to change it. Also, I think even if style_name is not NULL, the usual style name matching should be done: You are probably right. It was just that you said it should use it instead of the normal matching. However, that probably only creates a lot of more problems than anything else, so I think that the way you changed it to is good. I have updated the manpage to reflect the change. Just some conciderations: The manpage states that styles are search for in a specific order. I really fail to see how this information is useful while examining the logic, other than for the face that matchig early will save some comparitions. Am I missing something? if (SID_GET_HAS_NAME(s_id)) { if (matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) == TRUE) { return True; } if (matchWildcards(SID_GET_NAME(s_id), fw-class.res_name) == TRUE) { return True; } if (matchWildcards(SID_GET_NAME(s_id), fw-name.name) == TRUE) { return True; } if (fw-style_name == NULL matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) == TRUE) { return True; } } (Note that multi-line conditions with mixed and || operators are hard to read. If you happen to edit such a condition, please split it into separate conditions.) I see your point and will do that in the future. It should prevent errors as the one above. (I have committed this code to CVS, but feel free to change it). I've committed a copy-paste-error fix (you never compared with style_name). /Viktor
Re: style matching in current CVS
On Thu, 6 Apr 2006, Dominik Vogt wrote: On Thu, Apr 06, 2006 at 11:42:17AM +0200, Viktor Griph wrote: Just some conciderations: The manpage states that styles are search for in a specific order. I really fail to see how this information is useful while examining the logic, other than for the face that matchig early will save some comparitions. Am I missing something? Do you mean this text: They are searched in the reverse order stated. When two conflicting styles apply to the same window, the style that was changed last wins. I've always thought the first sentece They are searched in the reverse order stated. referre back to the order given in the previous statement, i.e I've read stated as stated here. Now that you say it it is fullt pssible, and probably makes more sence to interpet it as some sort of double information the the second sentence you quoted. This just means that style lines issued later override earlier styles. The text is confusing, though. I've committed a copy-paste-error fix (you never compared with style_name). :-P By the way, the function fw_match_style_id wasn't mentioned in your original ChangeLog entry. Please try to always mention *all* changed functions. This simplifies code maintenance enormously. I thougt I did that. I must have overwritten the changelog entry for fw_match_style_id with some subsequent addition to an alrady open changelog witout reverting to a recently saved one. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
Re: XResources and styles
On Sat, 25 Mar 2006, Dominik Vogt wrote: On Fri, Mar 24, 2006 at 06:32:18PM +0100, Viktor Griph wrote: Hi, does it exist any standard regulating the use of XResources? The reason I ask is that I recently found out that fvwm honors the resources Desk, Page and fvwmscreen for initial window positioning, and I find them quite neat to use together with apps supporting the -xrm option. I think that it would be good with a way to specify a style with resources in a similar way. The idea was that under AddWindow, before lookup_styles, add a resource lookup for some resource, say fvwmstyle, and if present map it to a WindowStyle command with rhe resource value as the style. All in all it comes down to two questions: Would adding such a resource break any standard? I don't think so. Good. Then I think it's ok as long as the resource starts with fvwm. and Is the feature described above something that should be added to fvwm? I think it's a good idea, but I wouldn't export the style syntax to the X resources. Instead, it should just add the style name to use for the application, i.e. (wahtever the correct syntax is). -xrm fvwmstyle: foobar The correct syntax for that would be -xrm *fvwmstyle:foobar. would tell fvwm to use the style foobar for the application (instead of the application name). This way, the whole configuration is still in the config file and there is no need to allocate styles dynamically (which is slow and potentially buggy). Sounds good, still if all you want is SkipMapping in addition to some default styles for the application, and want that for several different applications, that can result in many styles. However I belive that this way will be better with fvwm 3, so I'll give a try to implement it. I alrady have a draft implementaton[1] of my earlier suggested behaviour that I did while waiting for a reply. Implementing the suggested functionality will require an addition to the window structure. That also raise the question if a provided style name should be used for anything but style lookups, and if these should be any other ways, but resources, to set the provided style name. While this can be decided later, it's good to think of it aleady. One possiblity would be a SetStyle command that changes the style name used by a window. /Viktor [1] http://www.dd.chalmers.se/~griph/style_resource.diff
XResources and styles
Hi, does it exist any standard regulating the use of XResources? The reason I ask is that I recently found out that fvwm honors the resources Desk, Page and fvwmscreen for initial window positioning, and I find them quite neat to use together with apps supporting the -xrm option. I think that it would be good with a way to specify a style with resources in a similar way. The idea was that under AddWindow, before lookup_styles, add a resource lookup for some resource, say fvwmstyle, and if present map it to a WindowStyle command with rhe resource value as the style. All in all it comes down to two questions: Would adding such a resource break any standard? and Is the feature described above something that should be added to fvwm? /Viktor
Re: Compile error - latest cvs
On Tue, 21 Mar 2006, Alex Wallis wrote: Just updated my cvs version to the latest and get this error [...] Fixed. I accidently broke C90-compability (mixed declarations with statements) when doing warnings for unconsumed parts of style options. /Viktor
Re: Menu Title patch
On Wed, 15 Feb 2006, Dominik Vogt wrote: On Wed, Feb 15, 2006 at 09:25:11AM +0100, Viktor Griph wrote: On Wed, 15 Feb 2006, Dominik Vogt wrote: On Tue, Feb 14, 2006 at 07:27:55PM +0100, Viktor Griph wrote: On Thu, 9 Feb 2006, Dominik Vogt wrote: I have applied the patch with some changes and bugfixes: * The text of the menuitem is always drawn in the given colour set (this required a bugfix in the text drawing library). I don't think this should be done if no colorset is specified for the title. In that case I belive it should use the color of the normal items, or old configs using other color than black will get a black title color. That's exactly what I said (or maybe wanted to say). Currently: * No TitleColorset given - normal item colours are used. * TitleColorset given - foreground of cs is used. * TitleColorset and HilightTitleBack given - foreground and background of cs ase used. In that case it's not working, because I don't have a TitleColorset, and my menu title is black, while the rest of the items are khaki. Works perfectly for me. Can you post an example config that shows the problem? Just the following is ennough: Colorset 0 fg khaki,bg rgb:dd/00/00 MenuStyle * MenuColorset 0 /Viktor
Re: Comments
On Wed, 15 Feb 2006, Bert 'theBlackDragon' Geens wrote: On 2/14/06, Viktor Griph [EMAIL PROTECTED] wrote: (and the emacs mode does not deal with that either ;))) I don't know if you're using my emacs mode or the old one that's floating about the web, but I've fixed mine so it only higlights start of line comments. I'm not sure if it's allowed to have those preceded by spaces though, so if somebody could tell me that I'd be very grateful. Comments are allowed to be preceded by spaces. The mode I'm talking about is this one btw: http://www.lair.be/projects_fvwm-mode.php If you would know of a better or more up to date one, please do tell me as I haven't manage to find any (only a very old one that I didn't really like). I've actually been using a havily modified version [1] of that old mode, but I tested your mode before stating that the emacs mode didn't hilight comments correctly (to be on the safe side ;)). I've not posted it before since you posted your mode inbetween my start of adopting it for 2.5 and it being in somewhat working mode. Also I hadn't done anything in emacs lisp prior to that, so it's not very well written (and it's possible to follow my own evolving in the knowledge of emacs lisp by looking through how the coding style evolves in that file.) It only has support for config files, and not FvwmScript. It also can be a little slow sometimes since it's designed to be context sensitive for where keywords can be, and I really don't know the best way to optimize emacs lisp. (My brother asked me to do it for the reason that he always mixed up some keywords.) The reason why I stick to this mode and don't move over to your is probably that I have quite a fast machine, so I don't notice slowdowns in the fontlocking, and more importantly: Your mode does not font-lock comments spanning multiple lines (with escaped newlines), which makes commenting out long commands highlight strangely. The reason why I've never noticed that comments should be at start of commands is that I, normally always use it that way. It were just in a quick test I decided to try to disable the trail of a style command, and figured it didn't work. /Viktor [1] http://www.dd.chalmers.se/~griph/fvwm-mode.el.gz
Re: Menu Title patch
On Thu, 9 Feb 2006, Dominik Vogt wrote: I have applied the patch with some changes and bugfixes: * The text of the menuitem is always drawn in the given colour set (this required a bugfix in the text drawing library). I don't think this should be done if no colorset is specified for the title. In that case I belive it should use the color of the normal items, or old configs using other color than black will get a black title color. /Viktor
Re: fvwm hangs with xine (PR#3828)
Full_Name: Version: 2.5.14,2.5.16 CVS_Date: OS: linux X_Server: xorg 6.8.2 Submission from: (NULL) (213.247.189.13) This occurs, when I launch xine (xine-ui-0.99.3), choose settings-Setup...-audio, select speaker arrangement combobox and try to scroll it. After that fvwm stops to respond to any events, using 100% of processor time and occupying more and more memory. This is probably a bug with xine-ui, and the way it forces the combo box windows to stay in place. It doesn't seem to take the border added by fvwm in account. A workaround is to do 'Style Xitk Combo !Borders'. I'm not sure if anything can be done in fvwm to avoid the race condition.
Adding a Shift command
Seeing that there has only been one new command in the last 2.5 years I think it was time to add another. ;) I think that a parameter shifting command for use in functions could be useful. It could be used for small recursive (yes I know, that would not be very efficient) function calls: AddToFunc Inline + I $0 + I Shift + I Inline $* A sample call of the above would be Function Inline WindowStyle !Title, !Borders, !Handles UpdateStyles \ Maximize 100 100 Break Appart from that it would also provide meanns to get direct access to positional paramiters after $9. Thoughts? Is this something that anyone but me would use? /Viktor
EdgeScroll and pixel steps
Currently EdgeScroll divides pixel steps1000 by 1000 and enables wrap. I belive this to be a bug (and is reportd as sush (#3162)). However, it is useful to allow for warps when using pixel steps as well, so just removing that ability is no good solution. One possible solution would be to add another way of specifying wraps to the syntax, and make it the required method for pixel sizes (or change the check with pixels so that the size has to be larger than the screen width, and an even multiplicand of 1000, in order for division to take place (for compability with configs using for example EdgeScroll 1024000p 768000p)). I can think of several possible syntaxes, and can't decide on which one is best. One can either add a prefix (or another suffix) option 'w' to the individual coordinates. (w1024p or (1024pw or 1024wp)), or one can add optional keywords to the EdgeScroll syntax after the step parameters. (i.e. EdgeScroll 1024p 768p wrap|wrapx|wrapy) /Viktor
Re: fvwm starts when other window manager is already activeOrganization:
On Thu, 22 Sep 2005, Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian BTS has a record of your input] This was reported by a Debian user. Recent versions of fvwm, while being able to detect other versions of fvwm currently running: -- __ fvwm [FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running, try -replace -- are unable to detect other window managers.(Tested with ratpoison and woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm, making this almost every other window manager other than fvwm itself). Older versions of fvwm used to display this warning: -- [FVWM][CatchRedirectError]: ERROR another WM is running -- But the newer ones do not, for reasons I could not debug. This is a regression, and the other window managers are able to detect fvwm and refuse to run. Please see http://bugs.debian.org/328621 for details. manoj I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. /Viktor
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, 28 Jan 2006, Bernhard R. Link wrote: * Viktor Griph [EMAIL PROTECTED] [060128 14:36]: I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. I'm seeing the bug here with the Debian sarge version of XFree86 namely 4.3.0.dfsg.1-14sarge1. I do not know if it contain any patches taken from Xorg, though. Hochachtungsvoll, Bernhard R. Link Well, I really don't know about that. thinking about it the only x-server I'm certain it has worked with is a version of Xsun on solaris 2.8. Looking at the fvwm code I believe it might be that an XSync has been changed to an XFlush in the startup code before changing the errorhandler from the one that traps running WMs to the normal fvwm error handler. But since I'm not sure exactly how this WM-trapping is supposed to work I leave to someone else to decide if changing it back to XSync is correct. /Viktor
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, 28 Jan 2006, Dominik Vogt wrote: On Sat, Jan 28, 2006 at 02:20:13PM +0100, Viktor Griph wrote: On Thu, 22 Sep 2005, Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian BTS has a record of your input] This was reported by a Debian user. Recent versions of fvwm, while being able to detect other versions of fvwm currently running: -- __ fvwm [FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running, try -replace -- are unable to detect other window managers.(Tested with ratpoison and woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm, making this almost every other window manager other than fvwm itself). Older versions of fvwm used to display this warning: -- [FVWM][CatchRedirectError]: ERROR another WM is running -- But the newer ones do not, for reasons I could not debug. This is a regression, and the other window managers are able to detect fvwm and refuse to run. Please see http://bugs.debian.org/328621 for details. manoj I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. No, the only change since at least 2.3.0 was introducing the -replace option. We haven't touched this code in *ages*. Have you not? $ cvs log -r1.290 -N fvwm.c revision 1.290 date: 2002/03/17 17:34:15; author: domivogt; state: Exp; lines: +7 -10 * Replaced Xsync with XFlush almost everywhere. Note: it's rarely necessary to use XSync. XFlush usually suffices and is faster. * More work on frame layout. * Some general clean up. The relevant part of the cvs diff -r 1.289 -r 1.290 fvwm.c: Index: fvwm.c === RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v retrieving revision 1.289 retrieving revision 1.290 diff -u -r1.289 -r1.290 --- fvwm.c 15 Mar 2002 17:02:25 - 1.289 +++ fvwm.c 17 Mar 2002 17:34:15 - 1.290 @@ -557,21 +559,21 @@ CWEventMask | CWOverrideRedirect | CWColormap | CWBackPixmap | CWBorderPixel, attributes); XMapWindow(dpy, Scr.NoFocusWin); - SetMWM_INFO(Scr.NoFocusWin); FOCUS_SET(Scr.NoFocusWin); - XSync(dpy, 0); + frame_init(); + XFlush(dpy); if(debugging) { sync_server(1); } - SetupICCCM2 (replace_wm); + SetupICCCM2(replace_wm); XSetErrorHandler(CatchRedirectError); XSetIOErrorHandler(CatchFatal); XSelectInput(dpy, Scr.Root, XEVMASK_ROOTW); - XSync(dpy, 0); + XFlush(dpy); XSetErrorHandler(FvwmErrorHandler); I think that last XSync really should be there since, if I understand the test correctly it relies on an error to be generated if a window manager already exists, and XSync does wait until all requests are processed, and the errors handled, but XFlush just flushes the output buffer. I guess it's up to the threadin model of the X-server weather or not any errors generated by recently flushed requests are handled before or after the request to change error handler to FvwmErrorHandler is processed. /Viktor
Re: make rpm-dist and deb-dist both fail with the same error
On Mon, 16 Jan 2006, Alex Wallis wrote: I just updated my cvs sources (did a fresh checkout to be sure) and I keep getting an error with both make rpm-dist and make deb-dist as follows. Making all in FvwmTabs make[5]: Entering directory `/usr/src/rpm/BUILD/fvwm-2.5.16/modules/FvwmTabs' make[5]: *** No rule to make target `FvwmTabs.pod', needed by `FvwmTabs.1'. Stop. make[5]: Leaving directory `/usr/src/rpm/BUILD/fvwm-2.5.16/modules/FvwmTabs' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/src/rpm/BUILD/fvwm-2.5.16/modules' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/rpm/BUILD/fvwm-2.5.16' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/rpm/BUILD/fvwm-2.5.16' error: Bad exit status from /var/tmp/rpm-tmp.34739 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.34739 (%build) make[1]: Leaving directory `/home/awol/work/cvs/fvwm/rpm' awol-dev:/home/awol/work/cvs/fvwm# I get almost exactly the same error for both rpm-dist and deb-dist It's probably an oversight. Alex It seems as the same error is shiped with the 2.5.15 tarballs. It seems as if modules/FvwmTabs/Makefile.am concider the final manpage as a part of the distrubution, rather than the pod-file. When making make tries to rebuild the manpage from the pod, but the pod is missing. I don't have enough knowledge on automake to know what changes are needed, so somone else will have to fix it. /Viktor
Re: EWMH Window Types
I've spent some time learning the way fvwm wors with styles, and looked into how to implement the EwmhWindowTypeStyle command I suggested. There are at least two possible ways to do it: One is to make use of the style list, and add a window type field to the style id. That would require the ewmh_window_type value to be set before lookup_styles is called, which would make the style EWMHIgnoreWindowType hard to implement. However, the window tye stiles would be applied before other styles, and thus easy to override, so the ignore style wouldn't really be needed. On the other hand the styles would be in risk of accidental overriding by any Style * command in the user config. Another way is to keep the window type styles in a separate array, and apply them at a fixed time, as done now. That would keep the window type settings applied late, and the need for the EWMHIgnoreWindowType style would stay. I'm in favor of the first one, as it's more configurable, but I'd like some more input. /Viktor
Re: TrianglesUseFore patch.
On Mon, 21 Nov 2005, Malcolm Still wrote: Hello again, I've now patched against the CVS version. Again I've uploaded it to my webspace: http://rv.sdf-eu.org/CVSTrianglesUseFore.patch With the old patch I'd also found that it didn't paint with the foreground colour when using TrianglesRelief, so I modified the patch to do that. I've also patched menustyle_copy() to copy the TrianglesUseFore value to a new menustyle, which it didn't do before. As requested you can use !TrianglesUseFore to negate the option. I've also patched the manpage, AUTHORS, and NEWS to reflect the new option. Hope thats all fine. I've applied your patch, with lines shortened to less than 80 characters. If you write another patch in the future you should not use more than 79 columns. Also when responding to this list you should write the reply after the quoted text. /Viktor
matlab steals focus
I've encounted a strange, and undesired, behaviour with matlab 7.x (maybe eralier versions too), and I've tried all fvwm options available and I still can't get it to work right. My conclution is that matlab must break some rule. I write this in hope that someone knows of a way to go around that behaviour. Now to a description of the problem: I always run matlab in a terminal (-nodesktop), and I want that terminal to stay focused, even If you issue a command like figure(1). The problem is that, despite that I have FocusStyle * !GrabFocus, OverrideGrabFocus, !FocusByProgram in my config, matlap gives the focus to figure 1 if I isseu the command. If a figure already is active it will focus and raise. Otherwise it will start up focused. Even if I do 'Style Figure * NeverFocus' the figure will be focused on the command figure(1) (or when clicking on the window (but I use EnterToFocus, !LeaveToUnfocus, and not ClickToFocus, so it's matlab doing that focusing too). I tried to look at the focus code myself to see if there was anything I could do to force matlab not to focus it's figures on itself, but wasn't able to make out how the code worked. I did however find that when starting matlab with -nojvm it does not steal the focus at all. However I sometimes need the jvm, so it's not a good solution. I need some help by someone who know the specification, and more of the X-protocol than I do. I have two major questions: 1. Is it possible to make fvwm not allow the said focus change to happen? 2. Is matlab breaking any standard (and in that case what), and do you think it's worth submitting a bug report to MathWorks about it? /Viktor
Re: matlab steals focus
On Sat, 3 Dec 2005, Tavis Ormandy wrote: On Sat, Dec 03, 2005 at 11:28:47PM +0100, Viktor Griph wrote: I've encounted a strange, and undesired, behaviour with matlab 7.x (maybe eralier versions too), and I've tried all fvwm options available and I still can't get it to work right. My conclution is that matlab must break some rule. I write this in hope that someone knows of a way to go around that behaviour. I've had a similar problem with a different proprietary application, it used XSetInputFocus() whenever it wanted my attention, very annoying :) If this is what it's doing, afaik there is no way around it. I solved it with a preload library, for example, try this: $ cat libmatlab.c #include X11/Xlib.h int XSetInputFocus(Display *d, Window w, int i, Time t) { return 0;} $ gcc -shared -fPIC libmatlab.c -o libmatlab.so $ LD_PRELOAD=`pwd`/libmatlab.so matlab -nodesktop If it works, you could create a wrapper script to set LD_PRELOAD before starting matlab (dont have matlab here to test). Hope this helps, Tavis. Thank you! It works perfectly. Of course it would be best not to have to do rappers, so I would still want to know what standard matlab breaks. (I guess it's ICCCM, but if anyone that knows more precise where matlab does wrong it would hale me write a good bug report. /Viktor
Re: matlab steals focus
On Sun, 4 Dec 2005, Dominik Vogt wrote: On Sat, Dec 03, 2005 at 11:28:47PM +0100, Viktor Griph wrote: I've encounted a strange, and undesired, behaviour with matlab 7.x (maybe eralier versions too), and I've tried all fvwm options available and I still can't get it to work right. My conclution is that matlab must break some rule. I write this in hope that someone knows of a way to go around that behaviour. Now to a description of the problem: I always run matlab in a terminal (-nodesktop), and I want that terminal to stay focused, even If you issue a command like figure(1). The problem is that, despite that I have FocusStyle * !GrabFocus, OverrideGrabFocus, !FocusByProgram in my config, matlap gives the focus to figure 1 if I isseu the command. If a figure already is active it will focus and raise. Otherwise it will start up focused. Even if I do 'Style Figure * NeverFocus' the figure will be focused on the command figure(1) (or when clicking on the window (but I use EnterToFocus, !LeaveToUnfocus, and not ClickToFocus, so it's matlab doing that focusing too). I tried to look at the focus code myself to see if there was anything I could do to force matlab not to focus it's figures on itself, but wasn't able to make out how the code worked. I did however find that when starting matlab with -nojvm it does not steal the focus at all. However I sometimes need the jvm, so it's not a good solution. I need some help by someone who know the specification, and more of the X-protocol than I do. I have two major questions: 1. Is it possible to make fvwm not allow the said focus change to happen? No. Every application can set the focus to any window or subwindow at any time. The window manager is not involved in this process at all. All the fvwm styles affect only applications that try to cooperate with the window manager by honouring the ICCCM2 rules. 2. Is matlab breaking any standard (and in that case what), and do you think it's worth submitting a bug report to MathWorks about it? That depends on what type of focus policy matlab requests. Use FvwmIdent on the matlab window. If the focus policy says locally active or globally active, matlab is allowed to do that. If it says passive or no input matlab is breaking the ICCCM2 rules. It says Passive. I've never seen a company fixing a bug reported by someone from the open source community, so I doubt filing a report would be useful. I had the idea that if I report it to the helpdesk at my university, and have them report it further it will be reported from a large customer of them and it would be in their interest to fix it. But you might be right that they won't care about it. Thanks for your reply. /Viktor
Re: resizing windows with root-transparent titles
On Sat, 26 Nov 2005, Dominik Vogt wrote: On Sat, Nov 26, 2005 at 09:35:16PM +0100, Viktor Griph wrote: It seems as if resizing of windows with root transparent titles doesn't update the title. It will consist of the old pixmap, with the title text on the same position as before, posible tiled, if the window grew. Anyone that can give me a hint on where to start looking for the error? I've no idea where to look (Olivier wrote that code), but it works for me. Do you have a minimal config to show your problem? Colorset 1 RootTransparent TitleStyle Colorset 1 Style * ResizeOpaque To reproduce then resize the window, and keep it focused all the time. It's best noticed if you have a small window and resize it to more double size or more. During the resizing the title will be updateing, but when it's complete it will change to the previous title tiled. Once the window is unfocused the title is restored. /Viktor
EWMH Window Types
The way fvwm handles the _NET_WM_WINDOW_TYPE hint is very non-configurable currently. You can't even set other style options on the windows yourself. There are several ways to improve this. In short term a style EWMHIgnoreWindowType would allow for users to set their own style on windows having a specific windowtype without being foced to also have the default options of that window type. While this is an easy-to-make solution, I think there is room for more improvment. It would be good with configurable styles on a window type level, also for the window types currently ignored by fvwm. A command EWMHWindowTypeStyle could be added, and when the Style command is changed according to the 3.0 todo Type could be made a option to match on. I already got an implementation of the EWMHIgnoreWindowType which is ready for commit if agreed that such a style woud be useful (there might be other better solutions to the problem). I'd like to take a look at the implementation of an EWMHWindowTypeStyle command once I get a little more spare time. /Viktor
Re: MenuStyle
On Thu, 20 Oct 2005, Dominik Vogt wrote: On Thu, Oct 20, 2005 at 07:42:36AM +0200, Viktor Griph wrote: Hi I am looking into the MenuStyle code trying to understand how some things are done. I plan to enable negation of all on/off menu styles by prefixing ! to them. However looking at the code raise some questions: First of all what exactly does FreeColors free up? In certain modes, X colours are managed in so called colour cells. There may be a limited number of available cells. They are reserved with XAllocColor and freed with XFreeColor. Because colours are used in many places inside fvwm (colour sets!), fvwm keeps a reference counter for the allocated colours. The corresponding code may be a bit difficult to understand (libs/PictureUtils.c). FreeColors eventually decreases the reference counters and frees the cells if the reference count drops to 0. Actually the process is more complicated. I think Olivier has written most of the code. Answering this might answe some of my other questions; at least if it has some special functionality. Second: The styles HilightBack and ActiveFore do free the colors if the style have them. Howver the corresponding off-styles does not free them. Is there any reason for this? No, it's a bug. Both must free these colours also. Note that nobody ever actually tested the code to free colours. I'm sure fvwm still has many colour leaks. Last: This can't be right can it?: -- from menustyle.c: menustyle_copy /* HilightBack */ if (ST_HAS_ACTIVE_BACK(destms)) { FreeColors(ST_MENU_ACTIVE_COLORS(destms).back, 1, True); } ST_HAS_ACTIVE_BACK(destms) = ST_HAS_ACTIVE_BACK(origms); memcpy(ST_MENU_ACTIVE_COLORS(destms), ST_MENU_ACTIVE_COLORS(origms), sizeof(ColorPair)); ST_DO_HILIGHT_BACK(destms) = ST_DO_HILIGHT_BACK(origms); /* ActiveFore */ if (ST_HAS_ACTIVE_FORE(destms)) { FreeColors(ST_MENU_ACTIVE_COLORS(destms).fore, 1, True); } -- It looks to me as it frees the active fore color after having it copied over, thus freeing the source's color instead of the overwritten. Yes, without checking what the ST_MENU_ACTIVE_COLORS actually are, I think you're right. Furthermore I think the colour reference counts have to be increased when a menustyle is copied. Consider this: * Menustyle A has a colour x with reference count 1. * Copy menustyle A to some other menustyle B. x still has a reference count of 1. * Copy A over b again. The reference count of x is decreased to 0 and never increased again. Ouch. We should have a CopyColor function somewhere in PictureUtils.c that takes care of this situation, e.g. CopyColor( sometype* dest_color, sometype* src_color, int do_free_dest_color); (where do_free_dest_color indicates whether the destination colour should be freed). I found Pixel fvwmlib_clone_color(Pixel p) in ColorUtils.c which can be used to reallocate a color. With that creating a CopyColor function is no problem. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
Re: CVS griph: reimplemented previous fix without breaking escape
On Mon, 17 Oct 2005, Dominik Vogt wrote: On Sun, Oct 16, 2005 at 04:45:39PM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 05/10/16 16:45:39 Modified files: . : ChangeLog fvwm : move_resize.c Log message: reimplemented previous fix without breaking escape Yes, that fix is fine. Note that you can not just overwrite members of an XEvent structure that do not match the event type - you will inadvertedly overwrite members of the real event. What you thought to be a random mouse button was really the keycode of the KeyPress event. Sorry about that. I realized what was wrong the moment you reverted the patch. I had tested it, but not with escape. Strangely other keyboard controls still seemed to work. /Viktor
Re: ManualPlacement/Move Patch
On Thu, 1 Sep 2005, Mikhael Goikhman wrote: On 01 Sep 2005 07:10:25 +0200, Viktor Griph wrote: On Wed, 31 Aug 2005, Mikhael Goikhman wrote: On 31 Aug 2005 21:42:20 +, Mikhael Goikhman wrote: This is not enough, To emulate the current logic you should also add: Mouse 1 P N CancelPlacement Mouse 2 P N CancelPlacement I.e. if you started the Move using button 1, then button 2 cancels it and vice versa. Since you can't press button 1 again while dragging using button 1, these binding would be ok although not immediately intuitive. Well, actually these will not be ok if the Move is started on mouse click (not drag) or on key press. So either we conclude your idea can't work or we may try to somehow save it using, say, this extension: Mouse 0 P N PlaceWindow Mouse 1 P(d0) N CancelPlacement Mouse 2 P(d0) N CancelPlacement Mouse 1 P(d1) N PlaceWindow Mouse 2 P(d2) N PlaceWindow Mouse 2 P(c) N CancelPlacement Where dN means dragging using button N and c means mouse click or key press. No, I am not a big fan of such idea, but I am not against either. (I think the current logic about Move cancelation is good.) I've not changed the logic for dragging of windows. IT's only the interactive movment that my patch affects. I maybe should make that more clear in the manual page. I did see no need to try to change the drag logic, as all feeling on how it should work matches with how it currently does. I.e you hold down the button the drag started with and calcel the movement by pressing any other button. Well, this is not exactly what happens now. If you drag using mouse button 1 or 2, then button 3 places the window, rather than cancels. I suppose Dominik intentionally did it to allow PlacedByButton3 using dragging too. Yes, you are right. I missed that while rewriting the logic. It shouldn't be that hard to handle. If you want to be able to use some buttons for placing the window evenif it is being dragged it could probably be conficured by also changing PlaceWindow to always place the window and add PlaceWindowInteractive and PlaceWindowDrag as well as CancelPlacementDrag/CancelPlacementInteractive, and maybe also add CancelPlacement for completness, even if it would be the same as -. However, I think that just would comlicate things. But if you think it would be better to be able to define that you want to be able to place a window you are dragging by clicking on another button as well I can try to add that. You see, this is not enough. There should be at least the special notion of the same button that started the drag. The bindings quoted above should be implemented in one or another way (either configurable or hard-coded). I see no reason to ever want to have the button that started the drag to cancel a move. (And it would require new tests in the ButtonRelease even handling to implement) What seems to be the spimplest to solution is to hardcode (actually not handle specially) that if you release the button the move started with the window is placed - regardless of whatever bindings you have set up for Pressing the button during the move. Then I would only need for one more binding action. And possible some deactivating actions. The only thing that would have to be defined, in one way or another, is buttons pressable without movement cancelation while dragging. That together with buttons that can be used to place interactivly moved windows also defins buttons canceling movement. Mouse 0 P N PlaceWindow Mouse 1 P N CancelPlacementDrag Mouse 2 P N CancelPlacement Would then match the current default Suggested allowed Actuiions would be PlaceWindow / PlaceWindowInteractive / PlaceWindowDrag CancelPlacement / CancelPlacementInteractive / CancelPlacementDrag With - being equvalint of CancelPlacement PlaceWindow equvalent of PlaceWindowInteractive and PlaceWindowDrag with the CancelPlacement counterparts. If you see any case where that wouldn't be enough (given that the check is for button press and not release, and you can't press a button being held). I am not sure the flexibility you want to add is either needed or easy to implement (if possible at all). It is like to allow a user to create a new menu feel (key and mouse bindings) using a configuration. The menu code is messy and there are many actions and special cases already without configurable bindings. I don't know whether users want or have the ability to replace the placement feel with some usable alternative. Can you partition the exact current feel into configurable commands and estimate the work needed to implement this? Something along lines: Key Return P A PlaceWindow Key Space P A PlaceWindow Key Escape P A CancelPlacement Key Right P A MoveWindow +10p 0 Key Right P S MoveWindow +100p 0 Key Right P C MoveWindow +1p 0 Key AltP C ToggleSnapAttraction # well, this is a modifier, not a key If you show this is possible, then we may think to add a half-hardcoded command like
Move question
I'm working on a patch to allow windows to be placed with buttons 3. However, I run into some strangeness with the way Move is supposed to work according to the Man page, compared to what it actually does: The man page states that Move can be canceled with MB2. This is currently only true if Emulate is set to MWM. In other case MB2 places the window, and does nothing more (unless when __move is called from placement.c where it will continue with a resize operation). With Emulate not MWM the only way to cancel a non-drag-move with the mose is any button 3, which won't be possible with the patch I'm writing either. So, to come to the question: How should non-drag-movment be aborted by mouse? I also have two code-related questions: 1. Is there a way to see if a FvwmWindow never have been placed? (i.e to know if the return True for resize has any meaning) 2. What is the reason for windows dropped by button 1 to not fall over to button release, as windows dropped by button three. I know that not doing so allows to keep moving the window until you release the button, but why different behaviour for different buttons? /Viktor
ManualPlacement/Move Patch
This is the ManualPlacement/Move patch I'm currently working on. Right now I've done as mush as possible without knowing how placments are intended to be aborted. This patch makes placement of windows using any button possible. The button used to place the window is stored, and can be checked for with the new window condition PlacedByButton. Left to be done is to add a way to cancel placment with the mouse. One thing that has come to my mind is the allow some sort of mouse binding (ala the tearoff button for menus) Or another configure command that controls which buttons are valid for placing, and which that cancel placment. Jsut doing it by button numbers, ignoring any modifiers wouldn't be that hard. But I'm open to suggestions here. /Viktor placement_button.patch.gz Description: GNU Zip compressed data
New Test conditions: EdgeHasPointer and EdgeIsActive
I needed a way to tell waether the pointer is on an edge or not, and since non of the current conditionals were able to do that I wrote my own. I also included an EdgeIsActive since I thought that could be useful too, and they were to have similar syntax. Both are conditions to the Test command, and both take one direction argument. The direction argument can be any major direction or Any if no argument is given Any is assumed. EdgeHasPoiner is true if the pointer is over the pan frame specified by direction, and EdgeIsActive is true if the panframe in the given direction is mapped. /Viktor Index: AUTHORS === RCS file: /home/cvs/fvwm/fvwm/AUTHORS,v retrieving revision 1.103 diff -u -r1.103 AUTHORS --- AUTHORS 29 Jun 2005 17:15:18 - 1.103 +++ AUTHORS 12 Aug 2005 22:33:30 - @@ -4,6 +4,7 @@ Viktor Griph: Patch for Perl modules on 64 bit machines. +EdgeHasPointer and EdgeIsActive test conditions. Bjoern Steinbrink: Patch for FvwmScript tasks running too often. Index: ChangeLog === RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v retrieving revision 1.2612 diff -u -r1.2612 ChangeLog --- ChangeLog 12 Aug 2005 15:50:38 - 1.2612 +++ ChangeLog 12 Aug 2005 22:33:32 - @@ -1,3 +1,9 @@ +2005-08-13 Viktor Griph [EMAIL PROTECTED] + + * fvwm/conditional.c (CMD_Test): + * fvwm/fvwm.1.in: + added test conditions EdgeHasPointer and EdgeIsActive + 2005-08-12 Dominik Vogt [EMAIL PROTECTED] * fvwm/virtual.c (raisePanFrames): Index: NEWS === RCS file: /home/cvs/fvwm/fvwm/NEWS,v retrieving revision 1.565 diff -u -r1.565 NEWS --- NEWS12 Aug 2005 16:12:54 - 1.565 +++ NEWS12 Aug 2005 22:33:32 - @@ -8,7 +8,8 @@ * New features: - Fvwm now officially supports 64-bit architertures. - - New Test conditions IsEnvSet and MatchEnv. + - New Test conditions IsEnvSet, MatchEnv, EdgeHasPointer + and EdgeIsActive.. * New module features: Index: fvwm/conditional.c === RCS file: /home/cvs/fvwm/fvwm/fvwm/conditional.c,v retrieving revision 1.105 diff -u -r1.105 conditional.c --- fvwm/conditional.c 12 Aug 2005 11:39:58 - 1.105 +++ fvwm/conditional.c 12 Aug 2005 22:33:32 - @@ -47,6 +47,7 @@ #include stack.h #include commands.h #include decorations.h +#include virtual.h /* local definitions -- */ @@ -1913,6 +1914,113 @@ error = 1; } } + else if (StrEquals(cond, EdgeIsActive)) + { + direction_t dir= DIR_NONE; + char *dirname; + char *next; + next = GetNextSimpleOption(flags_ptr, dirname); + if (dirname) + { + dir = gravity_parse_dir_argument(dirname, + NULL, DIR_NONE); + if (dir == DIR_NONE) + { + if (!StrEquals(dirname, Any)) + { + next = flags_ptr; + } + } + else if (dir DIR_MAJOR_MASK) + { + error = 1; + } + free(dirname); + } + + if (!error) + { + if (((dir == DIR_W || dir == DIR_NONE) + Scr.PanFrameLeft.isMapped) || + ((dir == DIR_N || dir == DIR_NONE) + Scr.PanFrameTop.isMapped) || + ((dir == DIR_S || dir == DIR_NONE) + Scr.PanFrameBottom.isMapped) || + ((dir == DIR_E || dir == DIR_NONE) + Scr.PanFrameRight.isMapped)) + { + match = 1; + } + else + { + match = 0; + } + } + flags_ptr = next; + } + else if (StrEquals(cond, EdgeHasPointer