| |
| |
On 06.09.2014 09:35, Lauri Kasanen wrote:
On 31.08.2014 12:27, Albrecht Schlosser wrote:
> I'd like to be able to set the INACTIVE flag in a
> widget directly, without sending any events no matter what the previous
> state was (both activate() and deactivate() send events, call
> fl_fix_focus(), etc).
>
> WebkitFLTK needs to be able to change the draw state of dummy widgets
> to grayed out and back. Having events sent or focus messed with at that
> point is unnecessary,
What point is this? I can see that it may be unnecessary, but I'm curious...
The widgets in question are dummies, they will never receive focus or
events, never are interacted with. They are used purely for drawing.
Sending events to them is unnecessary work, which should be avoided
just on principle even if the overhead is small.
> but also causes asserts inside webkit (no events
> should happen during painting).
;-) Hmm, it's your software, so you could easily remove the asserts, if
they are "wrong" ;-)
Certainly, but deviating from upstream would make it harder to update.
I also assume the asserts are there for a reason, and if they did not
fire, something worse would happen.
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.
That said: I believe that sending FL_ACTIVATE and FL_DEACTIVATE,
together with calling fl_fix_focus, may currently be implemented - well,
let's say ... - suboptimal. Maybe we could fix this, so that we get less
events, but that wouldn't change the fact that events are sent to
widgets at all.
Yes, that wouldn't change the basic premise here.
I thought so.
> Many of the other flags have set() and clear() functions. Adding such
> for inactive would be ABI-safe, and if surrounded by /* for internal
> use only */ comments like some other Fl_Widget public functions,
> shouldn't confuse users.
I wrote already in the STR that I wouldn't want such a function, at
least not with a "standard" name that could easily be guessed (wrong, in
that case) and used w/o looking at the docs. We should strive to
_removing_ methods that are "for internal use only", instead of adding
more such methods. And, BTW, strictly spoken: the usage discussed here
would NOT be "internal use", since it is not used in the FLTK lib itself.
Yes, perhaps badly chosen words there.
Not having one is inconsistent though, and we have predecent of such
for-specific-use-only functions already:
/** Makes the widget visible.
You must still redraw the parent widget to see a change in the
window. Normally you want to use the show() method instead.
*/
void set_visible() {flags_ &= ~INVISIBLE;}
That exists with a guessable name, and if used without checking the
docs, would cause breakage in someone's app.
So calling them set_inactive and clear_inactive would be consistent
with all the other flags, including those that should only be used with
care.
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).
I don't really care for the naming though,
setup_only_set_inactive would be fine by me.
Well, if we go that route, then I'm fine with set/clear_active() too,
for consistency reasons, as you wrote, although I suggested to use
another name before. Let's see what users do with it...
BTW: you proposed set_inactive() and clear_inactive(), which sounds
somewhat like a double negation. Although the internal flag is called
INACTIVE, I would propose to use the "positive" forms set_active() and
clear_active() for the API.
Any more comments?
--
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.
[ Direct Link to Message ] | |
|
| |
