Re: FvwmProxy keyboard handling
2009/3/24 Jason Weber baboon.im...@gmail.com: The left/top sensitivity has me suspecting something related to a negative pixel coordinate. Hmm, is there some relative encoding with negative numbers? If you are using the Move command, then yes. negative coordinates are distance from right/bottom. You may prefix any number with a plus to use the top left corner as reference always. /Viktor
Re: FvwmProxy keyboard handling
On Tue, Mar 17, 2009 at 7:56 AM, Jason Weber baboon.im...@gmail.com wrote: On Tue, Mar 17, 2009 at 2:01 AM, Dominik Vogt dominik.v...@gmx.de wrote: On Mon, Mar 16, 2009 at 11:36:33PM -0700, Jason Weber wrote: On Mon, Mar 16, 2009 at 3:34 PM, Dominik Vogt dominik.v...@gmx.de wrote: On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: [snip] 1. Key polling I'm not completely sure what the current code does. I assume the keyboard map is polled every time an event occurs. However, there may be a possibility that the keyboard map changed but no event occurs. Earlier versions polled at a regular interval, which was inacceptable. We have to test this: * Invoke FvwmProxy by pressing a modifier key and configure it to terminate when the key is released. * Don't touch the mouse from now and make sure that no events occur that effect FvwmProxy. * Open a menu with the keyboard; fvwm grabs the keyboard. Make sure that the menu window does not overlap any FvwmProxy windows. * Release the modifier key inside the menu. * Close the menu by pressing Escape. Now, does FvwmProxy close or not? If so, the current polling of the keyboard map works acceptably. Yes, at the very end. (no touching the mouse) Meta3-ESC: proxies up Meta3-M: custom menu with some window ops pops up (proxies still up) Release Meta3: nothing happens As expected while the keyboard is grabbed. ESC: proxies and menu disappear It's the same results whether or not the menu and proxies window are in contact. That's good, to make sure however, could you repeat that test but put an fprintf in Loop() that shows which events arrive after the menu is closed? FvwmProxy ProcessMessage M_STRING Hide Where did this come from? *FvwmProxy: Action ModifierRelease S3 SendToModule FvwmProxy Hide FvwmProxy ProcessMessage M_FOCUS_CHANGE Ah I see. We need to repeat this test in a way that focus is and remains on some unrelated window. Once the menu raises, the focus locks on whatever was focused at the time. It doesn't change until the menu drops. Can you print X events too? I do. I believe I only receive events to the proxy windows. There are a bunch of Expose event when they raise. The other events only happen when I play with the mouse on the proxy window. 2. Moving keyboard handling into the core Regardless, I don't want to have this code in a module. If it works, every module could benefit from it if we put it into the fvwm core. We can't rely on KeyRelease events, but the approach in FvwmProxy might work. SendCommand can be used to remote ^^^ SendToModule control FvwmProxy or any other modules. We need a final solution before the next stable release. If we don't find one, I'll either remove FvwmProxy or mark it as experimental and announce that its interface will be changed. So this means replacing XEvent ButtonPress/etc with an FvwmPacket, say M_BUTTON or M_POINTER? No, it's already possible to reliable trigger actions in the core when mouse events occur. We'd just need some notion of key release handling, e.g. Mouse F1 A SC SendToModule FvwmProxy do_what_i_want Whenever Shift-Control-F1 is pressed, fvwm would send the string do_what_i_want over the module pipe to the module in an M_STRING packet. Look at modules/FvwmButtons/FvwmButtons.c for an example. If it's better for the core code, I'll be happy to adapt. Maybe something like WaitForKeyReleased F1 Action Fvwm could keep a list of key and actions it's waiting to be released. Whenever an event arrives while the list is not empty, fvwm would query the keyboard map and check if any of the keys is not pressed at the moment. If so, it would remove the entry from the list and execute the action. It would also need to handle pure modifiers. We currently have: *FvwmProxy: Action ModifierRelease S3 SendToModule FvwmProxy Hide I don't know if key bindings are exclusive, but if not, something like KeyRelease * A 3 SendToModule FvwmProxy Hide But you know what I'm looking for, so I should be happy with whatever syntax is decided upon. Since we can't rely on noticing if a key is pressed and then released, I don't think we'll ever make KeyRelease bindings work reliably. That's why is suggested different semantics that just watches specific keys when told so. 3. Problems in window placement code The while (collision == true) in AdjustWindows() may loop forever. I haven't tried to generate this situation though. It also may shift proxy windows to the void outside the screen. We need a more reliable algorithm. I suppose a maxCollisions would be prudent. Off the screen issues, that I am aware of. In really deep, but vertically short, stacks of virtual tabs, that
Re: FvwmProxy keyboard handling
On Mon, Mar 16, 2009 at 3:34 PM, Dominik Vogt dominik.v...@gmx.de wrote: On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: [snip] 1. Key polling I'm not completely sure what the current code does. I assume the keyboard map is polled every time an event occurs. However, there may be a possibility that the keyboard map changed but no event occurs. Earlier versions polled at a regular interval, which was inacceptable. We have to test this: * Invoke FvwmProxy by pressing a modifier key and configure it to terminate when the key is released. * Don't touch the mouse from now and make sure that no events occur that effect FvwmProxy. * Open a menu with the keyboard; fvwm grabs the keyboard. Make sure that the menu window does not overlap any FvwmProxy windows. * Release the modifier key inside the menu. * Close the menu by pressing Escape. Now, does FvwmProxy close or not? If so, the current polling of the keyboard map works acceptably. Yes, at the very end. (no touching the mouse) Meta3-ESC: proxies up Meta3-M: custom menu with some window ops pops up (proxies still up) Release Meta3: nothing happens As expected while the keyboard is grabbed. ESC: proxies and menu disappear It's the same results whether or not the menu and proxies window are in contact. That's good, to make sure however, could you repeat that test but put an fprintf in Loop() that shows which events arrive after the menu is closed? FvwmProxy ProcessMessage M_STRING Hide FvwmProxy ProcessMessage M_FOCUS_CHANGE 2. Moving keyboard handling into the core Regardless, I don't want to have this code in a module. If it works, every module could benefit from it if we put it into the fvwm core. We can't rely on KeyRelease events, but the approach in FvwmProxy might work. SendCommand can be used to remote ^^^ SendToModule control FvwmProxy or any other modules. We need a final solution before the next stable release. If we don't find one, I'll either remove FvwmProxy or mark it as experimental and announce that its interface will be changed. So this means replacing XEvent ButtonPress/etc with an FvwmPacket, say M_BUTTON or M_POINTER? No, it's already possible to reliable trigger actions in the core when mouse events occur. We'd just need some notion of key release handling, e.g. Mouse F1 A SC SendToModule FvwmProxy do_what_i_want Whenever Shift-Control-F1 is pressed, fvwm would send the string do_what_i_want over the module pipe to the module in an M_STRING packet. Look at modules/FvwmButtons/FvwmButtons.c for an example. If it's better for the core code, I'll be happy to adapt. Maybe something like WaitForKeyReleased F1 Action Fvwm could keep a list of key and actions it's waiting to be released. Whenever an event arrives while the list is not empty, fvwm would query the keyboard map and check if any of the keys is not pressed at the moment. If so, it would remove the entry from the list and execute the action. It would also need to handle pure modifiers. We currently have: *FvwmProxy: Action ModifierRelease S3 SendToModule FvwmProxy Hide I don't know if key bindings are exclusive, but if not, something like KeyRelease * A 3 SendToModule FvwmProxy Hide But you know what I'm looking for, so I should be happy with whatever syntax is decided upon. 3. Problems in window placement code The while (collision == true) in AdjustWindows() may loop forever. I haven't tried to generate this situation though. It also may shift proxy windows to the void outside the screen. We need a more reliable algorithm. I suppose a maxCollisions would be prudent. Off the screen issues, that I am aware of. In really deep, but vertically short, stacks of virtual tabs, that does happen. I've been just rearranging windows. My #2 would help, but it could go a step further and actually push away from the edges. With such bounds, it is clearly possible that the collision check could be unable to reach False if you simply cram a huge number of windows on one desk. Well, yes. Any ideas for a more robust algorithm? Ideal gas? In any case, I would cap the procedure to stop at some point even it it means not everything is visible and without contact. I think that would be an extreme case even if I just did the #2 fix. Hm, and how does FvwmProxy handle desks? Should it be aware of the StickyAcrossDesks style? Sticky windows have proxies where ever the window would show up. I have my Circulate calls set to skip over them, but that's preference. FvwmProxy does honor WindowListSkip, meaning it presumes that you don't want proxies where you don't want something on a window list. I'm single page, multi desk (as I understand the terms), so I don't have a good grip on issues with scrolling desktops but if regular windows work,
Re: FvwmProxy keyboard handling
On Mon, Mar 16, 2009 at 3:40 PM, Thomas Adam thomas.ada...@gmail.com wrote: 2009/3/16 Dominik Vogt dominik.v...@gmx.de: On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: [snip] 1. Key polling I'm not completely sure what the current code does. I assume the keyboard map is polled every time an event occurs. However, there may be a possibility that the keyboard map changed but no event occurs. Earlier versions polled at a regular interval, which was inacceptable. We have to test this: * Invoke FvwmProxy by pressing a modifier key and configure it to terminate when the key is released. * Don't touch the mouse from now and make sure that no events occur that effect FvwmProxy. * Open a menu with the keyboard; fvwm grabs the keyboard. Make sure that the menu window does not overlap any FvwmProxy windows. * Release the modifier key inside the menu. * Close the menu by pressing Escape. Now, does FvwmProxy close or not? If so, the current polling of the keyboard map works acceptably. Yes, at the very end. (no touching the mouse) Meta3-ESC: proxies up Meta3-M: custom menu with some window ops pops up (proxies still up) Release Meta3: nothing happens As expected while the keyboard is grabbed. I've had problems with FvwmProxy; I don't configure anything, but bind the showtoggle option to a key. If I have two windows one stacked on the other and group them, if I then focus between them with FvwmProxy running (none of the proxy windows need to be visible, it's enough to just have Module FvwmProxy loaded), FVWM (I assume) get's in a continuous lopp constantly shifting focus between the two windows which are stacked. I wonder if this is due to the default behaviour of WIndowListFunc somehow? [...] -- Thomas Adam I would need more details. Do you have auto-raise or something else going on other than simply a focus event? -- Jason Weber
Re: FvwmProxy keyboard handling
On Mon, Mar 16, 2009 at 11:36:33PM -0700, Jason Weber wrote: On Mon, Mar 16, 2009 at 3:34 PM, Dominik Vogt dominik.v...@gmx.de wrote: On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: [snip] 1. Key polling I'm not completely sure what the current code does. I assume the keyboard map is polled every time an event occurs. However, there may be a possibility that the keyboard map changed but no event occurs. Earlier versions polled at a regular interval, which was inacceptable. We have to test this: * Invoke FvwmProxy by pressing a modifier key and configure it to terminate when the key is released. * Don't touch the mouse from now and make sure that no events occur that effect FvwmProxy. * Open a menu with the keyboard; fvwm grabs the keyboard. Make sure that the menu window does not overlap any FvwmProxy windows. * Release the modifier key inside the menu. * Close the menu by pressing Escape. Now, does FvwmProxy close or not? If so, the current polling of the keyboard map works acceptably. Yes, at the very end. (no touching the mouse) Meta3-ESC: proxies up Meta3-M: custom menu with some window ops pops up (proxies still up) Release Meta3: nothing happens As expected while the keyboard is grabbed. ESC: proxies and menu disappear It's the same results whether or not the menu and proxies window are in contact. That's good, to make sure however, could you repeat that test but put an fprintf in Loop() that shows which events arrive after the menu is closed? FvwmProxy ProcessMessage M_STRING Hide Where did this come from? FvwmProxy ProcessMessage M_FOCUS_CHANGE Ah I see. We need to repeat this test in a way that focus is and remains on some unrelated window. Can you print X events too? 2. Moving keyboard handling into the core Regardless, I don't want to have this code in a module. If it works, every module could benefit from it if we put it into the fvwm core. We can't rely on KeyRelease events, but the approach in FvwmProxy might work. SendCommand can be used to remote ^^^ SendToModule control FvwmProxy or any other modules. We need a final solution before the next stable release. If we don't find one, I'll either remove FvwmProxy or mark it as experimental and announce that its interface will be changed. So this means replacing XEvent ButtonPress/etc with an FvwmPacket, say M_BUTTON or M_POINTER? No, it's already possible to reliable trigger actions in the core when mouse events occur. We'd just need some notion of key release handling, e.g. Mouse F1 A SC SendToModule FvwmProxy do_what_i_want Whenever Shift-Control-F1 is pressed, fvwm would send the string do_what_i_want over the module pipe to the module in an M_STRING packet. Look at modules/FvwmButtons/FvwmButtons.c for an example. If it's better for the core code, I'll be happy to adapt. Maybe something like WaitForKeyReleased F1 Action Fvwm could keep a list of key and actions it's waiting to be released. Whenever an event arrives while the list is not empty, fvwm would query the keyboard map and check if any of the keys is not pressed at the moment. If so, it would remove the entry from the list and execute the action. It would also need to handle pure modifiers. We currently have: *FvwmProxy: Action ModifierRelease S3 SendToModule FvwmProxy Hide I don't know if key bindings are exclusive, but if not, something like KeyRelease* A 3 SendToModule FvwmProxy Hide But you know what I'm looking for, so I should be happy with whatever syntax is decided upon. Since we can't rely on noticing if a key is pressed and then released, I don't think we'll ever make KeyRelease bindings work reliably. That's why is suggested different semantics that just watches specific keys when told so. 3. Problems in window placement code The while (collision == true) in AdjustWindows() may loop forever. I haven't tried to generate this situation though. It also may shift proxy windows to the void outside the screen. We need a more reliable algorithm. I suppose a maxCollisions would be prudent. Off the screen issues, that I am aware of. In really deep, but vertically short, stacks of virtual tabs, that does happen. I've been just rearranging windows. My #2 would help, but it could go a step further and actually push away from the edges. With such bounds, it is clearly possible that the collision check could be unable to reach False if you simply cram a huge number of windows on one desk. Well, yes. Any ideas for a more robust algorithm? Ideal gas? In any case, I would cap the procedure to stop at some point even it it means not everything is visible and without contact. I think that would be an
Re: FvwmProxy keyboard handling
On Tue, Mar 17, 2009 at 2:01 AM, Dominik Vogt dominik.v...@gmx.de wrote: On Mon, Mar 16, 2009 at 11:36:33PM -0700, Jason Weber wrote: On Mon, Mar 16, 2009 at 3:34 PM, Dominik Vogt dominik.v...@gmx.de wrote: On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: [snip] 1. Key polling I'm not completely sure what the current code does. I assume the keyboard map is polled every time an event occurs. However, there may be a possibility that the keyboard map changed but no event occurs. Earlier versions polled at a regular interval, which was inacceptable. We have to test this: * Invoke FvwmProxy by pressing a modifier key and configure it to terminate when the key is released. * Don't touch the mouse from now and make sure that no events occur that effect FvwmProxy. * Open a menu with the keyboard; fvwm grabs the keyboard. Make sure that the menu window does not overlap any FvwmProxy windows. * Release the modifier key inside the menu. * Close the menu by pressing Escape. Now, does FvwmProxy close or not? If so, the current polling of the keyboard map works acceptably. Yes, at the very end. (no touching the mouse) Meta3-ESC: proxies up Meta3-M: custom menu with some window ops pops up (proxies still up) Release Meta3: nothing happens As expected while the keyboard is grabbed. ESC: proxies and menu disappear It's the same results whether or not the menu and proxies window are in contact. That's good, to make sure however, could you repeat that test but put an fprintf in Loop() that shows which events arrive after the menu is closed? FvwmProxy ProcessMessage M_STRING Hide Where did this come from? *FvwmProxy: Action ModifierRelease S3 SendToModule FvwmProxy Hide FvwmProxy ProcessMessage M_FOCUS_CHANGE Ah I see. We need to repeat this test in a way that focus is and remains on some unrelated window. Once the menu raises, the focus locks on whatever was focused at the time. It doesn't change until the menu drops. Can you print X events too? I do. I believe I only receive events to the proxy windows. There are a bunch of Expose event when they raise. The other events only happen when I play with the mouse on the proxy window. 2. Moving keyboard handling into the core Regardless, I don't want to have this code in a module. If it works, every module could benefit from it if we put it into the fvwm core. We can't rely on KeyRelease events, but the approach in FvwmProxy might work. SendCommand can be used to remote ^^^ SendToModule control FvwmProxy or any other modules. We need a final solution before the next stable release. If we don't find one, I'll either remove FvwmProxy or mark it as experimental and announce that its interface will be changed. So this means replacing XEvent ButtonPress/etc with an FvwmPacket, say M_BUTTON or M_POINTER? No, it's already possible to reliable trigger actions in the core when mouse events occur. We'd just need some notion of key release handling, e.g. Mouse F1 A SC SendToModule FvwmProxy do_what_i_want Whenever Shift-Control-F1 is pressed, fvwm would send the string do_what_i_want over the module pipe to the module in an M_STRING packet. Look at modules/FvwmButtons/FvwmButtons.c for an example. If it's better for the core code, I'll be happy to adapt. Maybe something like WaitForKeyReleased F1 Action Fvwm could keep a list of key and actions it's waiting to be released. Whenever an event arrives while the list is not empty, fvwm would query the keyboard map and check if any of the keys is not pressed at the moment. If so, it would remove the entry from the list and execute the action. It would also need to handle pure modifiers. We currently have: *FvwmProxy: Action ModifierRelease S3 SendToModule FvwmProxy Hide I don't know if key bindings are exclusive, but if not, something like KeyRelease * A 3 SendToModule FvwmProxy Hide But you know what I'm looking for, so I should be happy with whatever syntax is decided upon. Since we can't rely on noticing if a key is pressed and then released, I don't think we'll ever make KeyRelease bindings work reliably. That's why is suggested different semantics that just watches specific keys when told so. 3. Problems in window placement code The while (collision == true) in AdjustWindows() may loop forever. I haven't tried to generate this situation though. It also may shift proxy windows to the void outside the screen. We need a more reliable algorithm. I suppose a maxCollisions would be prudent. Off the screen issues, that I am aware of. In really deep, but vertically short, stacks of virtual tabs, that does happen. I've been just rearranging windows. My #2 would help, but it
Re: FvwmProxy keyboard handling
On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: [snip] 1. Key polling I'm not completely sure what the current code does. I assume the keyboard map is polled every time an event occurs. However, there may be a possibility that the keyboard map changed but no event occurs. Earlier versions polled at a regular interval, which was inacceptable. We have to test this: * Invoke FvwmProxy by pressing a modifier key and configure it to terminate when the key is released. * Don't touch the mouse from now and make sure that no events occur that effect FvwmProxy. * Open a menu with the keyboard; fvwm grabs the keyboard. Make sure that the menu window does not overlap any FvwmProxy windows. * Release the modifier key inside the menu. * Close the menu by pressing Escape. Now, does FvwmProxy close or not? If so, the current polling of the keyboard map works acceptably. Yes, at the very end. (no touching the mouse) Meta3-ESC: proxies up Meta3-M: custom menu with some window ops pops up (proxies still up) Release Meta3: nothing happens As expected while the keyboard is grabbed. ESC: proxies and menu disappear It's the same results whether or not the menu and proxies window are in contact. That's good, to make sure however, could you repeat that test but put an fprintf in Loop() that shows which events arrive after the menu is closed? 2. Moving keyboard handling into the core Regardless, I don't want to have this code in a module. If it works, every module could benefit from it if we put it into the fvwm core. We can't rely on KeyRelease events, but the approach in FvwmProxy might work. SendCommand can be used to remote ^^^ SendToModule control FvwmProxy or any other modules. We need a final solution before the next stable release. If we don't find one, I'll either remove FvwmProxy or mark it as experimental and announce that its interface will be changed. So this means replacing XEvent ButtonPress/etc with an FvwmPacket, say M_BUTTON or M_POINTER? No, it's already possible to reliable trigger actions in the core when mouse events occur. We'd just need some notion of key release handling, e.g. Mouse F1 A SC SendToModule FvwmProxy do_what_i_want Whenever Shift-Control-F1 is pressed, fvwm would send the string do_what_i_want over the module pipe to the module in an M_STRING packet. Look at modules/FvwmButtons/FvwmButtons.c for an example. If it's better for the core code, I'll be happy to adapt. Maybe something like WaitForKeyReleased F1 Action Fvwm could keep a list of key and actions it's waiting to be released. Whenever an event arrives while the list is not empty, fvwm would query the keyboard map and check if any of the keys is not pressed at the moment. If so, it would remove the entry from the list and axecute the action. 3. Problems in window placement code The while (collision == true) in AdjustWindows() may loop forever. I haven't tried to generate this situation though. It also may shift proxy windows to the void outside the screen. We need a more reliable algorithm. I suppose a maxCollisions would be prudent. Off the screen issues, that I am aware of. In really deep, but vertically short, stacks of virtual tabs, that does happen. I've been just rearranging windows. My #2 would help, but it could go a step further and actually push away from the edges. With such bounds, it is clearly possible that the collision check could be unable to reach False if you simply cram a huge number of windows on one desk. Well, yes. Any ideas for a more robust algorithm? Hm, and how does FvwmProxy handle desks? Should it be aware of the StickyAcrossDesks style? Sticky windows have proxies where ever the window would show up. I have my Circulate calls set to skip over them, but that's preference. FvwmProxy does honor WindowListSkip, meaning it presumes that you don't want proxies where you don't want something on a window list. I'm single page, multi desk (as I understand the terms), so I don't have a good grip on issues with scrolling desktops but if regular windows work, proxies should be fine. A desktop is a big area made of one or more pages e.g. 3x2. A page is always the size of the screen. The currently visible area of the screen is called the viewport and usually shows a complete page, but may be scrolled smoothly. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmProxy keyboard handling
2009/3/16 Dominik Vogt dominik.v...@gmx.de: On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: [snip] 1. Key polling I'm not completely sure what the current code does. I assume the keyboard map is polled every time an event occurs. However, there may be a possibility that the keyboard map changed but no event occurs. Earlier versions polled at a regular interval, which was inacceptable. We have to test this: * Invoke FvwmProxy by pressing a modifier key and configure it to terminate when the key is released. * Don't touch the mouse from now and make sure that no events occur that effect FvwmProxy. * Open a menu with the keyboard; fvwm grabs the keyboard. Make sure that the menu window does not overlap any FvwmProxy windows. * Release the modifier key inside the menu. * Close the menu by pressing Escape. Now, does FvwmProxy close or not? If so, the current polling of the keyboard map works acceptably. Yes, at the very end. (no touching the mouse) Meta3-ESC: proxies up Meta3-M: custom menu with some window ops pops up (proxies still up) Release Meta3: nothing happens As expected while the keyboard is grabbed. I've had problems with FvwmProxy; I don't configure anything, but bind the showtoggle option to a key. If I have two windows one stacked on the other and group them, if I then focus between them with FvwmProxy running (none of the proxy windows need to be visible, it's enough to just have Module FvwmProxy loaded), FVWM (I assume) get's in a continuous lopp constantly shifting focus between the two windows which are stacked. I wonder if this is due to the default behaviour of WIndowListFunc somehow? [...] -- Thomas Adam
FvwmProxy keyboard handling
I've moved this discussion to a separate thread. jpwe...@imonk.com wrote: On Sun, Mar 15, 2009 at 12:44:27AM +0100, Dominik Vogt wrote: On Sat, Mar 14, 2009 at 12:24:57PM -0700, jpwe...@imonk.com wrote: On Sat, Mar 14, 2009 at 12:15:03AM +0100, Dominik Vogt wrote: On Tue, Mar 10, 2009 at 10:34:38PM +, Mikhael Goikhman wrote: * FvwmProxy: unfinished and unmaintained Please send me the location of any feature requests or bug reports. Here's my list. 1. don't reorder others in group on raise 2. vertical centering of groups of proxies 3. SoftRaiseOff SoftDeskOff SoftDragOff Hard* likewise 4. option to only show proxy of active window No bugs I know, but 1 and 2 address suboptimal behavior. 3 is an idea for more detailed custom behavior. 4 is a request I saw on the list a while back. It's not something I would use, but it would probably be an easy add next time I visited the code. The issue of keyboard handling and/or grabbing is completely unresolved. The original version did keyboard polling, which is unacceptable. My attempts to make it listen to events never led to anything usable, so basically there is not clean way to invoke it the way it way meant to be invoked. You'll need to be more specific. From what I see, it is using FQueryPointer which is also in FvwmDragWell, FvwmIconMan, FvwmIdent, FvwmPager, FvwmTaskBar, FvwmWharf, and FvwmWinList. It calls this through a Loop function that is pretty much cutpaste from FvwmPager. And it doesn't require you to do this modifiers watch. You can use simply toggle proxies with explicit commands. If some non-xorg server is fussy, well, I'd hate to see all these capabilites effectively banned to console a few fringe users who may not otherwise get the full functionality. It seems FvwmPager and FvwmProxy are both spinning in Loop(). Does it really matter if I call FQueryPointer each time (when activated and proxies are visible)? It is immeasurable on the CPU, not even above any of 0% cpu processes I see in 'top'. I do get 1% for the single time step that I open the proxies, so I know it's there. And there's still the possibility of cpu lockups because of an infinite loop. We discussed both when we added FvwmProxy to cvs - they've been in the todo-2.6 for ages. I use SendFvwmPipe and SendText. So does every nearly other module, it seems. I 'send' resize and move commands, as some others do. It seems more appropriate than XMoveResizeWindow and the like, which many modules have. Perhaps no other module reacts to its own move commands, maybe, but I've been using this 14 hours a day for nearing a decade (less comment to follow) and I haven't had it freeze for at least a couple of years, as long as I can remember at least. Are these current bugs or reports that were never rechecked? I went to the fvwm bug tracking system and a regex on fvwmproxy came up one fixed bug about a man page. It very difficult to debug speculations. I haven't had a compelling need to fiddle with something that works, mostly. Honestly, who has read through the whole current man page, set this module up correctly, used it for a while, and NOT seen huge benefits? Of course this tool was tailored to my vision, but I see things like Expose and other alt-tab alternatives and am amazed that people live with such limited capabilites. It's like it gives me xray vision. Add on the window grouping, sticky edges, virtual tab bar, and this is half of why I even use fvwm. I *know*. FvwmProxy has realy potential to become a very helpful tool for many people (maybe except me, because I already have a solution for the same problem). Please share. If you've reached to next plateau, I'd love to come up and take a look. There are two bis problems that need to be solved first (see above). People at work say, 'wow, how do I get that' and I have to tell them it doesn't work with their KDE or gnome. All the existing fvwm users I've met are now using it. I had one fvwm convert for a while, for this purpose, but I guess fvwm is a programmer's WM. By default, it doesn't really do anything. I don't control the master rc files. You have to set it up. I've tried to put good examples in the man page. My point being, this is neither abandoned code or a curious experiment. It is heavily used by serious professionals. This module is not the focus of my work, by the productivity of all my other efforts hinges on this tool. I consider the availablilty of fvwm (and therein proxy) in making career decisions. I spent 18 months on a job a few years back with pure Win32 and you never get used to it once you know what real efficiency is like. It is a joke, a sad sad joke. FvwmPartition, in contrast, is an experiment and, as far I am concerned, the sticky edge and virtual tab capabilites of
Re: FvwmProxy keyboard handling
I've found the lists.math.uh.edu archive which is not the same as what is shown on the fvwm.org page. Apparently my emails did show up, but I haven't been receiving them at my gmail or my older account. Perhaps the fvwm.org contact page needs to be updated to get the proper archive and any other newer instructions. I cutpaste this prior mail off the archive. From Dominik Vogt dominik.v...@gmx.de Subject FvwmProxy keyboard handling Date Sun, 15 Mar 2009 12:50:47 +0100 [Part 1 text/plain us-ascii (7.0 kilobytes)] (View Text in a separate window) I've moved this discussion to a separate thread. jpwe...@imonk.com wrote: On Sun, Mar 15, 2009 at 12:44:27AM +0100, Dominik Vogt wrote: On Sat, Mar 14, 2009 at 12:24:57PM -0700, jpwe...@imonk.com wrote: On Sat, Mar 14, 2009 at 12:15:03AM +0100, Dominik Vogt wrote: On Tue, Mar 10, 2009 at 10:34:38PM +, Mikhael Goikhman wrote: * FvwmProxy: unfinished and unmaintained Please send me the location of any feature requests or bug reports. Here's my list. 1. don't reorder others in group on raise 2. vertical centering of groups of proxies 3. SoftRaiseOff SoftDeskOff SoftDragOff Hard* likewise 4. option to only show proxy of active window No bugs I know, but 1 and 2 address suboptimal behavior. 3 is an idea for more detailed custom behavior. 4 is a request I saw on the list a while back. It's not something I would use, but it would probably be an easy add next time I visited the code. The issue of keyboard handling and/or grabbing is completely unresolved. The original version did keyboard polling, which is unacceptable. My attempts to make it listen to events never led to anything usable, so basically there is not clean way to invoke it the way it way meant to be invoked. You'll need to be more specific. From what I see, it is using FQueryPointer which is also in FvwmDragWell, FvwmIconMan, FvwmIdent, FvwmPager, FvwmTaskBar, FvwmWharf, and FvwmWinList. It calls this through a Loop function that is pretty much cutpaste from FvwmPager. And it doesn't require you to do this modifiers watch. You can use simply toggle proxies with explicit commands. If some non-xorg server is fussy, well, I'd hate to see all these capabilites effectively banned to console a few fringe users who may not otherwise get the full functionality. It seems FvwmPager and FvwmProxy are both spinning in Loop(). Does it really matter if I call FQueryPointer each time (when activated and proxies are visible)? It is immeasurable on the CPU, not even above any of 0% cpu processes I see in 'top'. I do get 1% for the single time step that I open the proxies, so I know it's there. And there's still the possibility of cpu lockups because of an infinite loop. We discussed both when we added FvwmProxy to cvs - they've been in the todo-2.6 for ages. I use SendFvwmPipe and SendText. So does every nearly other module, it seems. I 'send' resize and move commands, as some others do. It seems more appropriate than XMoveResizeWindow and the like, which many modules have. Perhaps no other module reacts to its own move commands, maybe, but I've been using this 14 hours a day for nearing a decade (less comment to follow) and I haven't had it freeze for at least a couple of years, as long as I can remember at least. Are these current bugs or reports that were never rechecked? I went to the fvwm bug tracking system and a regex on fvwmproxy came up one fixed bug about a man page. It very difficult to debug speculations. I haven't had a compelling need to fiddle with something that works, mostly. Honestly, who has read through the whole current man page, set this module up correctly, used it for a while, and NOT seen huge benefits? Of course this tool was tailored to my vision, but I see things like Expose and other alt-tab alternatives and am amazed that people live with such limited capabilites. It's like it gives me xray vision. Add on the window grouping, sticky edges, virtual tab bar, and this is half of why I even use fvwm. I *know*. FvwmProxy has realy potential to become a very helpful tool for many people (maybe except me, because I already have a solution for the same problem). Please share. If you've reached to next plateau, I'd love to come up and take a look. There are two bis problems that need to be solved first (see above). People at work say, 'wow, how do I get that' and I have to tell them it doesn't work with their KDE or gnome. All the existing fvwm users I've met are now using it. I had one fvwm convert for a while, for this purpose, but I guess fvwm is a programmer's WM. By default, it doesn't really do anything. I don't control the master rc files. You have to set it up. I've tried
