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 +0000, 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 cut&paste > 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 FvwmProxy now superset anything ion-like > FvwmPartition would have contributed, so partitioning is > an abandoned curious experiment.
-- 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. 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 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. 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. Hm, and how does FvwmProxy handle desks? Should it be aware of the StickyAcrossDesks style? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
