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

[Stewart G. <sgr...@ip...>]

Tim Teulings wrote:

> > - Draw and HandleMouseEvent had to be significantly redone, but it was not
> > too hard. The greatest difference is that Blackbox mouse tracking is modal:
> > 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 :-/

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 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.
 
> > 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=FALSE). 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.

True, but at some level the clipping must still be done. Even 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 region that
just happens to be rectangular might be slower than a simple rectangular
clip which can always be assumed for sub-windows. Hopefully, this is not
the case.

> > 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). 

I think that decision is correct. Mac OS does not have them either.

> 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).

I used the single window approach (as in VO) before. I found that it was
hard to make widgets that did not influence the drawing of other widgets or
vice versa. For example, widgets drawing outside their boundary, or
unspecified drawing options flowing over from other widgets. Admittedly, my
framework was fairly short-lived so I didn't get all the bugs out of the
code. If you're careful about design this should not be a problem. The idea
of a stacks for drawing parameters is a good one. It would even make it
possible to validate drawing code by checking that the push/pops are
balanced.

> > 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. This
> > 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 both?
> 
> 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.

I'll have a look at Text.Mod. 

> > 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?

I was just thinking about a general framework for properties. My GraphView
has at least a dozen parameters that control the display, each of which
should be controllable by the user depending on their need. 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 to fiddle
with the look of individual GUI objects. I agree that the look needs to be
maintained.
 
> > 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)...?

For large arrays, the operation will be slower anyway so the overhead of an
allocation might not be that bad. If we start with a reasonably large
buffer (say 64 points) its unlikely to need to grow much. If it does, the
draw operation will probably be slow anyway so the overhead of another
allocation would not be much. The buffer size could just adapt to the
maximum required length. Even 1000 points (very unlikely) would not be too
expensive.

Cheers,
  Stewart