AW: [Visualoberon-win32] Port of XCal to new VO

[<tim...@ma...>]

Hallo!

> The biggest problem I see is that modal mouse tracking blocks the =
main
> event loop, so everything stops while the mouse is being tracked. =
This
> includes window refresh, processing of timer events, etc. I=20
> think this is a
> fairly serious problem, especially if you are relying on some sort of
> timer-based background processing. Therefore I'm not in favour of it.

Since event handling of VO is "different" this would not be happen.
Time-Events
will still get through because they use a different meachanism. But
nevertheless,
when it is not wanted I will keep the current solution.

> True, but at some level the clipping must still be done. Even=20
> a sub-window
> must be clipped by the GDI device driver so it might not be faster. =
If
> clipping is not optimised in GDI, use of a generalised clip=20
> region that
> just happens to be rectangular might be slower than a simple=20
> rectangular
> clip which can always be assumed for sub-windows. Hopefully,=20
> this is not
> the case.

I would asume, that subwindow clipping is faster then clipping by hand, =
at
least
for the first clipping region (the window bounds). I'm also of the =
opinion
that by not enforcing clipping controls can redraw quicker in some =
situation
because they can decide to do no clipping. We should do some chekcing =
of
clipping
speed someday for further investigation. Is it still true for MAX OS X, =
that
it does not support subwindows. AFAIK the GUI is one of the things that =
got
a
major rewrite?

However without subwindows you still have the coords origin problem...

> problem. The idea
> of a stacks for drawing parameters is a good one. It would=20
> even make it
> possible to validate drawing code by checking that the push/pops are
> balanced.

Yes, when destructing the DrawInfo object, it checks if stack is empty.
I plan to do some more optimisation. F.e. check the last element on =
stack
and it has the same value, just increment a use count, so we do not =
need
reset a value on OS level that is already set. Might increase drawing =
speed
when the same value is pushed (likely from different controls) more =
than
once.

> I was just thinking about a general framework for properties.=20
> My GraphView
> has at least a dozen parameters that control the display,=20
> each of which
> should be controllable by the user depending on their need.=20
> For this kind
> of view, there is not a unique preference that will cope with all
> requirements. Although it might be possible, I would not want=20
> to fiddle
> with the look of individual GUI objects. I agree that the=20
> look needs to be
> maintained.

Currently the Prefs feature is used for only look and feel =
configuration.
Other parameters are just attributes/methods of the control. You =
propose
to a preferences-like general properties feature for further
parametrisation of controls. But isn't it OK to use object attributes
and methods for this. Or do you think of settings that will only be set
by the programmer but also by the user but that are not look and feel
relevant? Yes, in that case a general preferences mechanism would be
usefull.
However since VO already uses libXML, perhaps this should be the way to =
go?

> For large arrays, the operation will be slower anyway so the=20
[..]

You are right. I will change the X11 version (and later the windows) =
version
in ther sense of this proposal. This will remove the X11 dependency =
from
VO:Base:Display. However, may take some time, since I'm busy over the
weekend.

--=20
Gru=DF...=20
       Tim.