Fabien Costantini wrote: > Al wrote: >> That's what I wrote about before. You need specialized state variables >> to track all changes. This is beyond the scope of a toolkit like FLTK. > Many examples (see my previous posts) will not need any state variables
Please don't cite me without enough context. I didn't mean your (Fabien's) examples with this. I meant _his_ problem, where he described that he had problems with knowing, what had happened _before_ another event. >>> Regarding FL_WHEN_CHANGED. I was attempting to mimic the way the mouse >>> works, with this button attribute, using short cuts. I thought that the >>> intention of FL_WHEN_CHANGED was to allow a user to push and hold a button >>> to start an action which then stops when they released the button. This is >>> different from a normal or toggle button which would require the >> user to push/release a button to initiate an action then push/release >> the button to stop the action. >> >> You can do this. Derive your own class, handle() the push event, > > Sorry, but now I really have to disagree with this : are you seriously > suggesting that as an acceptable workaround for not having good semantics ? No. Not as a workaround. Not for "not having good semantics". If you would have cited (read) a little more, you would have seen, that this concerned the "continued action" John wrote about. I wanted to point out, that his complete problem is more than could be achieved with the simple widget callback mechanism (and with any modification that we can do with FLTK). Please read again: he wrote about four buttons that can be pressed simultaneously, and the "continued action" (key repetition)... > I guess what I would like to emphasis here is that we would not need in many > situations (many examples have been introduced in this thread) to use > inheritance for such a simple thing. > What is so hard to accept Al in what was explained ? Obviously we're talking about different things ;-). Nothing is hard to accept, but you should also try to understand my point. Okay, to make it clear: I don't object to making useful additions to the event handling mechanism. But trying to catch interactions between mouse push/release and keyboard push/release in conjunction with FL_KEYUP events... Well, I have my doubts, and that's what I wrote. > I don't understand why you're not enthusiastic about finally giving the > correct meaning to a so important event that is FL_WHEN_CHANGED, there are > almost only advantages to the proposed changes, and simplifications. I do fully agree, if we can achieve "the correct meaning". However, I don't know what the correct meaning is yet. And if we change too much in the behavior, we'll get backwards compatibility problems with users who relied on the old semantics [OT: remember the discussions with Greg, who pointed out that, although it is bad to have the scrollbars as child widgets, he wanted to keep them for users of old software that rely on this mis-behavior. We do still have to find a solution for this.../OT] > Frankly, I doubt it would be so hard to achieve and, after all, this is our > problem, not fltk users problem. If it is provided that life would be simpler > for fltk users and semantics more clear and simple, then it is my belief that > we should make it simple even if it's a hell for core developers. I saw the original patch, and how "complicated" this was (lots of if's, and's and or's). And I could see that it wouldn't work in all cases and that it was incomplete (as far as I could see). And I know about the difficulties with FL_KEYUP events. But if you can do it, go ahead. And if you do, please add a Fl_Input widget to the test program and test with the focus in the Fl_Input, so that you need to use ALT-X etc.. I wrote about my concerns, and that I think that it is not that easy. Give me a proof of the contrary (write a patch, or do it in a branch so that we can review it), and I'll be glad if it works. :-) Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
