visualoberon-win32 Mailing List for VisualOberon
Status: Beta
Brought to you by:
tteuling
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
(35) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Benno L. <ben...@id...> - 2004-05-03 07:16:11
|
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 _______________________________________________________________________ |
From: Tim T. <ti...@ed...> - 2001-06-23 21:23:05
|
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. |
From: Michael G. <mgr...@co...> - 2001-06-23 19:34:17
|
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. |
From: Tim T. <ti...@ed...> - 2001-06-15 05:46:42
|
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. |
From: Tim T. <ti...@ed...> - 2001-06-12 19:46:58
|
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. |
From: Stewart G. <sgr...@ip...> - 2001-06-12 06:51:03
|
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 |
From: <tim...@ma...> - 2001-06-11 11:29:12
|
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. |
From: Stewart G. <sgr...@ip...> - 2001-06-11 09:14:57
|
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 |
From: Michael G. <mgr...@co...> - 2001-06-10 19:56:07
|
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. |
From: Michael G. <mgr...@co...> - 2001-06-10 14:50:25
|
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. |
From: Stewart G. <sgr...@ip...> - 2001-06-09 10:12:37
|
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 |
From: Tim T. <ti...@ed...> - 2001-06-09 07:13:18
|
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. |
From: Stewart G. <sgr...@ip...> - 2001-06-09 06:17:32
|
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 |
From: <tim...@ma...> - 2001-06-08 09:48:34
|
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. |
From: Stewart G. <sgr...@ip...> - 2001-06-07 13:52:00
|
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 |
From: Tim T. <ti...@ed...> - 2001-06-06 20:51:01
|
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. |
From: Stewart G. <sgr...@ip...> - 2001-06-06 05:25:07
|
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 |
From: Tim T. <ti...@ed...> - 2001-06-05 20:26:42
|
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. |
From: Tim T. <ti...@ed...> - 2001-06-05 20:26:42
|
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. |
From: Stewart G. <sgr...@ip...> - 2001-06-05 08:31:20
|
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 |
From: Tim T. <ti...@ed...> - 2001-06-04 09:17:02
|
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. |
From: Michael v. A. <mi...@de...> - 2001-06-03 21:12:46
|
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. |
From: Michael G. <mgr...@co...> - 2001-06-03 20:37:56
|
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. |
From: Tim T. <ti...@ed...> - 2001-06-03 15:46:52
|
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. |
From: Michael G. <mgr...@sy...> - 2001-06-03 13:09:32
|
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. |