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?
> > 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 axecute the action.
> > 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?
> > 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.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
