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

[Tim T. <ti...@ed...>]

Hallo!

> - Draw and HandleMouseEvent had to be significantly redone, but it was not
> too hard. The greatest difference is that Blackbox mouse tracking is moda=
l:
> once a mouse press is detected the program must enter a polling loop to
> read mouse motion events.

Yes, I thought about that, too. I you not manually grab the mouse
strange things may happen, becuase you may never get mouse up. So the core
doing automatic mouse grabbing (that means, if a button down even
accures delegate all mouse events to the object catching the button
down even utnil he button gets raised again). This would make things
simpler, but also less flexible :-/

> > There is also functionality for double buffering. So WireFrame for
> > that. You just allocate a bitmap of the specified size, draw into it
> > (the bitmap has a DrawInfo instance) and then copy it back to the
> > window. This will avoid flickerr even more.

> Both previous versions had this feature, but I haven't implemented it here
> yet.

It would be easy to implement, so I thought I should mention it. But it is =
of
course not needed.

> > yet). It seems like already deep into VO :-) IF you have any comments
> > regarding implementation details, nice or not that nice stuff, feel
> > free to speak.

> Here are a few initial comments that come to mind.

> 1) The semantics of Draw are rather complicated. If I understand it
> correctly, Draw may be called on a region that does not actually include
> the object. It may also be called when the object does not need to draw
> itself (visible=3DFALSE). The object needs to translate all coordinates to

Correct. I thought about enforcing certain action. I could easyly
implement a wrapper to Draw that does automatically create a clipping
region for example. But that would not work if drawing is complicated.
If you have a complex visualisation or can get certain different changes
from you model you want to use special redrawing/refreshing methods.
Draw() does not get called then. It would be up to the user, to call
special DrawStart and DrawEnd methods implemented in the base class.
Also Clipping is expensive and can slow down drawing. That is because I
do not use subwindows for each control (Windows and X11 do support
this). Using subwindows would save me from doing manually clipping.

> its own x,y position and ensure that it does not draw outside its own
> bounds.

That is independent of the above and could always be implemented.
However since we currently do not subwindows the translation would
still be need - only just the other way round. This would include
transformation for every drawing primitive. We could add two more
additional variables (rX and rY, where "r" stands for "relative") that
get updated after every call to Move.

You see this rises and falls with the use of subwindows. It was a
design decision to not use them, bceause at that point not all OSs I
had in mind supported subwindows (Amiga OS for example). Since X11 and
Windows are currentrly the only tragets (with Mac of course, too) this
decision may have to be reevaluated. However moving in that direction
would not be simple. We have to check if this has inpact on the event
handling. We may get speed improvements in some parts (likly refreshing
would be much faster) but some things may slow down (if subwindow
clipping has an impact on the speed of drawing primitives).

> Under Blackbox a Frame is a rider on a Port; the Port encapsuates the
> actual OS device handle. The Restore procedure is passed a Frame which has
> a zero origin and automatically translates the coordinates of draw
> operations. It also has the clip region already installed, so that an
> object cannot draw outside its own bounds. AWT does something similar. Th=
is
> makes client code simpler and less error prone. I prefer this approach. I
> guess there may be a small performance penalty.

The problem is that all refreshing goes throw one methods making this
method much more complicated, especially when drawing is complex (think
of  atext widgets).

> VO allows user code to call Draw directly. I don't have a problem with
[...]

Correct. It is not good and bad. Both aproaches have advantages and
disadvatanges. I have no problem with changing that but it is a lot of
work and I don't think, I want to do that on my own.

> 2) I expected to be able to PushFont(f : Font), but there seem to be two
> different types of font handle (Font and id). Do I have to store them bot=
h?

Possibly. Look at VO:Text.Mod for the use of that. You only need the ID
for pushing and popping the font for drawing. However you need an
instance of the font class for font specific operations like getting
the size of a string when drawing it using this font. Font handling is
not optimal (thats because X11 is rather compklicated in that respect).
I'm not that happy with that part of the interface (OK, in fact every
part could be a possible candidate for improvement ;-)) and I'm also
willing to change that if there are suitable suggestions or even code.

> 3) VO has DrawArc and FillArc. It has FillRectangle and FillPolygon. For
> symmetry, there should probably be DrawRectangle and DrawPolygon. It might

True. Fillrectangle and FillPolygon are missing, because I never used
them <:-) also IMHO they are not part of the X11 drawing primitives.
But they can be implemented using existing routines. If an OS has
special support for them we could these optimized routines... NO
problem with that.

> also be nice to have DrawEllipse / FillEllipse, although I notice that
> DrawArc calls the GDI Ellipse code when it gets 0..360*64.

Yes, the X11 function is very powerfull (but has a strange interface
IMHO). We could split that into separate methods so implementation on
other OSs would be simpler. Thats is also an aproach that would help
solve the colored pattern and dotted lines problems under Windows.

> 4) It looks like Prefs are used for setting global parameters that control
> the way a class of objects is displayed. It would be nice if this could
> also be used to control local (per-object) preferences. For example, a
> pop-up menu for an object could use a Prefs-style dialog to control the
> look of that particular object.

Is possible. There is for each object (in theory, in practice for most
objects) a global prefs instance. Its values are read from the XML
configuration file if file and values are accessible. If no internal
defaults are used (that currently try to be close to
Windows/KDE/Gnome). If you instanciate an object it uses that global
instance for its own preferences settings. However you can instanciate
other instances of that preferences object and fill it with you own
values and then assign it to your special object instance (I never
realy used that but it should work). So you can have preferences not
only globale but also on an per instance basis. However, you should
never use this, because you kill the look and the result perhaps may
even not readable...

> The previous version of my GraphView object used Blackbox Properties
[...]

I'm not sure I that above fullfills your needs. Do you have something
different in mind?

> Since VO uses LONGINT coordinates, it would make sense if PointDesc.x, y
> were also LONGINT. This means that point arrays may have to be translated
> for some implementations (X11?).

Yes. But I would like to avoid allocating memory for calling drawing
primitives or do some copying of data. Perhaps The methods should
allocate a buffer with a defined size so you cannot assign array that
are longer than his buffer. That way you would not need to allocate new
memory but can copy (second best solution)...?

--
Gru=DF...
       Tim.