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 cut&paste 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 +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. 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 ESC: proxies and menu disappear It's the same results whether or not the menu and proxies window are in contact. > 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. So this means replacing XEvent ButtonPress/etc with an FvwmPacket, say M_BUTTON or M_POINTER? If it's better for the core code, I'll be happy to adapt. > 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. > 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. > Ciao > > Dominik ^_^ ^_^ > > -- > > Dominik Vogt
