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 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
