New GUI for the Atari 8-bit

[JamesD]

Can't you build the structures, store them in ROM as data and then just do one or more memcopy calls to init RAM?

Maybe a loop that reads through a list with length, start address, and destination address.

And have it loop until length = 0.

<edit>

Actually, if the length and destination address are with the data you don't need the start address.

Edited April 12, 2011 by JamesD

[flashjazzcat]

Yes, it would probably be factored out somewhat into function calls. Actually, I'd expect to see some recursion too, its popular when working with trees and lists. It's not always the best way to do things though.

Recursion's used a lot in the GUI when navigating the tree, but with linear operations like this I didn't think there would be any great benefit.

 

From a certain perspective, C can be looked at as kind of a very advanced macro assembler. You don't have to use the stack heavily or use the C library.

I was never a C++ coder, but I am proficient in C. Viewing a simple C compiler as a macro assembler is a pretty good analogy. The parameter passing in A,X and heavy indirection used in the GUI code is quite reminiscent of the assembler code the old Atari CC65 used to produce.

 

Can't you build the structures, store them in ROM as data and then just do one or more memcopy calls to init RAM?

Maybe a loop that reads through a list with length, start address, and destination address.

And have it loop until length = 0.

<edit>

Actually, if the length and destination address are with the data you don't need the start address.

I don't quite get what you mean here. The routines I posted are to do with linking up structures in a list, "unlinking" them, and rearranging their order. Very little of the data in the structures is something you can pre-define in ROM. I have the basic object struture reduced to this now:

 

WIDGET		.struct	; generic widget object
class	.byte	; object type
parent	.word	; pointer to parent object
child	.word 	; pointer to first child
prev		.word	; previous peer (wraps to last object in list)
next		.word	; next peer (NULL = last child)
x		.word
y		.word	; 16 bits for virtual coordinate system
width	.word
height	.byte
visible	.byte	; set if object has been rendered (cleared when object is hidden)
.ends
;

"Visible" will probably end up as bit 7 of "class", reducing the whole thing to 16 bytes. All controls, objects and containers are extensions of this basic structure. There's absolutely no way of knowing in advance before the application starts building menus and opening up windows what the content or structure of the object tree is going to be. When you instance an object, you (or the menu manager) provide size and coordinates, then the init_object routine links the object up to the tree relative to the chosen parent and in the prescribed position in the list. Any other ancilliary info (in the extended structure) gets filled in by the application, or by a helper routine. For example, the routine which creates a menu first calls "create_object", asking for a handle to a new menu object. "Create_object" allocates RAM for on object of type "menu", links it up to the desired parent and with the desired relationship to its peers, and returns the object handle to the create_menu routine, which then fills in the rest of the info in the "menu" structure (based on "widget"), such as the number of items in the menu (initially zero), which item is selected, etc.

Edited April 12, 2011 by flashjazzcat

[JamesD]

Can't you build the structures, store them in ROM as data and then just do one or more memcopy calls to init RAM?

Maybe a loop that reads through a list with length, start address, and destination address.

And have it loop until length = 0.

<edit>

Actually, if the length and destination address are with the data you don't need the start address.

I don't quite get what you mean here. The routines I posted are to do with linking up structures in a list, "unlinking" them, and rearranging their order. Very little of the data in the structures is something you can pre-define in ROM. I have the basic object struture reduced to this now:

That data should be consistent every time you launch the GUI. Run it, grab the data it builds and startup is much quicker and smaller. This is best left to when you are making fewer changes.

[flashjazzcat]

That data should be consistent every time you launch the GUI. Run it, grab the data it builds and startup is much quicker and smaller. This is best left to when you are making fewer changes.

I guess if the file manager (or whatever the default desktop manager happens to be) was built into the ROM, this would be a good approach. It's not necessarily the case, though: the startup condition is a "screen" object as the root, and blank desktop container and not much else. My intention was to have the default desktop manager load from disk, so folks could write their own replacements if they wanted. However, I'm starting to think there'll be plenty of room to have the default desktop app on the ROM, and just jettison it if there's a replacement on disk.

 

Anyway, I'm working on the desktop icons and the window focusing, so you can test the startup speed yourself soon.

[flashjazzcat]

Am back "in the groove" today...

 

 

These are real icon objects - not just the static decoration I was using before. I'm pressing on with the interim demo because I can get away with the current memory limitations for the moment. Just prior to implementing the label rendering (the actual textual part, not the background), I remarked to Mr Fish that I was expecting the extremely quick full desktop redraw to slow down somewhat. It hasn't... I'm a bit bewildered by it, to be honest. The font renderer is exceptionally efficient, but I'm still patiently waiting for the performance to degrade.

 

For the moment, you'll be able to adjudge how fast a populated window will redraw from the speed those five icons render. Obviously the labels need to be centred, and the icon struct will contain a pre-calculated pixel offset for speedy rendering.

 

http://youtu.be/EvtD0ye15Yg

Edited April 12, 2011 by flashjazzcat

[+Allan]

Wow. A-ma-zing!!

 

Allan

[fibrewire]

Looks fantastic - but the 3.5 floppy icon is making my right eye twitch. Bring back the 5.25 icon!!!

[atarixle]

you're still doing a complete screen-refresh?

 

on non-composed GUIs, only hidden parts of the screen/windows are redrawn. idk exactly how they do that, but somehow they report the refresh() command only to formaly hidden objects. the moved object itself is not redrawn but shifted (in the video memory ... of course exept the parts that were "hidden" outside the window).

 

anyway, didn't you say you wanna release an early demo some weekends ago?

[flashjazzcat]

you're still doing a complete screen-refresh?

 

on non-composed GUIs, only hidden parts of the screen/windows are redrawn. idk exactly how they do that, but somehow they report the refresh() command only to formaly hidden objects. the moved object itself is not redrawn but shifted (in the video memory ... of course exept the parts that were "hidden" outside the window).

I mentioned the reason for this in my post. When the extended banks are available, I'll be using - among other things - a complete window bitmask so that icons can be rendered while partly obscured by windows. Since the outer limits of windows aren't on byte boundaries and we don't do pixel level clipping on the x axis, this is the only way to clip desktop objects without doing a complete screen redraw. For example, if you click an icon to select it and it's partly obscured by a window border, you don't really want to force a complete redraw just so the selected icon remains partly hidded by the window. We cannot create a clipping rectangle for the icon on the desktop in any other way than to use a large bit mask. The second bit of optimisation is a background buffer for the top level window. Ultimately, when moving and resizing the top window, nothing on the desktop will need to redraw.

 

In addition, of course, the top level window will be "blitted" to its new location if the size hasn't changed when it's moved.

 

If you look at Diamond GOS - which anyway enjoys the advantage of all objects existing on byte boundaries (it doesn't use proportional fonts, which greatly simplifies the implementation) - you'll notice that when a window partly obscures a desktop icon, the icon completely disappears and cannot be selected. And it's still slow.

 

As for implementing a "dirty rectangle" list: I know all about this, but the client areas are so comparatively small and the rendering routines so efficient, that confining redraws to a newly "revealed" region of the screen may have no tangible benefit on performance.

 

Anyway, didn't you say you wanna release an early demo some weekends ago?

Yes I did, but I didn't want to release something half-baked. I just need to finish the icon label formatting (which I got into knots with last night: I'm starting afresh today), and bringing the back window to the front, and I'll release it

 

So - while I'm in a straight talking mood: the full desktop redraw is NOT the way this will work when it's finished, so DON'T be concerned that this is getting coded in an ass-backwards fashion. It's not. This is not going to be called "Ass-Rig OS".

Edited April 13, 2011 by flashjazzcat

[flashjazzcat]

The label centering was surprisingly fiddly, and I'll leave the final implementation until I have a better idea on how the filenames will be encoded in the data bank later on. At the moment, I've split the filename and extender up into two null-terminated strings. There'll ultimately be an option to hide extenders, as well as the option not to wrap the filenames as shown in this screenshot:

 

 

With the wrapped label option, the extender is displayed on an extra line if the complete filename won't fit into a 48 pixel wide panel. This constraint allows for a 5 x 5 icon grid on the desktop. The alternative setting is no wrapping, which dictates a 6 x 4 icon grid on the desktop. I tend to prefer the wrapped labels, since they give a rather more well proportioned look to the icons.

 

Anyway: lots more work to do, and things won't look any different from this in the demo, so I'll get my head down and get on with it.

[+Stephen]

Can't wait to try this!

[+JAC!]

The "Floppy A" text looks better than the "ACC_TEST". Maybe using camelcase/lowercase representation of the file name will yield more characters per line. And while I hate Windows when it hides away file extensions (and replaces them by a always same looking icons), it might be OK for icons on the desktop. In a real directory/file view I'd expect them probably.

[w1k]

very nice

[spookt]

Damn it! Where's a time machine when you need one? Before this all my ambitions would have been to go back into the past and fill my boots with loads of hardware and software I missed out on. Now I just want to skip forward a few months so I can install this on my system.

 

Seriously amazing work Jon.

Edited April 13, 2011 by spookt

[flashjazzcat]

The "Floppy A" text looks better than the "ACC_TEST". Maybe using camelcase/lowercase representation of the file name will yield more characters per line. And while I hate Windows when it hides away file extensions (and replaces them by a always same looking icons), it might be OK for icons on the desktop. In a real directory/file view I'd expect them probably.

I agree regarding the lowercase text, although using lowercase in itself won't yield more characters per line to the extent that the wrapping of the name won't be required (believe me, MrFish and I have looked at this from every angle, and then again inside out). But aesthetically, lowercase or initial capitals are preferable, so we were considering "enforcing" one of those methods, all DOS filenames being uppercase as stored on the disk. I definitely think initial caps would look good. Of course, we can have this as an option in the control panel applet.

 

Same goes with extenders. Hiding them will get rid of a bit of bulk in icon view, and - usefully - would allow a 5 x 6 grid on the desktop. List view will in fact be the more challenging of the views, performance wise, and we're keen to see how fast it will be. All I can predict is that it shouldn't take much longer to update a busy list view window than it takes to draw that large edit menu, which takes just under a second, and that includes the background caching. Imagine two or three of those menus side by side, and the largest possible list view window can't take longer than that to redraw. Dense text rendering is something we need to keep on top of anyway, with a view to the text editor, etc.

[atarixle]

On MyDOS, file names are case sensitive anyway, so the file system itself defines if a letter is upper or lower case. Considering, I never touch this on my file-manager.

Edited April 15, 2011 by atarixle

[flashjazzcat]

On MyDOS, file names are case sensitive anyway...

Heh... great. Sounds like a real PITA.

 

...so the file system itself defines if a letter is upper or lower case. Considering, I never touch this on my file-manager.

It'll be a switch in the options, then, or will automatically deactivate if MyDOS is detected. Thanks for pointing that out.

[fibrewire]

fjc: AWESOME!!!

 

Now all you need is the Fuji logo in the top left for the system menu, and the ability to read the RT8 or Jiffy timer for the CLOCK!

 

The clock is important, just ask Steve Balmer

[fibrewire]

And for those that are wondering, Coachella 2011 is down the street from me, tickets are selling for $1000 a pop, and I've got - 20 tickets to paradise! Can you guys say $20K in a day? It's for a good cause

 

EDIT: All 20 tickets have been sold already - Holy GOD! I think they are gonna resell them at the gate for $1500 a piece!

[flashjazzcat]

fjc: AWESOME!!!

 

Now all you need is the Fuji logo in the top left for the system menu, and the ability to read the RT8 or Jiffy timer for the CLOCK!

Thanks. The clock's high on the list of jobs, since it will require an interrupt-based event (a redraw every time the minute ticks over). We also have a couple of other cool little widgets to go in the RHS of the menu bar.

 

I'm now reluctant to release a demo without "smart" screen redraws, given the rather worried commentary the videos attracted. This despite the fact that I'm just implementing everything incrementally, and I figured the most important thing was to get something up on the screen. I have a few ideas which will take a few days to test out, including background buffers, window masks, and dirty rectangle lists for client areas. I was initially inclined to think the latter would be complete overkill for this kind of screen resolution, but partial window updates are integral to a GUI text editor, and if the mechanism is already part of the GUI, all the better.

 

I've done a whole lot of talking, forum posting, emailing and RetroBriting over the past couple of days, and I have MyIDE driver updates to start at the weekend. If you send me an email and I take a while in replying, I'll apologize in advance: I'm just trying to get in the "zone" and forge ahead with some heavy coding. I'll say right here and now that I have too many irons in the fire and some stuff's gonna have to wait its turn.

[+Stephen]

I'll say right here and now that I have too many irons in the fire and some stuff's gonna have to wait its turn.

You need to hire a project manager

[fibrewire]

You need to hire a project manager

Project management software - BasecampHQ - get the free edition

 

I'll say right here and now that I have too many irons in the fire and some stuff's gonna have to wait its turn.

Do what you will, I appreciate just getting to watch the story unfold

 

Oh, and here's another

 

Also, letting customers steer the project is a bad idea. This is your project FJC, we are only here to submit ideas and watch what happens. You actually accomplished something, and we can only do what we know best - criticism

 

You could always sell a licesed 'FJC unfinished GUI' as version 1.0, and then sell updates as new versions to those that can't wait. Worked for Microsoft...

[fibrewire]

Hey, Have you thought of a name for the GUI? I thought Fuji GUI or FujiOS would be cool

[flashjazzcat]

You need to hire a project manager

Project management software - BasecampHQ - get the free edition

I'll look into it. I also need a CVS.

 

Oh, and here's another

Yep - I'd seen that. It's usually in the recommended videos next to my GUI vids. I think the original author would be well placed to develop for the GUI.

 

Also, letting customers steer the project is a bad idea. This is your project FJC, we are only here to submit ideas and watch what happens. You actually accomplished something, and we can only do what we know best - criticism

Yep - agreed. There have been too many teasers and too many videos. This is because the demo is taking much longer than expected, as the expectations increase and the coding takes longer and longer to fulfil those expectations. Best thing for me to do is post nothing else until there's a program to donwload.

 

Hey, Have you thought of a name for the GUI? I thought Fuji GUI or FujiOS would be cool

Good ideas. What about FuGUI!

[danwinslow]

Hey, Have you thought of a name for the GUI? I thought Fuji GUI or FujiOS would be cool

 

FlashCat might be cool.