Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: Early version small screen graphics library

  1. #1
    Junior Member
    Join Date
    Jan 2017
    Posts
    15

    Early version small screen graphics library

    Hi everyone,

    I have written a library that (I think, at least) markedly simplifies managing a simple graphical user interface on the ILI9341 and similar. It so far written expressly for Teensy 3.5 and 3.6 but should be a very straightforward port.

    The code separates out the parameters for each graphical element into a line item in a file that is stored on an SD card. At startup, the parameters are written into RAM and then drawn on the screen. Each element on the screen belongs to a virtual window, so it is possible to not only draw a single object, but there is a command to draw an entire window as well.

    Each element can also act as a button. The code requires a single function call in the main loop that polls for a touch. If a button is touched, the function returns the unique ID of the element touched. Actions can then be executed by a switch/case block.

    So far, I've only written code for three types of ojbects: a rectangle, circle, and text block. Colors of elements can be changed during execution of the program, as can text content. Activity as a button can also be turned on and off.

    I think this approach offers several advantages. First, if you want to add a purely "decorative" element (doesn't act as a button, doesn't need its color or text changed during execution), no additional code is needed. Simply add a line to the rsrc.txt file containing the necessary information and the item will appear the next time the program runs. Second, if you are working on the esthetics of the GUI, you can move an item around on the screen by twiddling the parameters. No recompilation needed, and button functionality will tag happily along. No fixes to that code needed either. Third, language localization becomes much easier. From a control standpoint, I think building a case/switch statement that runs from an item number is much easier.

    Runtime functions include the loop polling function as well as an ability to change foreground, background colors on the fly and perhaps most importantly to change text on the fly. Drawing individual objects and virtual windows can handle (as I said before) circles, text, and rectangles. I was going to put in the ability to draw a bitmap, but that got very complicated very quickly, and I didn't have the energy or interest/need for my purposes to pursue it. I still want to put in a couple more simple elements such as a line and a triangle. I also eventually want to write this such that a parameter line can describe an object's size and position as an expression of screen size (e.g., top/left of rectangle 1/4 of y length and 1/8 x length, height .15 of screen y dimension and width .25 of screen x dimension). This would allow for better planning and would make porting code to a different screen much easier.

    My work on this got sidetracked when I started building a website for my wife's music teachers association. I suspect many of you out there are much better programmers than I am, and I hope someone can run with the basic ideas I put out there. However, attribution would be greatly appreciated.

    Code, more description at [URL="http://github.com/edringel/ssgui"]

    Cheeers,

    Ed

  2. #2
    can you post some images or a video of the code in action? I'm always messing with TFT displays, drawing graphics and such. Maybe this is something I can use.

  3. #3
    Senior Member Projectitis's Avatar
    Join Date
    Feb 2018
    Location
    New Zealand
    Posts
    174
    Hehe heh. I'm working on an almost identical library as part of a larger project. All to be released when it's presentable, of course

  4. #4
    Junior Member
    Join Date
    Jan 2017
    Posts
    15
    Hi Projectitis and KrisKasprzak,
    thanks for your replies. Right now, I don't have the time to put up pix or a video. I'll try and put up some pix over the next few days.
    Projectitis, looked at the thread you started. I'm handling this differently. Each object on the screen belongs to a parent generic class. This class contains drawing information common to any object such as color, which window it belongs to, its touch area, etc. Specific object types, such as text, a rectangle, etc, are instances of child classes derived from the parent class. That instance contains specific information such as position on the screen, text content, etc. We diverge in that none of these classes contains a drawing method. The drawing method (as opposed to the drawing information) is held in a drawObject function which belongs to the SSGUIScreen object. The drawObject function looks at the information, figures out what kind of object it is, then calls the function to draw a rectangle, circle, etc. Each of those methods is just a wrapper method for the hardware specific function. I thought about the whole issue of how quickly the functions would execute, and from a programming elegance standpoint I agree it's not great to be hopping around the stack. However, for my purposes (i.e., doesn't need game-like speed) it works fine. My greater concern was memory, and the amount of information carried in each object is less than 100 bytes (except for text, and even then, just sometimes.) The other two things I really wanted to achieve was simplifying response to a touch and being able to tweak screen position, color, etc, without recompiling and rewriting to program memory. From my perspective, I've achieved that. I have benefited from so many other people sharing their code that I felt that putting this out there would be of use to someone, and I wanted to give something back.
    Ed

  5. #5
    Senior Member Projectitis's Avatar
    Join Date
    Feb 2018
    Location
    New Zealand
    Posts
    174
    Hi Ed,

    Actually, from your description, our GUI classes work very similarly. And it's also the "normal" way to implement a GUI, so it's great you've done it that way This is what my hierarchy looks like:

    Code:
    Display adapter (handles hardware. Implemented differenty for each display type)
    	|
    Graphics class (handles drawing primitives and color. Does not change with hardware.)
    	|
    Display list (list of "Display objects" to draw)
    		|
    	Display object (an object to draw. Can be a window, panel, textboxbutton etc. Contains position and size info etc)
    			|
    		Child display objects (Can be a window, panel, textboxbutton etc.)
    				|
    			Child display objects (etc)
    	Display object
    	Display object
    	...
    Similarly to your description, a display object is the generic class, and then, other classes are sub-classed as appropriate, like this:

    Code:
    Display Object
    	|
    	Panel
    		|
    		Window
    		
    Display Object
    	|
    	Text Label
    	
    Display Object
    	|
    	Button
    		|
    		Toggle button
    
    etc
    The discussion in that linked thread was only pertaining to how to handle the "graphics adapter" part of the code.
    Good on you for attaining your project goals, and for sharing

    Cheers,
    Peter

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •