Re: Tracking flag changes from modules
Dominik Vogt wrote: On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. As a possibility for 3.0, could the module interface be reworked perhaps more extensively? I had an idea for an ICE-based module interface that would, if well done, be more flexible and extensible than the current system. (It's biggest change would be that modules would no longer need to be children of the fvwm process.) It could solve this problem by defining a query-flag operation, with an upward-compatible way of specifying flags. FVWM already links libICE (session management uses it), so this wouldn't add much to the size of the running process. Is the time right to start discussing major changes for 3.0, or should I hold this a while longer?
Re: Tracking flag changes from modules
On 8/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: Dominik Vogt wrote: On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. As a possibility for 3.0, could the module interface be reworked perhaps more extensively? I had an idea for an ICE-based module interface that would, if well done, be more flexible and extensible than the current system. (It's biggest change would be that modules would no longer need to be children of the fvwm process.) It could solve this problem by defining a query-flag operation, with an upward-compatible way of specifying flags. FVWM already links libICE (session management uses it), so this wouldn't add much to the size of the running process. Is the time right to start discussing major changes for 3.0, or should I hold this a while longer? This may not be the right time to start the final discussion, but I guess no one will complain about us spaming the fvwm mailing list :P As for this discussion, IMHO the best thing to do first is to abstract ourselves from the actual communication method. We first define an interface over a generic bidirectional stream, then we can implement it over any kind of mechanisms. Being it pipes, ICE, DBUS, dynamic loaded libraries, TCP/IP. If we manage to work out a good abstract interface, it wouldn't be hard to implement it using ICE.. Cheers Renato
Re: Tracking flag changes from modules
seventh guardian wrote: On 8/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: As a possibility for 3.0, could the module interface be reworked perhaps more extensively? I had an idea for an ICE-based module interface that would, if well done, be more flexible and extensible than the current system. (It's biggest change would be that modules would no longer need to be children of the fvwm process.) It could solve this problem by defining a query-flag operation, with an upward-compatible way of specifying flags. FVWM already links libICE (session management uses it), so this wouldn't add much to the size of the running process. Is the time right to start discussing major changes for 3.0, or should I hold this a while longer? This may not be the right time to start the final discussion, but I guess no one will complain about us spaming the fvwm mailing list :P As for this discussion, IMHO the best thing to do first is to abstract ourselves from the actual communication method. We first define an interface over a generic bidirectional stream, then we can implement it over any kind of mechanisms. Being it pipes, ICE, DBUS, dynamic loaded libraries, TCP/IP. If we manage to work out a good abstract interface, it wouldn't be hard to implement it using ICE.. I was thinking of using the ICE opcodes in a meaningful manner. A packet-oriented interface, rather than a pure stream, in other words. Since ICE should be available on any system where fvwm is in use, why worry about other mechanisms? (Or am I wrong here?) ICE can use TCP/IP as its transport, so using ICE would give us network transparency if we want it. Dynamic linking into fvwm would mean that a poorly written module could crash fvwm, but it shouldn't be too hard to construct a dynamic shell module that loads an .so and then uses the ICE interface to communicate with fvwm. (Why anyone would want this is another matter.) A similar shell could provide backwards compatibility for older modules. A DBUS interface could be implemented in a similar manner, if a reasonable way to represent fvwm's state to DBUS is devised. This could actually be used in an even more general manner--interface modules could be written for KDE's DCOP and whatever GNOME uses as well. Using ICE would allow us to have one interface in fvwm proper and then have other interfaces atop that one in modules that can be started by the programs that need them. Also, ICE is intended for use underneath an app-layer library. This could help with maintaining the module interface code if we put it in such a library. ICE's protocol is similar to X's, which might also help maintainability. To sum up, ICE presents a (almost) ready-made command-response interface--all we do is define the opcodes and implement the ends. And, if session-management is compiled in, libICE is already in use for that, so we can remove the module interface's transport from fvwm's code and use libICE. Is there something so wrong with ICE that working from scratch rather than using it to abstract the transport is a good idea?
Re: Tracking flag changes from modules
On Wed, Aug 09, 2006 at 12:07:40AM +0200, Viktor Griph wrote: [snip] But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. I'm afraid there is more to the issue than just that. The issue remains, that if, for instance, the style FixedPosition is changed no updated config info is sent to the module, so the flag would get outdated. Of course. Nobody said it would be this easy :-) You have to set the flag flags-do_update_modules_flags in check_window_style_change() (styles.c) to 1. The module message will then be sent. Also, thinking about it: Aren't the pager window movements seen by fvwm as application induced movements since toy use X rather than the fvwm Move builtin? Yes, you're right. This isn't optimal since the action is clearly triggered by the user, not an application. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Tracking flag changes from modules
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. 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. Cheers Renato
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
Re: Tracking flag changes from modules
On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: 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. It would be easy to uniquely identify the modules if the alias' were managed by fvwm instead of the modules. This way fvwm would know which specific module was listening on which pipe. As a (positive) side effect, modules wouldn't need to know their alias, which in turn would make the message requesting/parsing easyer. I've already suggested this, but it was said to be too complicated to be worth implementing before 2.6.. Things that needed to change: -Change of the module interface code in fvwm. -Add a command/style to specify the module alias in the config file. - VISIBLE (new feature) -Minor changes to the module's config parsing code. -The module's parsing cmd line options (now reject the alias options). - VISIBLE (could break backward-compatibility) As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes
Re: Tracking flag changes from modules
On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: 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. It would be easy to uniquely identify the modules if the alias' were managed by fvwm instead of the modules. This way fvwm would know which specific module was listening on which pipe. As a (positive) side effect, modules wouldn't need to know their alias, which in turn would make the message requesting/parsing easyer. I've already suggested this, but it was said to be too complicated to be worth implementing before 2.6.. Things that needed to change: -Change of the module interface code in fvwm. -Add a command/style to specify the module alias in the config file. - VISIBLE (new feature) -Minor changes to the module's config parsing code. -The module's parsing cmd line options (now reject the alias options). - VISIBLE (could
Re: Tracking flag changes from modules
On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: 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. It would be easy to uniquely identify the modules if the alias' were managed by fvwm instead of the modules. This way fvwm would know which specific module was listening on which pipe. As a (positive) side effect, modules wouldn't need to know their alias, which in turn would make the message requesting/parsing easyer. I've already suggested this, but it was said to be too complicated to be worth implementing before 2.6.. Things that needed to change: -Change of the module interface code in fvwm. -Add a command/style to specify the module alias in the config file. - VISIBLE (new
Re: Tracking flag changes from modules
On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? The very first issue is that there is no defined way of choosing the alias. From what I see in the code, it was suposed to have the very first user argument as an alias (standard). Since some modules don't use (respect?) this, I guess the effort was undermined by the back-compat issues.. But this can be partially tackled if we add a command for the modules to request their alias in the fvwm internal data. Is it worth continuing the job? Is it safer to start an experimental side branch on this? Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs Cheers, Renato Ciao Dominik ^_^ ^_^ -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: Tracking flag changes from modules
On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs There's still one or two things that need fixing before I would deem 2.5.X as a release candidate. There's no rush. :) I'd much rather see it done proper than released; pampering to the possible cries of the users that so desperately want it. :) -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: Tracking flag changes from modules
On 8/8/06, Thomas Adam [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order Should they? I don't agree. The modules shouldn't have to deal with fvwm's internals. The module interface should be as clean as possible.. As Dominik said, it is a hack. for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs There's still one or two things that need fixing before I would deem 2.5.X as a release candidate. There's no rush. :) I'd much rather see it done proper than released; pampering to the possible cries of the users that so desperately want it. :) Anything that wouldn't require a rewrite/hack? Cheers Renato -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: Tracking flag changes from modules
On Tue, Aug 08, 2006 at 04:18:41PM +0100, seventh guardian wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? The very first issue is that there is no defined way of choosing the alias. From what I see in the code, it was suposed to have the very first user argument as an alias (standard). Since some modules don't use (respect?) this, I guess the effort was undermined by the back-compat issues.. But this can be partially tackled if we add a command for the modules to request their alias in the fvwm internal data. Is it worth continuing the job? Is it safer to start an experimental side branch on this? Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. No, it isn't. It has some areas that are hardly tested at all, and some features that can not be released in the current state (see the corresponding to-do file for details). After that we may change everything to our heart's desire (unless we want a 2.8 release before 3.0). It's definitely more stable than some other release programs Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Tracking flag changes from modules
On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs There's still one or two things that need fixing before I would deem 2.5.X as a release candidate. There's no rush. :) I'd much rather see it done proper than released; pampering to the possible cries of the users that so desperately want it. :) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Tracking flag changes from modules
On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. Elegant enough :) Viktor will you do it? Cheers Renato Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs There's still one or two things that need fixing before I would deem 2.5.X as a release candidate. There's no rush. :) I'd much rather see it done proper than released; pampering to the possible cries of the users that so desperately want it. :) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE2Nh3meSprTOr4tgRAhSYAKCtVnMulvIbWYgQDdaODNvDkH1lkACfRjuT EUZJPAB99lkRifhELOa88TI= =lp+7 -END PGP SIGNATURE-
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
Re: Tracking flag changes from modules
On Mon, Aug 07, 2006 at 07:26:40PM +0200, Viktor Griph wrote: On Mon, 7 Aug 2006, Dominik Vogt 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). I see that the flags are part of M_CONFIGURE_WINDOW. However, this package is not sent when styles that affect flags are changed, so the flags will be outdated until some other window operation that results in a new config message to be sent. Looking at is_function_allowed in decorations.c it seems as if the move action is goverened by the said flag and mwm hints. Would it be wrong to reimplement a check in the pager for if move is allowed? Yes, it would be wrong. To do so the pager would have to know the mwm functions hints and changes in styles would have to generate configure messages. I'm unhappy that the flags are sent at all. It's just a hack. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Tracking flag changes from modules
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? Cheers Renato Ciao Dominik ^_^ ^_^ -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
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
