On Sat, 06 Sep 2014 15:14:01 +0200
Albrecht Schlosser wrote:

> >> So, the question is: can you change your design to change all widgets
> >> before "painting"?
> >
> > Not really, as the dummy widget handling is all inside a RenderTheme.
> > All functions in there are called during painting only.
> >
> > It would require some deeper hackery to accomplish that, involving
> > files outside the specific platform/ directory (ie: common files
> > outside the port).
> 
> Thanks for the explanation, although I still don't get it. I thought 
> "upstream" is webkit, and you are developing WebkitFLTK, so how can FLTK 
> widgets and their handling be in "upstream" software? Is it done somehow 
> like a callback system, in a plugin, and/or with derived classes? Still 
> curious.

A build-time switch decides which port is used, and port files live
under platform/port_name. Most are primary classes (for which only a
header exists under the generic dirs). Most of the classes are
allocated in a singleton way before main(), which isn't really a good
place to create widgets either.

Binding FLTK widget creation to some unrelated object would be
confusing, and adding a new call for such would require changes in the
generic parts.

> Okay, now you got me. I still feel a little uneasy with adding these 
> methods, since I don't know what side effects they would have if used in 
> the wrong way. As with set/clear_visible() we should carefully document 
> when to use these shortcuts, when not to use them, and what the negative 
> (maybe incorrect focus handling) and positive (better performance) 
> effects would be.
> 
> Question: what would happen if the current focus widget would be 
> deactivated with this special method and eventually be destroyed. Could 
> it be that FLTK would access a deleted widget? Do we have to check this? 
> I ask because we had another issue where a user called flush on a window 
> that was not yet shown, and FLTK crashed (STR #3028).

If the widget had focus, deactivating it wouldn't cause FLTK to access
it after deletion. It would only receive events while greyed out, which
would certainly be confusing to the user, but this API misuse would be
corrected as soon as the user focused some other widget.

The widget destructor checks for each case individually, so it doesn't
matter that a focused widget is inactive in that sense.

- Lauri

-- 
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.