Hi Dominik, > The only problem I see is how > predictable program behaviour is. Does the patch re-grab window > bindings when the name/class/resource of the window changes? If > so, it may be a performance hog, if not, it may confuse the user. > I don't see a good way to handle both problems at the same time.
The patch handles windows that dynamically change name/class/resource. I just wrote a small Perl/Tk app to change the window name at the click of a button ($mw->configure(-title => ...)) to confirm this. As for performance, it should be pretty good. Looking up a window-specific binding should take about the same amount of time, but looking up a global binding will be (on average) about twice as long. This is because in CheckBinding() we search the whole binding list in the hope of finding a window-specific binding. Previously, when searching the binding list we would stop as soon as we found a matching binding (as we do now for window-specific bindings). Anyway, only bean-counters will be unhappy with the performance change. (I tried to make it as efficient as possible.) As for confusing the user - yes I agree. Most apps won't change their class/resource name, however, & a decent wildcard pattern for window names should avoid most problems. > - The reference to regular expressions is wrong. Wildcard > matching in fvwm has nothing to do with regular expressions Ah yes. Well spotted. > - I'd rather see the four name strings put into a structure (to > reduce the number arguments passed to the functions). A good idea. A shame the XClassHint structure only holds the class & resource names. "four name string" - I thought only 3? > - Is there a specific reason why the patch handles only key > bindings? It should be trivial to extend it to handle mouse and > stroke bindings too. I've always said the patch supports both key & mouse bindings. (The fvwm man page gives an example of how to use both.) I've never used stroke bindings - I'll have a look. SCoTT. :) -- [EMAIL PROTECTED] -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
