In article <[EMAIL PROTECTED]>, matthiasm <[EMAIL PROTECTED]> wrote:
> There was an issue that this would not work on OS X and for a while, > users could open a menu and then drag the *main* window while the menu > window was still hovering lonely in its original position. Now, I know > I fixed that issue a while ago, but I really can not remeber how I did > that... . I remember that issue. There was another one, very similar, were you could receive click events even on the OSX's title bar which was breaking some of my GL programs (for example when one attempted to drag the window away). I also remember an issue about non-modal windows stealing focus from each-other. There was some extensive rewrite of the OSX code involved which fixed a bunch of these problems, and for some weeks everyone was happy ;). Ironically, when grab(1) is used in this bug report, I can see the click-on-title-bar event claiming his victory. I think we share the opinion that grab(1) should do what the documentation says: send all events to the target window until turned off. This is necessary evil needed almost exclusively for popup handling (and tooltips I guess). Tooltips not turning off correctly make me mad. I will see if I can find anything... I have just a question to the main developers. What about adding some kind of test-case repository in the svn for 1.1.x? I do not mean anything fancy: just simple STR cases with "click-here" "shoult-not-see-mee" immediate instructions that one could simply run blindly in a batch to validate the library. A fltk-config/make based directory and tests: "make" to build, "make check" to run the lot. Just for developers with svn access. I see the same bugs popping again and again. I suspect there are "bugs" listed as "fixed in 1.1.8" that were never present in 1.1.7. I could start by putting there the STRs I've fixed so far. What do you think? _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
