GUI Library

[yock1960]

Here are two programs that demonstrate a small library of GUI functions. One demo program simply demonstrates the different GUI objects that are available: Buttons, Textboxes, Checkboxes, Radio Buttons, Progress Bars, Sliders and Frames. The other demo program is a calculator program, which uses Buttons, Textboxes and a Frame. This GUI library I ported from code written in MMBASIC which can be viewed here (http://www.fruitoftheshed.com/MMBasic.A ... -pack.ashx), along with the description of the objects and their parameters. Currently this code is written in Prog8, using Prog8's GFX2 graphics routines in mode 4 (320x240x8). The GUI code is contained in 2 Prog8 code blocks, one for the code, called 'GUI' and one for the data structure for the objects, called 'object'. Ideally, this would be written as code that could be located in upper memory, or perhaps even in HIRAM, with function calls useable by any language. This would also need to be done for the GFX2 routines, I haven't attempted this yet. Prog8 is not difficult to learn, so anyone wanting to try this code, can simply get hold of it and start trying it. Also, if desired, someone could port this to CC65 or whatever. The original author makes it plain on the web page, that the code is free to use and no license is cited.

The calculator program...my first such, was I suspected, going to be somewhat tricky...it was...is. There are occasional bugs...unexpected results of input...I've spent more than enough time on it however. It mostly works and is, after all, only a demonstration program. The demo program GUI is the original develpment version of the code and it is recommended that it not be used for further development, but only as an example on how the other objects are coded.

The GUI library is certainly a simple way to add a clean...modernish UI to a program. More could be done to flesh out the GUI library, but there is enough here to start with!

Try It Now!

[desertfish]

Very cool!

[ahenry3068]

Thats awesome. I'm stoked to see it be a library for all programming languages

[ahenry3068]

The buttons look kind of like what I'm doing in Hangman for the Letter Choosing Control Panel.

[Adiee5]

since you're sharing the source code i guess making a github repo'd be a good idea

[yock1960]

Probably so. However, I have never seriously considered creating a Github account. Also, if I were to do that, I think I should talk to the original author first, especially as I have no idea of the considerations concerning 'ported' code.

[yock1960]

One of the ideas that I had in my head, for after getting the GUI code ported and working, was to incorporate the ability
to allow saving the screen under the objects, so that they could be hidden and restored in a non-destructive way. There isn't
enough VRAM to allow buffering the entire 320x240x8 screen, so it needed to be done 'per object'. Additionally, while there is a fair amount of VRAM free, it can get dicey if you have multiple sprites/cursors defined, so I decided to use High RAM, as there is plenty of that, for my uses at least.

As a demonstration, I took an existing program of mine, which used the text layer to display...textual information, which worked fine for the most part, except that when the palette is modified, which in this case, the first 16 entries are fixed and are used for the text, the rest are shifted 16 places at a time. Some shifts made it difficult to read the text. Not a huge deal, but neither was it ideal. GUI to the rescue! No more contrast issues and with the added benefit of moving from a mouse and keyboard interface to one that is now almost entirely mouse based, which I like rather better! Now, the only keypress a user need remember is ESC to 'summon' the UI back into view. We won't get into the 'inappropriateness' of this program on this platform (Julia/Mandelbrot Sets)...it's just one of my interests and one that would have been cool back in the day!

Before doing any of this however, I needed to get away from using Prog8's GFX2 graphics library. It's a nice library, but it is a memory hog! The GUI library now uses the ROM based graphics routines, which saves about 4k of memory. I did need to 'borrow' the 'disc' command from GFX2, as the 'Oval' routine has not been incorporated into the current ROMS. Using the ROM based graphics routines are not quite as convenient, as rather than including the desired color for the object in your subroutine call, a separate call to set the 'stroke, fill and background' colors must be made. Also, there is only an output character routine, although building a 'put_string' command together is relatively simple. One thing that changed in doing this, which I discovered by accident, is that the text displayed is smaller and no longer a fixed character size. There is....probably...a way to get back to that fixed size font, but I haven't figured it out yet. For this project I like the smaller font better, I don't think it would be as useful for the calculator program however. The variable sized characters also
make justification of text problematic. I think that to avoid having separate libraries a) I need to figure out how to access all of the available fonts and b) handling the fixed and variable sizes of text needs to be accounted for in the code. One other cool thing that moving moving away from GFX2 makes possible, is adding a 'rounded corner' style to the now, currently, square edged objects! Is it worth the extra code space this would require? I haven't completely optimized this program from the previous version. Prog8 removes unused code, but there still maybe some redundant code. The older version was about 8K smaller, so 19K versus 27K. The 'ideal' would be to move the approximately 8k into high RAM,
actually less, since some of that is 'user program code and data'. I have done no work towards moving the GUI library into a 'high RAM library'.

Making the changes revealed a flaw in my text handling....something I've run into before...but I hadn't learned my lesson! I don't know how the calculator program didn't have more issues! Actually, I think it did (does?), but I coded around it, without fully realizing what was going on! This had me scratching my head, until I finally got to looking at one of Irmen's example programs. In short, it's the old...pointers point but don't allocate! String arrays (str type) are pointers....I'm not even going to try to explain it, as I'll probably not get it right even now! Indirection is not my strong suit! I believe I finally have it squared away however.

I'm still playing around with all of this. The code for allocating high memory, saving and restoring VRAM to HRAM and tying that to the GUI objects has not been integrated into the GUI library. I'm not sure that I want to do that at this point. For one thing, it's not needed at all in the case of a program such as Calca, but there are certainly use cases for it. Maybe the best thing to do would be to make it into it's own small library of code, to be included as needed.

[desertfish]

Hi, gfx2 is pretty large because it supports various display modes all in 1 library.
Note that for the upcoming next version of prog8 I've removed the monochrome display mode support from it and it should be a lot smaller. (there will be a new, separate, library module to support the monochrome modes specifically).


Also note that there is the "graphics" library module as well, it can draw stuff including circles and discs for you AND uses the kernal graphics routines to draw stuff - so it is a lot smaller than gfx2

[yock1960]

Hi, gfx2 is pretty large because it supports various display modes all in 1 library.
Note that for the upcoming next version of prog8 I've removed the monochrome display mode support from it and it should be a lot smaller. (there will be a new, separate, library module to support the monochrome modes specifically).


Also note that there is the "graphics" library module as well, it can draw stuff including circles and discs for you AND uses the kernal graphics routines to draw stuff - so it is a lot smaller than gfx2

It's been a while since I looked at the graphics library in any detail, since GFX2 is nice, but it has the same issue as I recall, of needing a separate call for color changes. Not a huge deal, just not as convenient and the order of the parameters isn't set in my mind yet. I suppose I could write mimic routines...but that seems wasteful. I believe that I'm still importing 'graphics', I dont recall what for at the moment.