R6502A Posted March 14, 2011 Share Posted March 14, 2011 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. Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted March 14, 2011 Share Posted March 14, 2011 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. Quote Link to comment Share on other sites More sharing options...
+JAC! Posted March 14, 2011 Share Posted March 14, 2011 Couldn't resist - 30 years of power without the price PM underlay would be a nice eye catcher for sure. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 15, 2011 Author Share Posted March 15, 2011 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... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 16, 2011 Author Share Posted March 16, 2011 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 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted March 16, 2011 Share Posted March 16, 2011 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! Quote Link to comment Share on other sites More sharing options...
+Philsan Posted March 16, 2011 Share Posted March 16, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
fibrewire Posted March 16, 2011 Share Posted March 16, 2011 I would very much like to use my CX22 with the OS. Then I could say "FINALLY! A legitimate use for this thing!" Quote Link to comment Share on other sites More sharing options...
fibrewire Posted March 16, 2011 Share Posted March 16, 2011 Seriously though, using the trak-ball would be great! Quote Link to comment Share on other sites More sharing options...
fibrewire Posted March 16, 2011 Share Posted March 16, 2011 Oh, nearly forgot Your Atari GUI OS would make a great window system for ContikiOS Quote Link to comment Share on other sites More sharing options...
Mr.Amiga500 Posted March 17, 2011 Share Posted March 17, 2011 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) Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted March 17, 2011 Share Posted March 17, 2011 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 17, 2011 Author Share Posted March 17, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
jvas Posted March 17, 2011 Share Posted March 17, 2011 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? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 17, 2011 Author Share Posted March 17, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
OldAtarian Posted March 17, 2011 Share Posted March 17, 2011 Can an unmodded ST mouse be used with it? (both buttons functional) Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 17, 2011 Author Share Posted March 17, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted March 17, 2011 Share Posted March 17, 2011 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... Quote Link to comment Share on other sites More sharing options...
Mr.Amiga500 Posted March 17, 2011 Share Posted March 17, 2011 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 17, 2011 Author Share Posted March 17, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 17, 2011 Author Share Posted March 17, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 18, 2011 Author Share Posted March 18, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
danwinslow Posted March 18, 2011 Share Posted March 18, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 18, 2011 Author Share Posted March 18, 2011 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. Quote Link to comment Share on other sites More sharing options...
pixelmischief Posted March 19, 2011 Share Posted March 19, 2011 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.