On Tue, Mar 17, 2009 at 7:56 AM, Jason Weber <baboon.im...@gmail.com> wrote: > 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. >> >> Dominik Vogt >>
For completeness, here's another little proxy-evident bug. I'm not sure if this is an issue the proxy code, fvwm core, or how I am configured. As an example, say I create two xterms and glue them side by side (same proxy group, not isolated). I can move either and the other follows. But suppose I move one so the top edge goes above the screen edge. The move command sent to the other window seems to wrap around so that it lands near the bottom. If I make minor movements, they move together in their new vertically displaced arrangement. If I slide the now vertically lower one so that the upper would rise partially above the screen boundary (or it is already above), they realign vertically to the original side-side arrangement. Similar things seem to happen on the left edge. Also, doing an immediate move-undo doesn't go back to the prior positions. With multiple windows, this can be quite a mess. Is there a reason that fvwm would be making some presumption about a 'better' place to move the window, or should I search the proxy code for some overrun or unsigned issue? The left/top sensitivity has me suspecting something related to a negative pixel coordinate. Hmm, is there some relative encoding with negative numbers? -- Jason Weber
