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, 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. Pages are probably good for somebody, but they're not for me. > > Ciao > > Dominik ^_^ ^_^ > > -- > > Dominik Vogt > > >
