New GUI for the Atari 8-bit

[flashjazzcat]

Rewriting the menu handler took a long time, so nothing to download for a few more days yet, I'm afraid. The need to split the menu bar into different sections (with different owners, defining their menu bars in different physical banks of RAM) meant I had to come up with a linked list structure to string them all together into a single graphical entity. Previously, the menu bar was just seen as a normal menu with the items laid end-to-end, but no more. Fortunately the changes will make contextual menus much easier to handle.

 

 

So - the menu bar belonging to the application with the focus is now swapped in contextually. Moreover, there are now three different classes of menu bar which can be registered: System, Application, and "Menulet".

 

 

System and Menulet menu bars always have just one item (the Atari logo menu in the case of the System menu, and an 8x8 icon or string for a Menulet bar - the clock being a Menulet menu bar), and Application is where you put File, Edit, etc. Although space is limited, any process can register any menu type. As it happens, the "shell" registers three: the System menu, its own application menu, and the task/window menu next to the clock. The clock is registered by the clock process, which gets a menu event when the user pulls its menu down and chooses an item.

 

A process can update its menu at any time; changes to System and Menulet types are rendered immediately; changed Application menus show up the next time the application gets the focus. Mentlets are the only type with distinct register/update functions, since several menulets can be added (new ones appear between the leftmost menulet and the application menu) and this causes the size of the application menu to be reduced. There's nothing in place to deal with an application menu running out of space, but I'll worry about that later on. I can't see there ever being more than 3-4 Menulets.

 

I'm not adding all this stuff just for the sake of prevarication, BTW: I consider the contextual menu bar a basic requirement for the next demo, even if I don't get the other panes of the task manager done before I put something out. Still a few bugs to fix, anyway, and some UI niggles to sort out, but this work on the menu bar always felt like a big hurdle coming up, and I'm glad it's done.

[+MrFish]

I went back and cleaned up the icons in some of the designs I did over the last few days.

 

I also noticed I had a little mixture of 2D and 3D style icons together. So I did completely separate designs for the 2D and 3D styles, which gives each design a more consistent look.

 

 

2D 16 x 16 Icon Style

 

 

 

 

3D 16 x 16 Icon Style

 

 

 

 

 

2D Larger Bitmap Icon Style

 

 

 

 

3D Larger Bitmap Icon Style

 

 

Edited September 15, 2014 by MrFish

[+MrFish]

I know some people are waiting to see this.:

 

 

 

 

[popmilo]

I know some people are waiting to see this.:

Brilliant !!!

[AtariNerd]

It might be a bit early in the process and I'm not sure if the memory buffering can account for this,as yet, but a simple, yet effective demo, would be having two documents opened up and then cutting and pasting text from one document to the other document, saving the destination document, closing it and reopening it to show that the changes had been succesfully made. Basically, an implementation of a clipboard. This is probably the most common use scenario...though maybe it is best served by a dedicated app, like TLW.

[flashjazzcat]

It'll be good when we reach that stage, since it'll mean the thing's nearly finished (file system done, multi-line text control written). A demonstration of the clipboard we could produce sooner would be copying some text from a single-line text control in one window to another.

[+Philsan]

Today I received Atarimax 8Mbit Flash cart.

 

Feel free to release the demo!

[flashjazzcat]

Today I received Atarimax 8Mbit Flash cart.

 

Feel free to release the demo!

I will be delighted to prepare it once I have finished copying these five VHS home movies I promised to convert for my father. The software supplied with the EZCap capture device was crap, and everything else free either didn't work or produced jagged interlacing defects. Fortunately the solution was under my nose the whole time: good old VLC Media player, which captures beautifully from the input device.

 

However - I am now commencing the first tape, and although each one will hopefully capture unattended, someone's expecting their laptop fixed. I'd rather be working on the GUI, believe me.

[+Stephen]

I will be delighted to prepare it once I have finished copying these five VHS home movies I promised to convert for my father. The software supplied with the EZCap capture device was crap, and everything else free either didn't work or produced jagged interlacing defects. Fortunately the solution was under my nose the whole time: good old VLC Media player, which captures beautifully from the input device.

 

However - I am now commencing the first tape, and although each one will hopefully capture unattended, someone's expecting their laptop fixed. I'd rather be working on the GUI, believe me.

Interesting - I have never captured via VLC.

[flashjazzcat]

Interesting - I have never captured via VLC.

I had a light bulb moment when I remembered an article I'd read in Micro Mart years ago. It went into some detail about the fact VLC could basically do everything video related, including live streams and encoding. And - now I look - this is indeed the case. What a wonderful program.

[Xuel]

I had a light bulb moment when I remembered an article I'd read in Micro Mart years ago. It went into some detail about the fact VLC could basically do everything video related, including live streams and encoding. And - now I look - this is indeed the case. What a wonderful program.

 

You might also like VirtualDub by the one and only phaeron, author of Altirra.

[flashjazzcat]

You might also like VirtualDub by the one and only phaeron, author of Altirra.

I tried it, but let's say I wasn't clever enough to get it to do what I wanted.

[flashjazzcat]

Just trying to do what I can when I can, and it didn't take long to get the tab control working:

 

 

I want the "processes" tab done (with CPU usage for each task) before release at least. That won't take many hours, but there are bugs to fix too and some robustness to add before I let anyone loose on it.

Edited September 17, 2014 by flashjazzcat

[+Stephen]

Can't believe how this is shaping up!

[Faicuai]

Just trying to do what I can when I can, and it didn't take long to get the tab control working:

 

 

I want the "processes" tab done (with CPU usage for each task) before release at least. That won't take many hours, but there are bugs to fix too and some robustness to add before I let anyone loose on it.

 

F-SICK (!)

 

Can't wait to test-drive it for a while on either the Incognito-800.

 

It is practically incredible that this thing runs on a 1.7+ Mhz, 8-bit, 6502... Talk about a MONUMENTAL feat, here, in every step of the way.

 

Bring it on!

[potatohead]

It is impressive. It's excellent to follow this each week. You should feel really good Jon. Lots of people out here watching with great interest, egging you on!

[flashjazzcat]

Lots of people out here watching with great interest, egging you on!

Thanks. I appreciate the support. Keep egging, since I just discovered a bug in the inter-process messaging, and it's gonna be a nightmare to track down.

Edited September 18, 2014 by flashjazzcat

[flashjazzcat]

Fixed.

[TheNameOfTheGame]

Ugh 3 hour bug fix. That was a nasty one! Glad you squashed it

[flashjazzcat]

Yes: that's why I spent a couple of months trying to write the kernel so it would work right first time, and with a reasonable degree of success. This bug was caused by stuff I forgot to remove later on when I made changes to the message queue (basically adding per-process head and tail pointers). It's sheer punishment trying to trace faults in half a dozen doubly linked lists, head and tail pointers, pending message counts, sender IDs, etc, amidst context switches, even with Altirra's incredibly powerful debugger. It was easier to just rewrite the problematic sections. I'm fairly pleased that the kernel is completely functional and - now - robust, only six weeks after it was tested for the first time with just a blank desktop, menu bar, and nothing else. I see the first real hardware test was on 26 August too, so it's been moving along for a few weeks.

Edited September 18, 2014 by flashjazzcat

[ravard]

This continues to be an awesome project to follow. Just amazing. Looking forward to the demo.

 

ravard

[UNIXcoffee928]

As I believe that we had talked about, very early on, Lightpen & Koala Pad support would be a nice touch. It would definitely breath new life into these under-utilized user input devices that lots of people have packed away in a box, somewhere, in their attic.

[flashjazzcat]

Neither has the horizontal resolution to be useful in - say - a drawing program, I'm afraid. I'm sure I must have mentioned that already.

[UNIXcoffee928]

No, actually, you hadn't mentioned it, in fact, you said something like that you'd be happy to add the driver support, ha.

 

Just to be clear, I was describing using the light pen as an alternative to using the mouse to control the pointer in the GUI, not as a tool for a drawing program.

 

The light pen does not have the same fixed horizontal limitation as the tablet.

 

Check the section: "HORIZONTAL/VERTICAL POSITIONING" at http://www.atarimagazines.com/v3n1/lightpen.html

 

 

"The light pen's horizontal position is linked to color clock units."

 

 

"...values are independent of the graphics mode being used, so it's necessary to scale the pen's readings to match the correct screen positions for the graphics mode in use."

 

Seems like it would work fine, as long as there was a driver.

[flashjazzcat]

No, actually, you hadn't mentioned it, in fact, you said something like that you'd be happy to add the driver support, ha.

I mentioned the resolution issue here, which I covered again in post 3023.

 

The resolution issue was mentioned again here.

 

Just to be clear, I was describing using the light pen as an alternative to using the mouse to control the pointer in the GUI, not as a tool for a drawing program.

Understood, but I imagined drawing would be a primary use for such an input device.

 

The light pen does not have the same fixed horizontal limitation as the tablet.

 

Check the section: "HORIZONTAL/VERTICAL POSITIONING" at http://www.atarimagazines.com/v3n1/lightpen.html

 

 

"The light pen's horizontal position is linked to color clock units."

 

 

"...values are independent of the graphics mode being used, so it's necessary to scale the pen's readings to match the correct screen positions for the graphics mode in use."

 

Seems like it would work fine, as long as there was a driver.

Yep - it'll work fine, but since the coordinate system is tied to colour clocks, the mouse position will only be accurate to every alternate horizontal pixel. I don't really see how it's any different from the touch tablet in that respect.