New GUI for the Atari 8-bit

[R6502A]

Ok - that's aboot three votes for Atari. However, you must respect my authority with regard to the final decision.

 

 

Lol! I can almost hear the voice.

 

Your authority will be respected.

[MEtalGuy66]

UNIX COFFEE, I agree with 100% of what you just wrote.. I also stand FIRMLY behind 100% of what I wrote, because the two things are not directly related. I am gonna continue this in PM because I have said exactly what I wanted to say and dont need to add anything else here.

[+JAC!]

Couldn't resist

 

- 30 years of power without the price

 

PM underlay would be a nice eye catcher for sure.

[flashjazzcat]

That's a rather nice rendition of the logo in 16x16. Could look pretty snazzy, but I can't guarantee it would be in colour if we did use it. We have enough interrupts on the go...

 

 

 

[flashjazzcat]

Finally got back into some coding after a few days absence (doing some major house cleaning), and cracked the maths necessary for the proportional scrollbar scaling. It was WELL worth the effort:

 

http://www.youtube.com/watch?v=jsh0lBdNLa0

[+Stephen]

Finally got back into some coding after a few days absence (doing some major house cleaning), and cracked the maths necessary for the proportional scrollbar scaling. It was WELL worth the effort:

 

http://www.youtube.com/watch?v=jsh0lBdNLa0

I see why you wanted that in there. I didn't think it was that big a deal, until seeing it in action!

[+Philsan]

What do you think about this mouse?

http://www.best-elec...endum.htm#Handy

 

But I think The Best CBT1 (scroll the page) is better.

Edited March 16, 2011 by Philsan

[fibrewire]

I would very much like to use my CX22 with the OS. Then I could say "FINALLY! A legitimate use for this thing!"

[fibrewire]

Seriously though, using the trak-ball would be great!

[fibrewire]

Oh, nearly forgot Your Atari GUI OS would make a great window system for ContikiOS

[Mr.Amiga500]

Seriously though, using the trak-ball would be great!

 

Yes, that would be the ultimate for sure. I've got a Trak-ball, but only ever use it for Centipede. It would be great to get more use out of the Trak-ball and a useable GUI would be perfect. It should work on Joystick 2 port, keeping joystick on Joystick 1 port - just like on Amiga. (where I also use a trackball)

[UNIXcoffee928]

Seriously though, using the trak-ball would be great!

 

Yes, that would be the ultimate for sure. I've got a Trak-ball, but only ever use it for Centipede. It would be great to get more use out of the Trak-ball and a useable GUI would be perfect. It should work on Joystick 2 port, keeping joystick on Joystick 1 port - just like on Amiga. (where I also use a trackball)

 

We had already covered this ground, over a month ago.

[flashjazzcat]

I see why you wanted that in there. I didn't think it was that big a deal, until seeing it in action!

I definitely think they're worth it. Actually the calculations aren't too difficult or code-intensive. The key - as I predicted - was in upscaling the dividend in order to do away with fractions. Works perfectly. The next job is to code up a resolution-independent positioning system, so that the handle position can always be described within a fixed range, regardless of its size.

 

I should add that the virtual workspace is 512 x 400 pixels in the demo video.

 

What do you think about this mouse?

http://www.best-elec...endum.htm#Handy

 

But I think The Best CBT1 (scroll the page) is better.

Hard to recommend one or another, but the mouse is certainly "different". I still like a conventional mouse, but I can see a track-ball being useful in certain circumstances.

 

 

Oh, nearly forgot Your Atari GUI OS would make a great window system for ContikiOS

No doubt it would. Since Contiki already has all the back-end stuff done, I wonder how tricky it would be (however that's a rhetorical question at the moment, so please do not post algorithms or code).

Edited March 17, 2011 by flashjazzcat

[jvas]

Finally got back into some coding after a few days absence (doing some major house cleaning), and cracked the maths necessary for the proportional scrollbar scaling. It was WELL worth the effort:

 

http://www.youtube.com/watch?v=jsh0lBdNLa0

 

Are you sure, that the size of the scrollbar relates to the size of the window this way?

Let's take a simple example of a text editor. If "word wrap" is turned on, then changing the width of the window affects the size of the vertical scrollbar.

Or in your demo, you just connected the size of the scrollbars to the resizing of the window, and this connection is up to the actual application?

[flashjazzcat]

Are you sure, that the size of the scrollbar relates to the size of the window this way?

Let's take a simple example of a text editor. If "word wrap" is turned on, then changing the width of the window affects the size of the vertical scrollbar.

Or in your demo, you just connected the size of the scrollbars to the resizing of the window, and this connection is up to the actual application?

You're quite correct. When a resize event occurs, the application may choose (in fact in most instances it will) to adjust the proportions of the "virtual" window. If text is wrapping to the window width and one adjusts the size, the document will effectively contain a greater number of lines, so the application will need to adjust the size of the virtual workspace (in the window structure's properties) and then issue a "dummy" scroll so that the scrollbars are resized and re-rendered. Since there are currently no objects in the client area, the demo in the video simply demonstrates a viewport of adjustable size on a fixed-size canvas. Also, in the example you describe (that of text wrapping horizontally to the window bounds), there would be no horizontal scroll bar at all. It's likely that the file manager will scroll window contents only on one axis (as is the case in TOS): narrowing the window will cause lengthening of the icon/filename list, and the adjustment of the offscreen workspace's width to match that of the visible window.

Edited March 17, 2011 by flashjazzcat

[OldAtarian]

Can an unmodded ST mouse be used with it? (both buttons functional)

[flashjazzcat]

Can an unmodded ST mouse be used with it? (both buttons functional)

An unmodded ST mouse will work fine, but a mod is required to get right-click functionality. I can't recall offhand what it is: I assume it's to get the button to show up on one of the pot lines. I'll build in functionality to use the right button, but if it's not available, something like Shift+Click will do the same job.

 

I'm using a rewired Amiga mouse which is MUCH nicer than the stock ST mouse, but I haven't experimented with right button mods yet.

Edited March 17, 2011 by flashjazzcat

[Heaven/TQA]

uj... just saw the videos and they rock... looks so Atari ST familiar or Mac OS. great speed imho. ST without Blitter and Tos 1.0 in 640x400 is not that faster...

[Mr.Amiga500]

Yes, that would be the ultimate for sure. I've got a Trak-ball, but only ever use it for Centipede. It would be great to get more use out of the Trak-ball and a useable GUI would be perfect. It should work on Joystick 2 port, keeping joystick on Joystick 1 port - just like on Amiga. (where I also use a trackball)

 

We had already covered this ground, over a month ago.

 

I must have missed a page. That's the problem with a 21-page thread.

[flashjazzcat]

I must have missed a page. That's the problem with a 21-page thread.

Don't worry about it. We could do worse things than mention trackballs twice in the same GUI topic.

Edited March 17, 2011 by flashjazzcat

[flashjazzcat]

Second trickiest part of scrollbars out of the way now: as well as specifying the size of the scroll handle, it's now possible to specify its position using an integer value 0-255. 0 is always the extreme left/top, while 255 is the extreme right/bottom. This works regardless of the size of the scrollbar or handle. I tested the routine by issuing a move_handle call using various values after the resize event. In all cases, the scroll handle stayed in the correct position.

 

The math is quite interesting, although a real headache in the first instance. To avoid fractional calculations, everything is first multiplied by 32. The "travel" of a scroll handle (in pixels) is the width of the scroll bar itself, minus the width of the handle. The smallest "travel" being 8 pixels (in the case of the horizontal scroll bar), to successfully arrive at our "single unit" value, we say:

 

(travel * 32) / 256

 

The smallest result will be 1, given our minimum travel of 8 pixels. We then multiply this value by the desired scroll handle offset (0 - 255), and divide the result by 32 again, to yield a pixel offset, before rounding up by 1 and ANDing with $F8 to keep the position in multiples of eight.

 

Looking at the above sum again, of course, it became obvious that (travel * 32) / 256 is the same as travel / 8. So:

 

( (travel / 8 ) * offset) / 32

 

rounded up and ANDed with $F8 gives us a byte aligned pixel offset for the scroll handle. The only non-shift calculation is when we multiply by offset (0 -255).

 

The scrollbar control will also return 0-255 as the result of handle drag operations, although the ganularity will obviously be quite coarse when the scrollbar is short. For finer control, the up/down arrows should be used, which will also return an event to the application.

 

The upshot of this is that - when writing a text editor, for example - simple math is required to update the scroll bars:

 

(lines in document / 256) * (offset in lines to top of page) = scroll bar offset

 

Of course, one must also first establish the size of the proportional scroll bar handle by calculating the height of the visible page as a fraction of the document length.

Edited March 17, 2011 by flashjazzcat

[flashjazzcat]

Bloody scroll bars...

 

Finally arrived at a solution I like. When updating window properties (following a resize event or prior to initial window rendering), you specify the "document" size in pixels for each scroll bar, and the range or tracking (i.e. the extent of the document not visible in the client area).

 

So, for example, if your content is 512 pixels wide, and your maximized client area is 312 pixels wide, the tracking is 200 pixels. You just pass the tracking range and the document width to the scrollbar via an update call, and the scrollbar does all the scaling calculations for you in accordance with the current size of the window. This to me seems MUCH easier than the app having to do lots of percentage calculations or other math. To move the scroll bar, you just call the update routine with any value inside the tracking range. No need to worry about converting the value to a percentage, or value between 0-255. You just use the actual offset into your document.

Edited March 18, 2011 by flashjazzcat

[danwinslow]

Yes, that makes sense, and has the added benefit of encapsulating the calc inside the system...so if it changes the apps won't have to be rebuilt. Abstraction ftw.

Edited March 18, 2011 by danwinslow

[flashjazzcat]

Thanks Dan: always good to know when I've done something right. This approach to scroll bars is closer to that of the Windows API than GEM/TOS. It pretty much absolves the app of any complex workings-out.

 

Damn, though: these scrollbars are generally the trickiest thing in the whole GUI, primarily because they're about the only control which has to be scalable. The previous approach I was toying with (indexes of 0-255) seemed reasonable until I realized the onus this placed on the application. And still, there are off-by-one errors and rounding up to contend with (for example, it's desirable that when the thumb is at the right edge of the scroll bar, that's the only time it returns the maximum tracking offset to the application). I'm pretty much there with it now, though.

 

It'll be time to start documenting the data structures and calls soon: the API is now sufficiently complex that I require documentation for my own reference.

[pixelmischief]

Thanks Dan: always good to know when I've done something right. This approach to scroll bars is closer to that of the Windows API than GEM/TOS. It pretty much absolves the app of any complex workings-out.

 

Damn, though: these scrollbars are generally the trickiest thing in the whole GUI, primarily because they're about the only control which has to be scalable. The previous approach I was toying with (indexes of 0-255) seemed reasonable until I realized the onus this placed on the application. And still, there are off-by-one errors and rounding up to contend with (for example, it's desirable that when the thumb is at the right edge of the scroll bar, that's the only time it returns the maximum tracking offset to the application). I'm pretty much there with it now, though.

 

It'll be time to start documenting the data structures and calls soon: the API is now sufficiently complex that I require documentation for my own reference.

 

 

If the scale on the bars gets too expensive, you could always have the bars remain a fixed size and just vary the "steps" between the extremes.