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