...Any good gui is going to need to be event driven, for sure. You could look at Contiki for one method of doing an event-driven GUI on an 8-bit platform. Also, Allegro (the programing library) also has a neat event-driven method for it's built-in GUI, as well as an "object-oriented" paradigm, making it easy to customize the different GUI pieces in your own programs. Adapting that idea to the 8-bit may be a bit of challenge though.
Handy links: thanks. I know what needs to be done, but the methods tend to present themselves during the design stage. For example, the control methods for the text-mode dialogue boxes became quite elegant as I coded them up: on the first refresh pass, all the controls are drawn, but on subsequent tab-key entry into a control, it enters its edit state. This is easily controlled with a single flag, which all control routines observe, and either draw the control in a static state, or enter the edit stage. The main loop takes care of wrapping things up when you tab to the next field. This becomes a little more complicated with a mouse pointer system (although the keyboard control will be preserved), mainly because the access to controls is non-linear. The only real question is whether a control in the edit state should incorporate its own loop, polling the event handler, or whether the main dialogue loop should poll the event handler and feed keystrokes/mouse clicks to the active control. It's a subtle point, but I'm sure the most efficient method will soon become apparent.
I'm using a fast-text-routine written by Peter Dell now, it's much faster than the meanwhile 11 years old (and also damn fast) routine by Ron Hamilton ... so or so, these routines are much faster than the one from your demo, so may be you want to use the one I use in BOSS-X, but I only got the machine code (don't have the sources here). I think, Peter is active in this forum too ... username JAC in ABBUC-Forum (and I think here too) ... PM him for the sources.
Generally, I think GUIs that support current technologies are always useful. Like BOSS-X supports MyDOS' sub-directories, it's useful to find files and folders on 16 MB disks and images. The links you can make on the desktop help you to arrange frequently used programs, which can be a lot and hidden between useless files on a 16 MB disk.
You can say what you want, GUIs have to look nice, and they help you to manage large storages, so even if you just create a graphical file-manager for SpartaDOS, this will be a huge helpful application for users who work with this DOS.
I'll certainly PM Peter. Bear in mind that although the rendering routine I've written is pretty efficient, it is slowed in the demo both by the interrupt driven mouse, and the masking routine (which makes the text appear "under" the pointer). The masking routine replaces simple STA (SCR),Y and LDA (SCR),Y with two expensive subroutine calls, both of which establish whether the target location is behind the mouse pointer, and perform all the writing to/reading from the back buffer if that is the case. Even when the target byte isn't behind the pointer, the X,Y coordinates still have to be checked, and this takes a little time. That's why I'll only use the masked routine when drawing the drop down menus, but I'll turn off the mouse in all other situations (if the mouse pointer is removed from the screen, the rendering routines automatically use the "fast" option). I think the text rendering will be dramatically faster with the mouse switched off.
I'm still onboard. Doing the fonts, icons, and gui elements should be a blast.
I would still like to get the original proportional font design in there, which has full ascenders, rather than the chopped down version that we stuffed into the Atari font format.
I'm still up for either building a unique font editor or creating a utility that will convert bitmapped drawings into a font file, unless you're planning on utilizing some other preexisting format.
That's good to hear! We can quickly knock-up a font format with a header describing the baseline, cell width, height, etc. That way, we can have a font which has 8-bit wide chars which occupy, say, 12 lines. The routine to calculate the character width table from your original "PROPSANS" font is quite interesting in itself. The only problem I had was with the lower case "I", until I realize you'd left 1 bit of padding on the left of the character.
I removed it, and all was well.
If we could get some kind of conversion chain going where we could quickly produce proportional bitmapped fonts in various sizes (maybe up to 32 x 32 pixels maximum) with built-in character width data, that would be a weight off my mind. Borland CHR stroke fonts would be nice, but I see no practical way to use them throughout the system. GEOS was absolutely agonizing to watch as it rendered those fonts. Much easier to blit characters to the screen straight from the font buffer. Of course, italicisation, emboldening, etc, can all be accomplished reasonably well on the fly using bitmapped fonts.
Icons will probably come in 8x8 and 16x16 flavours - possibly larger ones, too, for icon view file windows. I fancy having little visual cue icons next to some menu entries.
I'm thinking a VBXE compatible GUI would do the trick! Either way, I'm always eager to see new GUI's for the Atari. Too bad our CPU is too slow for the task. :/
It would be nice to make the system device-independent as far as the screen display is concerned, but we really need to use game/demo tech to get this system to run anywhere near fast enough. Once the version for stock machines is working, maybe it wouldn't be too hard to create a VBXE version.
As for the CPU: it's going to be a struggle, especially since I've taken the decision to use (or at least cater for) proportional fonts. But the whole objective is to see if it can be made to work, and work fast, using all the dirty tricks in the book. I believe it can. Boss-X shows what can be done in Turbo Basic.
Something as simple as "Notepad" running in a window and using proportional fonts is a good test of practicality. The editor window can't be fully redrawn after each keystroke, but I already have optimisations in mind to make responsive editing possible.
Oh - almost forgot. Are there any real advantages to using a POKEY timer instead of a DLI for sampling the mouse? It really needs to be sampled at least 500 times per second (yes, that's right), but I thought using a POKEY timer might "spread out" the sampling somewhat. With a DLI, SIO is handled OK: CRITIC will disable the stage 2 VBL (preventing the mouse from re-drawing), which sector I/O will (usually) turn off the DLI bit. But what precautions are required prior to SIO transfers when using a POKEY timer for a mouse interrupt?
Edited by flashjazzcat, Tue Jan 4, 2011 7:27 AM.