On 2008-10-14, Albrecht Schlosser <[EMAIL PROTECTED]> wrote:
> Jane wrote:
>> On 2008-10-12, Albrecht Schlosser <[EMAIL PROTECTED]> wrote:
>>> jane wrote:
>>>
>>>> oh, this looks pretty easy, just draw and handle? well,
>>>> makes sense, draw something and then handle events on it.
>>> Your question was, where to start ... ;-)
>>>
>>> Of course you would also need member variables to save the values and
>>> the appropriate get and set methods, but that should be obvious.
>>>
>>>> do i need damage too? or is that on a lower level?
>>> No, not really. Damage can be used to improve drawing, to minimize areas
>>> that need to be redrawn, but you can also let the default FLTK handling
>>> draw everything when needed. After you change something, calling
>>> redraw() should be enough.
>>>
>>> I propose using Fl_Double_Window, because then there won't be any
>>> visible flickering, but you could also use damage() and
>>> {push_|pop_}clip() to reduce flickering, if you want to use a normal
>>> Fl_Window. Otherwise, if your widget becomes big (and I assume that
>>> would be necessary to hit the correct keys with the mouse), then
>>> flickering could become a problem with normal Fl_Windows. But you can
>>> decide this later, you don't need it for starting.
>>>
>>> Albrecht
>>
>> man, this is great. thank you.
>> it is kinda like opengl programming. :) it took me a
>> little time to get things right and the way i wanted them
>> to be but i am quite happy with it now. fltk is great! ")
>
> I'm glad that we could help you.
>
>> i am not 100% sure when to return 1 and when to return 0 in
>> my handle function.
>
> The easy rule (but you know that): if you don't use it, return 0,
> otherwise return 1.
>
>> eg, should i return 1 for an
>> FL_MOUSEWHEEL event, even if i dont use that event for any
>> control? because i wonder if i don't, where is the event
>> going to?
>
> That's the more difficult part. FLTK "tries really hard not to loose any
> event" (cited without looking at the docs, may be different). That means
> that unused (mouse and keyboard) events are delivered "bottom up" from
> the Fl::belowmouse() and Fl::focus() widget, resp. to the parent
> group(s) and then again "top down" to other widgets in these groups,
> maybe even to competely unrelated "sister" groups.
>
> That said, if your widget is a child of an Fl_Scroll group, then the
> Fl_Scroll would get the event and do, what the user would expect. But if
> not, the FL_MOUSEWHEEL event could end up in another unrelated group,
> maybe annoying for the user. You can sometimes see such unexpected
> behavior in browsers with embedded scroll boxes and a page that is
> bigger than the window. But your widget can't "know" if it is a child of
> a scroll group, thus it depends on your application and needs.
>
> Another example: FL_KEYUP events. Almost no widget uses keyup events,
> and therefore they can fly around and may eventually be delivered to
> every widget in the window. I decided to return 1 on FL_KEYUP events in
> one of my input widgets, if this widget is the Fl::focus() widget,
> because the probability is high that this widget used the FL_KEYDOWN
> evetn before. This reduced the (IMHO) useless FL_KEYUP event propagation
> to unrelated widgets in _my_ application. YMMV.
>
> And one more: if a user clicks the mouse on an object, but this object
> is inactive (at that moment), what should happen? IMHO, the object
> should return 1 on the click event (I got it and "used" it, but did
> _nothing_ with it), which is better (because it would be expected by the
> user) than asking all other widgets, if they want to use this particular
> click event. But that may depend, too...
>
> Albrecht
thanks for this explaination. :)
heres my current ui with the piano widget. i am so lucky
that i know fltk :D
my current ui with piano:
http://img45498.pictiger.com/images/17117939/
jan
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
