visualoberon-win32 Mailing List for VisualOberon

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I
kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The
questionnaire consists of 53 questions and you will need about 15 minutes to
complete it.

With the FASD project (Fun and Software Development) we want to define the
motivational significance of fun when software developers decide to engage
in Open Source projects. What is special about our research project is that
a similar survey is planned with software developers in commercial firms.
This procedure allows the immediate comparison between the involved
individuals and the conditions of production of these two development
models. Thus we hope to obtain substantial new insights to the phenomenon of
Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under
http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please
see http://fasd.ethz.ch/qsf/mailinglist_de.html for registration to this
mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Hallo!

> I've been getting back to Linux and after installing VO,
> and when attempting to run an application, I get an error
> message saying that the shareable VO library cannot be
> found.  Any idea on what's happening?  The library is
> actually located in /usr/local/lib and neither gcc nor
> oo2c seem to complain.

If the library is there and is not broken, everything should be
allright. Is the directory in the library search path, did you call
ldconfig?

--
Gru=DF...
       Tim.

Hi all,

I've been getting back to Linux and after installing VO,
and when attempting to run an application, I get an error
message saying that the shareable VO library cannot be
found.  Any idea on what's happening?  The library is
actually located in /usr/local/lib and neither gcc nor
oo2c seem to complain.

Michael G.

Hallo!

OK, here is the new windows code based on the new version of X11 VO I
will release in the next few minutes (if sourceforge allows). Have fun.

I'll be away of the weekend...

--
Gru=DF...
       Tim.

Hallo!

> It seems that CreateCompatibleBitmap requires the handle on the original
> DC, *not* the compatible DC returned by CreateCompatibleDC. The bitmap
> created with the compatible DC appears to be monochrome so when it it
> blitted into the window DC the result is a dithered image that maps
> black/white to the default foreground/background colour. I guess Windows
> does not regard "compatibility" as transitive.

I used the VisualStudion 5 (reference) documentation while implementing this
and I remember that it was not very clear how things work. When it
worked for me (WireFrame) I thought I got it. Seems like it was not the
case :-/

> The attached Display.Mod corrects the problem in CreateBitmap.

Fine and thank you for your effort. I will integrate the changes into
my local version. I also hope to include the Point-buffer stuff we
discussed on Thursday. If I do I will publish a new version of the X11
version of VO. This will include other changes to certain files
I did while porting. As a result some file currently in the windows
changes can be removed...

--
Gru=DF...
       Tim.

tim...@ma... wrote:
> 
> Hallo!
> 
> > For me, colours drawn into bitmaps don't come out when copied into a
> > window.
> 
> I didn't have that problems when checking functionality using the WireFrame
> stuff in XTest, but it only uses black and white.
> 
> Perhaps a color allocation problem? But colors aren't bitmap local, they are
> global
> to the programm!?

After a lot of detective work, I finally found the problem. Its rather
subtle.

It seems that CreateCompatibleBitmap requires the handle on the original
DC, *not* the compatible DC returned by CreateCompatibleDC. The bitmap
created with the compatible DC appears to be monochrome so when it it
blitted into the window DC the result is a dithered image that maps
black/white to the default foreground/background colour. I guess Windows
does not regard "compatibility" as transitive.

The attached Display.Mod corrects the problem in CreateBitmap.

Cheers,
  Stewart

Hallo!

> For me, colours drawn into bitmaps don't come out when copied into a
> window.

I didn't have that problems when checking functionality using the =
WireFrame
stuff in XTest, but it only uses black and white.

Perhaps a color allocation problem? But colors aren't bitmap local, =
they are
global
to the programm!?

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

Tim Teulings wrote:

> > It seems that bitmaps are not implemented in the current version of
> > VO/Win32. I will need them to do double-buffering.
> 
> > If someone has is working on this, let me know. Otherwise, I'll have an
> > attempt at it next week.
> 
> I did implement them and AFAIK I did send the relevant code. Bitmaps
> are working for me as tested with the last tab in XTest
> (VO:WriteFrame.Mod).
> 
> I'm adding the current source code to this message, perhaps the message
> got lost...

OK. I tried the bitmaps and they seem to work. Animation is certainly
smoother.

For me, colours drawn into bitmaps don't come out when copied into a
window.

For example, the attached view comes out black, white, and red when drawn
directly into the window. When drawn via a bitmap it comes out black and
grey (grey is my default background colour). Red seems to be mapped to
grey. I can't see anything obviously wrong with Display.Mod. If noone has
an obvious solution, I'll take a deeper look.

In the example, set UseBitmap in GraphView.Mod to control whether or not a
bitmap is used.

Cheers,
  Stewart

I've attached the final version of the attributes testing module.
If anyone has any improvement suggestions, feel free to make
the changes yourself as I'll be busy on other projects.

What is missing are some flags for determining whether to use
Unix-attributes or just PC-attributes.  I'm not sure how you would
want to implement this.  The attribute functions for the PC
attributes always return FALSE at the moment.

Some flags probably also have to be added around the date/time
include files and the functions I call.

Have fun,
    Michael G.

Michael van Acken wrote:

> nice to hear from you.  I'm not quite sure why you think I have "lots
> to say" on this matter, but hey, I'll whip up an opinion in no time ;-)
>
> 1) I would suggest to split enumerating the names in a directory and
>    getting data on the returned names.  The most important reason for
>    this is that enumerating the names is quite portable, while
>    obtaining file stats isn't.
>
>    Getting file info should be a different module, say "OS:Stat".
>    This module should provide a function to get a info object for a
>    file name, and this info object should have methods (_not_
>    attributes) to access all relevant information.  In particular, I
>    strongly suggest to drop the "is*" flags and replace each of them
>    with a predicate method for portability and efficieny reasons.
>    This methods would map to the C-level "S_IS*" macros.

Watch for the attribute interface coming soon.

>
>
> 2) The enumeration of the files should _not_ report the entries "."
>    and ".." to the caller.  Reason: They are always there, even if
>    some readdir()s don't report them, and most of the time the user
>    must filter them out anyway.

Ok, these entries have been filtered.

>
>
> 3) Don't ignore error messages with Open/Next/Close.

I'm going to ignore these errors since I don't know much
about how either the C interface or Oberon-2 errors work.
Anyone interested can add the error reporting.  For now,
a NIL return from Open means it didn't work and an empty
string from Next() means no more entries could be found.
I think that 99.9% of all directory lists will work with
this.  Remember the KISS principle.

>
>
> 4) The iterator pattern for this module should be as simple as
>    possible.  The simplest one I can come up with is

Mine is even simpler.  See attached TestDirectories.  I'm
using a returned string for the file entry so the interface to the
attributes module can be cleanly separated from this module.
Besides, you need a filename to get attributes anyway.  In
addition Directories can be used stand-alone if you don't
care about attributes and all you need is a list of filenames.

> 5) Document that the reported order of files is pretty much random.

Done.

>
>
> 6) I would consider skipping Rewind().  Would anybody miss the Unix
>    functions rewinddir(), telldir(), and seekdir()?  Probably not.

Done

>
>
> And when all is done, one could write yet another module that selects
> all files of a directory matching a regular expression and return them
> sorted according to a given relation.  The regexp matcher I justed
> checked in under libadt might come in handy there :-)

An exercise left to the reader.

>
>
> So, is this "lots" enough?
>

As usual you came through.  :-)

Michael G.

Thanks. I'll try the lastest code. I must have missed one of the updates.

Cheers,
  Stewart

Tim Teulings wrote:
> 
> Hallo!
> 
> > It seems that bitmaps are not implemented in the current version of
> > VO/Win32. I will need them to do double-buffering.
> 
> > If someone has is working on this, let me know. Otherwise, I'll have an
> > attempt at it next week.
> 
> I did implement them and AFAIK I did send the relevant code. Bitmaps
> are working for me as tested with the last tab in XTest
> (VO:WriteFrame.Mod).
> 
> I'm adding the current source code to this message, perhaps the message
> got lost...
> 
> --
> Gruß...
>        Tim.
> 
>   ---------------------------------------------------------------------------
>                            Name: VisualOberon.tar.bz2
>    VisualOberon.tar.bz2    Type: unspecified type (application/octet-stream)
>                        Encoding: base64

Hallo!

> It seems that bitmaps are not implemented in the current version of
> VO/Win32. I will need them to do double-buffering.

> If someone has is working on this, let me know. Otherwise, I'll have an
> attempt at it next week.

I did implement them and AFAIK I did send the relevant code. Bitmaps
are working for me as tested with the last tab in XTest
(VO:WriteFrame.Mod).

I'm adding the current source code to this message, perhaps the message
got lost...

--
Gru=DF...
       Tim.

Hi,

It seems that bitmaps are not implemented in the current version of
VO/Win32. I will need them to do double-buffering.

If someone has is working on this, let me know. Otherwise, I'll have an
attempt at it next week.

Cheers,
  Stewart

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.

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

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.

Tim Teulings wrote:

> > For your amusement, here a Model/View for displaying graphs. As an
> > experiment, I ported some of my code from Blackbox. Its not finished, but
> > you'll get the idea.
> 
> I will do some comments to your code, so perhaps you might understand
> some concepts better, but first of all: It is c00l (I should write it
> in fat letters: *c00l*). It already looks very nice. Since it is ported
> code (anotehr language another visualisation system). Was it difficult?

This is the third incarnation of this widget. First was written in C++ in
my "Pastel" GUI framework. Second was written in Component Pascal for
Blackbox Component Framework.

In porting this to VO, I split one module into a separate modules for View
and Model. Translating to Oberon-2 was not too hard.

Language issues:
- Remove procedure attributes (eg. NEW).
- Replace IN/OUT parameters with VAR
- Convert INTEGER to LONGINT
- Convert POINTER TO RECORD ... END to separate POINTER and RECORD
declarations.
- Implement MIN(a,b), MAX(a, b). These are built in procedures in Component
Pascal.

Framework issues:
- Use RealMath in place of Math. Implement ceiling.
- Convert Blackbox types to VO types. Color -> Color. Font -> Font. Frame
-> DrawInfo. Most of the associated methods are different, although there
seems to be equivalent functionality.
- 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. 

> VO uses parmeterless Init methods. I like them better. So for
> Graphodel one should initialise later on. The same for GraphView. But
> that is just style... You do not need to hand an instance of
> VO:Base:Diplay.Display to controls. There is only one instance and it
> always exists (but may of coure not always valid). So you can access it
> directly. Of couse you do not need to call Draw for a refresh you can
> make your own optimized version for updates and model changes. This
> will give you a cleaner and smoother refresh.
> 
> 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.
 
> The rest is OK fromt he first view (to much code to look into detail
> 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=FALSE). The object needs to translate all coordinates to
its own x,y position and ensure that it does not draw outside its own
bounds.

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.

VO allows user code to call Draw directly. I don't have a problem with
this, and it makes some things easier to do. For example, if a user
manipulates a Model, the view's Resync can call Draw so each view can be
updated interactively. Under Blackbox, a view's HandleModelMsg can call
Update but that does not redraw the object. It schedules an update which is
done later by the framework. Because mouse tracking is modal, you can only
directly update the view that is handling the mouse input. Separating
Update and Restore does have the advantage that the redrawing of an object
can be deferred in the situation where views are updated rapidly.

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?

3) VO has DrawArc and FillArc. It has FillRectangle and FillPolygon. For
symmetry, there should probably be DrawRectangle and DrawPolygon. It might
also be nice to have DrawEllipse / FillEllipse, although I notice that
DrawArc calls the GDI Ellipse code when it gets 0..360*64. 

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.

The previous version of my GraphView object used Blackbox Properties
objects to do this. Here, the framework controls properties of via
Properties.EmitMsg and Properties.CollectMsg control messages. Blackbox
uses meta-programming and a mapping file to look up a dialog for the
dynamic type of the emitted property object. It looks like something
similar could be done with Prefs. A Prefs object already has an associated
dialog, so this part is probably neater. If there were a method for
emitting/collecting Prefs from an object this could be used as the basis of
a nice properties dialog mechanism. 

> X11 uses INTEGER for XPoint (you know that point stuff in
> VO:Base:Display) so I had to add six SHORT casts for Unix. But we have
> to fix that nevertheless (also open for solutions/implementations for
> that part).

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

- Stewart

Hallo!

> Not yet. I'm still trying to learn my way around VO.

OK :-)

> For your amusement, here a Model/View for displaying graphs. As an
> experiment, I ported some of my code from Blackbox. Its not finished, but
> you'll get the idea.

I will do some comments to your code, so perhaps you might understand
some concepts better, but first of all: It is c00l (I should write it
in fat letters: *c00l*). It already looks very nice. Since it is ported
code (anotehr language another visualisation system). Was it difficult?

OK. The code:

VO uses parmeterless Init methods. I like them better. So for
Graphodel one should initialise later on. The same for GraphView. But
that is just style... You do not need to hand an instance of
VO:Base:Diplay.Display to controls. There is only one instance and it
always exists (but may of coure not always valid). So you can access it
directly. Of couse you do not need to call Draw for a refresh you can
make your own optimized version for updates and model changes. This
will give you a cleaner and smoother refresh.

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.

The rest is OK fromt he first view (to much code to look into detail
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.

> Have fun. It works for me under Win32.

X11 uses INTEGER for XPoint (you know that point stuff in
VO:Base:Display) so I had to add six SHORT casts for Unix. But we have
to fix that nevertheless (also open for solutions/implementations for
that part).

--
Gru=DF...
       Tim.

Hallo!

> I've successfully ported over my XCal to use the new
> VO interfaces.  It seems to work under Windows NT.

Fine :-) I hope there were only a few changes necessary.

> There are a few strange things happening such as the
> title for the scroller being overwritten.  I haven't tried
> it yet under Unix.

I compiled it under Unix and it seems that while pressing the century
buttons the slider get some strange values and overwrites the area to
its right. Bceuase I also happens under Unix this seems to be a bug in
the slider itself. If you have some time, please check the values it
gets from the model and print out the caluclated ranged. Seems that
there is missing a test or something similar. I will take a look at it
later...

Btw.,  date and time pickers are also open for inclusing into VO.
However at least for date I would like to choose an little bit
different interface that is more similar to the Window control or the
one a PDA uses (btw., displaying dates in a calender and choosing a
date are different things with different controls IMHO).

> BTW, could I get a copy of someone's VO preferences?
> Perhaps this file could be included in future distributions?

Did you get the preference to work?

--
Gru=DF...
       Tim.

Tim Teulings wrote:

> By the way, is anybody activly doing something on the VO Windows code?

Not yet. I'm still trying to learn my way around VO.

For your amusement, here a Model/View for displaying graphs. As an
experiment, I ported some of my code from Blackbox. Its not finished, but
you'll get the idea.

To compile, put the directory in the source path and do:
  oo2c [ --config oo2crc ] -Mv GraphTest

Drag nodes to set their position. Fixed nodes are displayed in red. Nodes
can be fixed/released by clicking without dragging. Drag elsewhere to
rotate the display volume. Shift-click to add edges. If the end-point is
within a node the edge links to the node, otherwise it links to a new node.

Have fun. It works for me under Win32.

Cheers,
  Stewart

Hallo!

> Yes, I meant the slider.

At least I have no problems with the slider in XTest (Tab "Other"). Is
yours vertical or horizontal?

--
Gru=DF...
       Tim.

Michael Griebling <mgr...@sy...> writes:

> Hi all,
> 
> Here's the initial definition of the directory scanning interface.
> Please make any comments and let me know what changes you
> think would make this module better.  I'm sure Michael will have
> lots to say :-)

Michael,

nice to hear from you.  I'm not quite sure why you think I have "lots
to say" on this matter, but hey, I'll whip up an opinion in no time ;-)

1) I would suggest to split enumerating the names in a directory and
   getting data on the returned names.  The most important reason for
   this is that enumerating the names is quite portable, while
   obtaining file stats isn't.  

   Getting file info should be a different module, say "OS:Stat".
   This module should provide a function to get a info object for a
   file name, and this info object should have methods (_not_
   attributes) to access all relevant information.  In particular, I
   strongly suggest to drop the "is*" flags and replace each of them
   with a predicate method for portability and efficieny reasons.
   This methods would map to the C-level "S_IS*" macros.

2) The enumeration of the files should _not_ report the entries "."
   and ".." to the caller.  Reason: They are always there, even if
   some readdir()s don't report them, and most of the time the user
   must filter them out anyway.

3) Don't ignore error messages with Open/Next/Close.

4) The iterator pattern for this module should be as simple as
   possible.  The simplest one I can come up with is

   VAR d: Directory; res: Msg.Msg;
   ...
   d := Open(name);
   WHILE d.Next() DO
     (* ... do something with current entry *)
   END;
   Close(d);
   IF (d. res # done) THEN
     (* oops, something went wrong in one of the preceding fct calls *)
   END

5) Document that the reported order of files is pretty much random.

6) I would consider skipping Rewind().  Would anybody miss the Unix
   functions rewinddir(), telldir(), and seekdir()?  Probably not.

And when all is done, one could write yet another module that selects
all files of a directory matching a regular expression and return them
sorted according to a given relation.  The regexp matcher I justed
checked in under libadt might come in handy there :-)

So, is this "lots" enough?

-- mva


> 
> MODULE Directories;
> 
> IMPORT sc := SysClock;
> 
> CONST
>     isDir *     = 0;   (* set when the entry is a directory *)
>     isRead *  = 1;   (* set when the entry is readable *)
>     isWrite *  = 2;  (* set when the entry is writeable *)
>     isExec *   = 3;  (* set when the entry is executable *)
>     isArch *   = 4;  (* set when the entry is archived *)
>     isHidden * = 5; (* set when the entry is hidden *)
>     isComp * = 6;  (* set when the entry is compressed *)
>     isSys * = 7;     (* set when the entry is a system file *)
>     isLink * = 8;     (* set when the entry is a link to another file *)
> 
> TYPE
>     Directory* = POINTER TO DirDesc;
>     DirDesc* = RECORD
>         ok- : BOOLEAN;       (* true if last operation succeeded *)
>         size- : LONGINT;      (* current size in bytes *)
>         date- : sc.DateTime; (* date attached to file *)
>         flags- : SET;             (* set of attributes for the active entry
> *)
>     END ;
> 
> (* Open the directory named "name".  A NIL pointer is returned
>     if the directory cannot be opened.  *)
> PROCEDURE Open * (name : ARRAY OF CHAR) : Directory;
> 
> (* Returns the name of the active directory entry.  An empty string
>     is returned at the last directory entry. *)
> PROCEDURE (d : Directory) EntryIs * (VAR ename : ARRAY OF CHAR);
> 
> (* Steps to the next entry in the current directory.  "ok" is updated
>     to reflect the status of this operation. *)
> PROCEDURE (d : Directory) Next * ();
> 
> (* Restarts the directory scan from the beginning. *)
> PROCEDURE (d : Directory) Rewind * ();
> 
> (* Closes the directory "d". *)
> PROCEDURE Close * (VAR d : Directory);
> 
> END Directories.

Tim Teulings wrote:

>
> What do you mean with "title of the scroller"? Do you mean the slider?
> This may of course be a drawing or refrshing problem, not yet found.
>

Yes, I meant the slider.

>
> Yes. Since inserting and delting of object should work now, this should
> not be a problem.
>
> By the way, is anybody activly doing something on the VO Windows code?

Not me.

>
>
> The directory code is OK for me, at least it looks sufficient for a
> directory browser. I fear that MvA with a more general look for
> usibility will have some suggestions for changes ;-) Also we need
> something now, and since the interface is small, it will not be a
> problem to later change to another API. For inclusion into VO however
> it should work on at least most of the OS/Systems.
>

Ok, I'll see if I have time to complete this directory browser some
time this week.

Michael G.

Hallo!

> I've successfully ported over my XCal to use the new
> VO interfaces.  It seems to work under Windows NT.

That is nice to hear :-) The demos programs should work, at least
within the range of the implemented features.

> There are a few strange things happening such as the
> title for the scroller being overwritten.  I haven't tried
> it yet under Unix.

What do you mean with "title of the scroller"? Do you mean the slider?
This may of course be a drawing or refrshing problem, not yet found.

> BTW, could I get a copy of someone's VO preferences?

I have one for unix, but most of it will not work under Windows, since
it makes uses of images for background and button look. You will have
to some modifications.

> Perhaps this file could be included in future distributions?

Perhaps, since preference can greatly enhance the visual look. Note for
the windows version, that size of most object depends on the font size.
The font that is hardcode is a little bit big, so the dialogs get a
little bit big, too (at least in relation to my 1200x1024 resolution).

> As well, I remember Tim talking about depreciating the
> List and Cycle objects.  I'm still using these in my

Yes, they are obsolete. The will/may compile, but I havn't tested them
for functionality for a long time.

> SimpleGadgets routine.  I take it the Combo object
> replaces the Cycle object?  Why doesn't the Combo

Yes. That is planed. The have the same functionality. But since Combo
make use of table and as such can handle also non-text objects, columns
and is not limited to the number of elements it has major advantages
(however the cycle is close in style to the motif equivalent).

> object work properly -- is this related to the pop-ups
> not working?  I guess the Table object replaces the

The do work with the latest code I send, but it seems like event
handling for it is buggy, since you can only choose an entry when
initialiy opening it and after that no more. Someone has to find the
bug.

> List?

Yes. Since inserting and delting of object should work now, this should
not be a problem.

By the way, is anybody activly doing something on the VO Windows code?

The directory code is OK for me, at least it looks sufficient for a
directory browser. I fear that MvA with a more general look for
usibility will have some suggestions for changes ;-) Also we need
something now, and since the interface is small, it will not be a
problem to later change to another API. For inclusion into VO however
it should work on at least most of the OS/Systems.

--
Gru=DF...
       Tim.

I've successfully ported over my XCal to use the new
VO interfaces.  It seems to work under Windows NT.
There are a few strange things happening such as the
title for the scroller being overwritten.  I haven't tried
it yet under Unix.

BTW, could I get a copy of someone's VO preferences?
Perhaps this file could be included in future distributions?

As well, I remember Tim talking about depreciating the
List and Cycle objects.  I'm still using these in my
SimpleGadgets routine.  I take it the Combo object
replaces the Cycle object?  Why doesn't the Combo
object work properly -- is this related to the pop-ups
not working?  I guess the Table object replaces the
List?

Have fun,
    Michael G.