2007-09-09

TextViewerDS and GUI Thoughts

Things are going slowly at the moment. I’ve started a new project at work with an impossible deadline, which means I’m working flat-out and have little brainpower left over at the end of the day for DS work.

Just before that landed on me I changed TextViewerDS so that it can’t scroll above the start or below the end of the text being displayed. I’ll release a new version eventually.

Other than that, I’ve been thinking about how to handle the file requester. The obvious way is some kind of ASL-reminiscent file lister window. The problem with that is I’d need to write a simulation of the Amiga windowing and gadget system. To do so, I’d need to write:

  • A window class, to which all other gadgets can be attached
  • A gadget base class, that other gadgets can inherit from
  • A button class
  • A scrollbar class
  • A scrollbar button class (can inherit from the button class)
  • A window close button class
  • A window depth button class
  • A scrolling text window class (I think I can duplicate the TextViewer class and modify it to handle this)
  • A file list class (inherits from the scrolling text window class)

There’s probably some more things I need to write. Most of that’s fairly simple to do. The only real tricky bit is the window handling. How do windowing systems handle re-drawing windows? The most obvious way is to treat each window as a separate bitmap. Each gadget will have to be drawn using line and rectangle drawing functions, so to save time we can draw the entire window layout to a buffer, then copy it to video memory every time the window needs re-drawing. We can even work out which part of the window has been corrupted, and re-draw the whole lot. Simple, but it’ll use a lot of memory if we start opening a lot of windows.

The other alternative is to re-draw a window every time it gets corrupted. Saves memory, but it’ll be slow.

The other question is, how do we handle window dragging? Again, there are two options. The complex one is to show the window’s contents whilst dragging, which means lots of memory copy operations (slow) or lots of redrawing (slower). The simple one is to just draw the outline of the window, then move it once the window has been “dropped’ into place. I was initially concerned about the complexity of buffering and unbuffering the graphical data underneath the window outline, until I realised that all the old windowing systems (Workbench, Gem, Win3.11, MacOS, etc) just XORed the rectangle that described the outline of the window to display it, then XORed it again before moving to the next position. No extra memory or complexity needed.

There’s also some trickery needed to handle window stacks. Suppose I have three windows that overlap each other, and I move the middle window. The top window doesn’t need to be re-drawn, whereas the bottom window will need to be partially re-drawn. Thus, each window will need a height (or a depth, or a z-index as Javascript and Flash would call it) in addition to an array of invalidated rectangles for re-drawing.

The gadgets and windows would probably need to inherit from the same base class. This class would define things like the width and height of the item, some method of indicating whether the item needed to be re-drawn, etc.

The advantage of writing a windowing system now is that I need buttons for AmigaGuideDS, both for links within the text and for the back/forward/contents/menu/help buttons of the GUI.

Comments

ant.simianzombie.com » Blog Archive » Timers Revisited on 2008-10-05 at 16:05 said:

[…] I’ve been working on this for over a year; the first post about it on this blog was on September 9th last year. Nuts, a milestone […]