Go Down

Topic: PixiGui V0.0 (Read 336 times) previous topic - next topic

arctos

Dec 07, 2017, 05:36 pm Last Edit: Dec 07, 2017, 09:28 pm by arctos
So what is PixiGui

First and foremost it is a work in progress so if your looking for a fully functional library this is not it YET!

This requires a Mega minimum (will not work on a Uno).

I have chosen to post my code (proof of concept) here and now in the hope that the wisdom of the crowd will positively influence my project. So while I believe my design is sound I'll openly admit that I have been away from C++ for awhile and my code may not be as elegant as I would like.  So all Constructive Criticism is Welcome.

I've followed the standard of including an 'Example' folder but in all honesty these are tests, so if you start at the start you may get way board before you see something worth looking at. So I suggest starting with 'MarginsAndAlign' and  'MovingImageButtons'. But I have to admit until I offer the full library this whole system may seem like a lot of effort for very little gain.


Under the bonnet..

Pixi controls are broken into 2 basic groups. Host and Element
As the names suggest a host can contain other controls (including other hosts) so hosts are also elements..
While a pure element control is a base unit that simply does what it does and must be contained within a host.
All parameters regarding location and alignment of a control are relevant to their host not the screen..

At the moment we have.

Host:
 Page
   NavPage (not functional)
 Border
 StackPanel

Element:
 TextBlock
 Button
   TextButton    
   ImageButton


And that's it (for proof of concept)

But now that the core concepts have been solved the inclusion of
 TextBox (input that requires a keyboard)
 ToggleButton
 Checkbox
 Switch
 Slider
 Menu etc.

are not to far behind.


PixiGui works on a 4 pass system.

1. Measure. All controls are given a maximum space that they can occupy and are required to respond with the space they will require.

2. Layout. Having given the parent control their space requirements a control is now given it's allocated space and a co-ordinate in which to operate.

3. Erase. At this point each control is given the chance to erase from the screen any unwanted artefacts of previous renders.

4. Render. Now knowing it's available space and location a control can draw itself to the screen.

Notes

** The 'Read Me" files are very limited at this point.
** At the moment this is aimed at a 320 x 240 TFT LCD and uses the MCUFRIEND_kbv library.
** This has only been tested on a 8 bit parallel system (no SPI) but should work? maybe? With required pin changes. (look in the GUI.h file for Touchscreen)


I have taken and learnt so much from the free programming community over the last decade, and it's time to give back.


Dan B







 

arctos

Something I feel I need to point out.
If you run my test /examples  you may find yourself thinking "sorta cool but how often do I want to move my layout"
Chances are not very often. But since Pixi is Page orientated system (sorry no proof yet) and the overhead of all controls is 36 bytes min (for now). Why would I create all new controls  that I need for my next page? When I can use a pool of controls I have and simply re-purpose them. So while you may never need to re-position / re-color a piece text or a button on any page. The ability to do so makes all controls (except for the Page) re usable elsewhere.

pert

I recommend publishing your library on GitHub, which makes it very easy for people to browse the source code, report bugs, and submit proposals for enhancements/bug fixes. You can still use this thread as a support/discussion thread.

arctos

Good advice and I have every intention of doing that as soon as I have the rest of the system in place.

Go Up