[RFC] octave-to-backend notification of property change

[Michael Goffioul]

Hi all,

I'm currently in the process of implementing the mechanism used by
octave to notify the backend about property changes that can impact
GUI elements. I'm not talking here about objects contained in an axes
system, which are handled during the axes rendering, but about
actual GUI elements. For instance:
- "name" in figure => change figure window title bar
- "string" in uicontrol => change control string (for instance the
text of a button)

When such properties are changed, the backend must be notified
in order to update its internal GUI elements. I thought about 2
possible mechanisms:

1) In the "set" method of the corresponding property (for instance
in figure::properties::set_name), call a specific method in the
backend to notify it (for instance update_figure_name). The
real backend implementation can then overload the method and
implement the appropriate action.

2) Delay the backend notification until next "drawnow". This can be
done by adding a "modified" flag to the property class, which is set
to "true" when a property is modified. During the next drawnow, the
real backend can then poll all properties it knows about, check if
they changed and implement the appropriate action.

Now let's talk about advantages and drawbacks. Option 1 imply
a lot of methods to add to the backend classes, especially for
uicontrol objects, but the effort can be largely reduced with some
preprocessor magic (I experimented it). OTOH the backend becomes
very responsive, because the it gets notified almost immediately.
However for functions/scripts that modify a lot of those properties,
the CPU overhead due to method call and possibly thread
synchronization can quicly slow things down. At the opposite,
option 2 does not requires much coding in octave (most of the
work will be done by the backend), but you'll only see the visual
result of changing a property in the next drawnow.

I experimented a little in the competition, and used the following
piece of code

figure;
for k=1:500, set(gcf, 'position', [k 50 500 500]), end

You can see the figure window moving, which means that something
similar to option 1 is used. I started to implement option 1, but then
I started to doubt whether it was the best solution. I tried to figure
out a use-case where a bahevior like in option 1 would be required,
but could not find any.

So, does anybody have any comment or scenario that would be
in favor of one option vs. the other?

Thanks.
Michael.