[Oberon] Hidden bug in WMScribble.Mod?

[Thomas Frey]

> But if I enlarge the window before pressing the right button to
> delete my drawing, then more than one quarter of the window is
> cleared. (This behavior leads to a corrupted display of my
> chessboard.) I think using GetWidth() and  GetHeight() in
> procedure PointerDown() is wrong -- maybe it would be correct to
> use the initial, fixed window size instead?
Yes. The scribble application is the the very simplest case of a
window with a fixed framebuffer. In this example, the program should
only work in framebuffer coordinates (of the framebuffer that was
created with the window).
>
> I am confused -- its not absolutely clear for me which procedures
> use  fixed or scaled coordinates.
>
> The content of the window of WMScribble.Mod is scaled
> automatically, drawn lines become thicker if I enlarge the
> window. Is there a simple way to modify this, so that the window
> contents in not automatically scaled?
The window can be made non-scaling but the program is then responsible
for the redrawing.   Component windows are by default adjusting to the
window size. It is most flexible to implement the view of any model as
an extension of VisualComponent. That way the new display element can
be combined with existing other GUI elements like buttons and editors.

> Some idea how to draw nice chess pieces? Currently I see only two
> methods: Using bitmap-images or drawing the pieces with simple
> drawing primitives like lines. More powerful drawing methods, as
> used by Leonardo of Native-Oberon, seems to be not available in
> Bluebottle currently.
I suggest using Bitmaps since they are easiest for replacing (eg.
different set of pieces). It is also possible to use the Gfx framework
to create the bitmaps on the fly. (AosGfx*.Mod)

--Thomas