impulseadventure / guislice Goto Github PK

Hii,
I am using GUIslice to built UI for my Project and i am using Waveshare 7inch HDMI LCD.
When i tried to built Using MAKEFILE present in linux
For First case : No Touchscreen enabled it works fine
But when I run Second program i am getting this error
ERROR : DrvInit() error in SDL_Init(): Unable to open /dev/fb1
ERROR : Init() failed

Currently, the Travis-CI creates automatic test builds for Arduino UNO and ATmega2560. I think it would be very helpful to add support for a few of the other compilation targets, such as:

• Raspberry Pi (w/ SDL1.2)
• ESP8266 (w/ TFT-eSPI)
• ESP32 (w/ TFT-eSPI) / M5Stack
• STM32 (w/ Adafruit-GFX-AS)

If someone has familiarity with Travis-CI and wants to try adding new entries for any of the above (into .travis.yml), it would be greatly appreciated.

It would be useful to support dynamic displays that show / hide GUI elements on the basis of the current state (e.g. A button that is only visible when a radio button / checkbox is set). This may just involve adding a ElemSetVisibleEn() and then integrating this with the existing redraw functionality. The visibility status could potentially be stored by expanding tsElem:bValid into a multi-bit state field.

Add support for alert / input dialog boxes that overlay a portion of the existing display.
The following implementation would allow user to continue seeing the other controls (not hidden by the dialog) continue to update in the background.

One implementation might be the following:

• Add a Boolean indicator bit in the element reference array to mark the start of a new layer
• LayerAdd() function marks the next Element in the current page as beginning the layer. This first element should probably be a box with a filled background (the base for the dialog). This function also records the ID for this layer base element
• create elements as normal (text, buttons)
• in user main loop, they can optionally determine whether the dialog buttons are active by querying for the active layer ID
• if user main loop observe alert ok / cancel / etc button that is supposed to clear the dialog then LayerDelete() is called
• LayerDelete() will remove element last references from top of stack and then wind back the current layer ID value

Optimize the rendering of the scrolling Textbox on slow displays/processors (such as Arduino).

• Goal: minimize flicker when text lines are scrolled up.
• Ideal method: use a graphics RAM copy (within ILI9341) to shift old lines up on the display without having to redraw all characters.
• Alternate optimization: batching of consecutive character options into string operations. One complexity would be in handling color change requests part-way along a row.

In GUISlice_ex, we are missing a function to reset the buffer of the XTextBox element.

Cal has proposed:
It should be easy to add a gslc_ElemXTextboxReset(pElem) which would perform something like the following:
gslc_tsXTextbox* pBox;
pBox = (gslc_tsXTextbox*)(pElem->pXData);
pBox->nBufPosX = 0
pBox->nBufPosY = 0
memset(pBox->pBuf,0,pBox->nBufRowspBox->nBufColssizeof(char));
gslc_ElemSetRedraw(pElem,GSLC_REDRAW_INC)

When adding the XPT2046 (pull request "Adding rotation depending display width and heigth setting for ILI9341") I copied some code from the DRV_TOUCH_ADA_SIMPLE. Here I'm not sure if the last command below is a typo and should read nRawPress=p.z; instead of nRawPress=p.x;
Best regards.

#elif defined(DRV_TOUCH_ADA_SIMPLE)

TSPoint p = m_touch.getPoint();

pinMode(XM, OUTPUT);
pinMode(YP, OUTPUT);

if (p.z > 10 && p.z < 1000) {

nRawX=p.x;
nRawY=p.y;
nRawPress=p.x;

To support memory-constrained targets (such as Arduino), it would be useful to have some limited support for buttons but without the full overhead of the gslc_tsElem structure.

Does GUIslice support Polish characters?

ą, ć, ę, ł, ń, ó, ś, ź, ż

Issue filed by neoengineer on ImpulseAdventure website:

GUIslice is a great library - Thank you! I ma having a issue with the behavior of the text box created with gslc_ElemXTextboxCreate. The text always seesm to start in the middle of the box, even after a call to text box reset. I am using an adafruit feather M0 and an adafruit 480x320 display. Eveything else appears to work. You can see this behavior using gslc_ex10_ard. I experimented by reducing the TBOX_ROWS value to force "a no scroll" and the text then starts at the top of the text box, but then wraps in the middle of the display. any help would be greatly appreciated.

Since the recent Adafruit-GFX library updates have added support for alternate fonts via setFont(), it would be good to incorporate this into GUIslice.

The existing ElemCreateTxt and ElemCreateBtnTxt elements render a single line of text.
This request is to explore the possibility of providing some degree of text wrap functionality.

I would propose the following capabilities (in order of decreasing priority):

• Support a manual forced-wrap via insertion of \n in the text string, enabling multi-line text
• Support default font (monospaced) as well as extended fonts (proportional)
• Support a character wrap mode based on the element bounds
• Consider an optional mode to support word-wrap rather than character-wrap

What about to add support of Waveshare e-ink display
for example [https://www.aliexpress.com/store/product/264x176-2-7inch-E-Ink-display-HAT-for-Raspberry-Pi-Three-color-SPI-Interface-No-Backlight/407494_32829483976.html?spm=2114.12010612.0.0.77a1556bNme7S9]

for example GxEPD (base class is a subclass of Adafruit_GFX)
support AVR, STM32Duino
https://github.com/ZinggJM/GxEPD

you can use as driver

?

After configuration, when running example 7, the device crashes with a fatal exception(28) on gslc_Update being called

Since
e3541cd Fix-potential-crash-in-FontAdd()-if-LINUX-font-file-doesn't-exist
Arduino does not work any more.

This is because

const void* gslc_DrvFontAdd(gslc_teFontRefType eFontRefType,const void* pvFontRef,uint16_t nFontSz)
{
  // Arduino mode currently only supports font definitions from memory
  if (eFontRefType != GSLC_FONTREF_PTR) {
    GSLC_DEBUG_PRINT("ERROR: DrvFontAdd(%s) failed - Arduino only supports memory-based fonts\n","");
    return NULL;
  }
  // Return pointer to Adafruit-GFX GFXfont structure
  return pvFontRef;
}

returns null for Arduino and
e3541cd
adds
const void* pvFont = gslc_DrvFontAdd(eFontRefType,pvFontRef,nFontSz); if (pvFont == NULL) { return false;
in GUIslice.c

Hi,

I am trying to use this library in a M5Stack board. I have configured the ard.h file to the proper options but the compilation failed because ILI9341 does not exist.

It seems like M5Stack headers do not provide this class anymore. I replace the definition with the global display object and it worked.

-  ILI9341 m_disp = ILI9341();
+ #define m_disp m5.Lcd

Is this a bug? Probably the upstream library update broke the symbol.

Running this example on Feather M0 and Featherwing 2.4, the touch screen is not working.
Problem is the screen size return 0,0 after the extended components are created.

Problem is fixed by changing line 51
#define MAX_ELEM_PG_EXTRA_RAM MAX_ELEM_PG_MAIN // # Elems in RAM
to
#define MAX_ELEM_PG_EXTRA_RAM MAX_ELEM_PG_EXTRA // # Elems in RAM

Given the number of TFT display modules, graphics libraries and configurations modes supported by GUIslice, it is not practical to use a manual approach to testing new release combinations. An automated regression suite to test the Arduino IDE compilation and Raspberry Pi targets is essential.

Thankfully, I have recently come across the excellent Arduino-CLI which enables some automation. I will use this issue to capture the current status of this work, but I am always open to suggestions from others who may have experience in this area too.

At this point, a good portion of the supported platforms have already been integrated into the regression suite. I intend to include a selection of sample configuration files for a number of the platforms and TFT modules into the repo later.

TODO

• Travis-CI testing of releases / pull requests
  STATUS: Mostly done, but looking for help to add new targets mentioned in #58
• Regression for UNO
  STATUS: Done
• Regression for ATmega2560
  STATUS: Done
• Regression for ESP32 & M5Stack
  STATUS: Done. Required fix to arduino-cli (filed arduino/arduino-cli#73)
• Regression for ESP8266
  STATUS: Done. Had same issue as for ESP32
• Regression for Cortex-M0 (Adafruit Feather M0)
  STATUS: Done
• Regression for Cortex-M4 (nRF52)
  STATUS: Not started
• Regression for STM32 using STM32duino
  STATUS: Done
• Regression for STM32 using Arduino_STM32
  STATUS: Done (manual core install)
• Regression for LINUX / Raspberry Pi using SDL1.2
  STATUS: Done
  install)
• Regression for LINUX / Raspberry Pi using SDL2
  STATUS: Not started

Note that the above suite is primarily aimed at ensuring compilation is successful locally before pushing to the repository (wherein travis-ci will perform a limited sanity check). A matrix of the GUIslice examples and compilation modes are executed in the local regression. Later on, I'd like to devise a suitable way to confirm that runtime operation is as expected too.

The Arduino-CLI will be used for all \arduino and \arduino-min targets, whereas direct compilation (with SDL in LINUX) will be used for the \linux (Raspberry Pi) targets.

For reference, I am running the regressions in a Xubuntu 16.04 VM using Windows 10.

From @imalipusram #48:

Hi Calvin!

Got a new ESP32 (NodeMCU-32S) and tested the examples (ILI9341 w/o touchscreen, waiting for an ILI9488 with touchscreen to arrive) and did some tests:

Examples 1..4 compile and seem to run ok as far as I can see.

Example 2 has warnings:

/home/wo/Arduino/libraries/GUIslice/arduino/gslc_ex02_ard/gslc_ex02_ard.ino: In function 'void setup()':
/home/wo/Arduino/libraries/GUIslice/arduino/gslc_ex02_ard/gslc_ex02_ard.ino:57:19: warning: unused variable 'bOk' [-Wunused-variable]
   bool            bOk = true;
                   ^

Examples 1..4 have these warnings:

/home/wo/Arduino/libraries/GUIslice/src/GUIslice_ex.c: In function 'gslc_ElemXCheckboxFindChecked':
/home/wo/Arduino/libraries/GUIslice/src/GUIslice_ex.c:792:18: warning: comparison is always true due to limited range of data type [-Wtype-limits]
     if (nCurType != GSLC_TYPEX_CHECKBOX) {
                  ^
/home/wo/Arduino/libraries/GUIslice/src/GUIslice_ex.c: In function 'gslc_ElemXTextboxDraw':
/home/wo/Arduino/libraries/GUIslice/src/GUIslice_ex.c:2187:21: warning: variable 'bEncUtf8' set but not used [-Wunused-but-set-variable]
   bool              bEncUtf8;
                     ^

Example 5 yields an error:

gslc_ex05_ard:63: error: 'gslc_tsXSelNum' does not name a type
 gslc_tsXSelNum              m_sXSelNum[3];
 ^
/home/wo/Arduino/libraries/GUIslice/arduino/gslc_ex05_ard/gslc_ex05_ard.ino: In function 'bool InitOverlays()':
gslc_ex05_ard:152: error: 'm_sXSelNum' was not declared in this scope
   pElemRef = gslc_ElemXSelNumCreate(&m_gui,E_ELEM_COMP1,E_PG_MAIN,&m_sXSelNum[0],
                                                                    ^
gslc_ex05_ard:153: error: 'gslc_ElemXSelNumCreate' was not declared in this scope
     (gslc_tsRect){160,60,120,50},E_FONT_BTN);

Example 6 yields errors, too:

/home/wo/Arduino/libraries/GUIslice/arduino/gslc_ex06_ard/gslc_ex06_ard.ino: In function 'bool CbDrawScanner(void*, void*, gslc_teRedrawType)':
gslc_ex06_ard:118: error: narrowing conversion of '(((int)nX) + -30)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFrameRect(pGui,(gslc_tsRect){nX-30,nY-20,60,40},GSLC_COL_BLUE_DK2);
                                           ^
gslc_ex06_ard:118: error: narrowing conversion of '(((int)nY) + -20)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFrameRect(pGui,(gslc_tsRect){nX-30,nY-20,60,40},GSLC_COL_BLUE_DK2);
                                                 ^
gslc_ex06_ard:123: error: narrowing conversion of '(((int)nX) + 1)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFillRect(pGui,(gslc_tsRect){nX+1,nY+1,10,10},GSLC_COL_RED_DK2);
                                          ^
gslc_ex06_ard:123: error: narrowing conversion of '(((int)nY) + 1)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFillRect(pGui,(gslc_tsRect){nX+1,nY+1,10,10},GSLC_COL_RED_DK2);
                                               ^
gslc_ex06_ard:124: error: narrowing conversion of '(((int)nX) + 1)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFillRect(pGui,(gslc_tsRect){nX+1,nY-10,10,10},GSLC_COL_GREEN_DK2);
                                          ^
gslc_ex06_ard:124: error: narrowing conversion of '(((int)nY) + -10)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFillRect(pGui,(gslc_tsRect){nX+1,nY-10,10,10},GSLC_COL_GREEN_DK2);
                                               ^
gslc_ex06_ard:125: error: narrowing conversion of '(((int)nX) + -10)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFillRect(pGui,(gslc_tsRect){nX-10,nY+1,10,10},GSLC_COL_BLUE_DK2);
                                          ^
gslc_ex06_ard:125: error: narrowing conversion of '(((int)nY) + 1)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFillRect(pGui,(gslc_tsRect){nX-10,nY+1,10,10},GSLC_COL_BLUE_DK2);
                                                ^
gslc_ex06_ard:126: error: narrowing conversion of '(((int)nX) + -10)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFillRect(pGui,(gslc_tsRect){nX-10,nY-10,10,10},GSLC_COL_YELLOW);
                                          ^
gslc_ex06_ard:126: error: narrowing conversion of '(((int)nY) + -10)' from 'int' to 'int16_t {aka short int}' inside { } [-Werror=narrowing]
   gslc_DrawFillRect(pGui,(gslc_tsRect){nX-10,nY-10,10,10},GSLC_COL_YELLOW);
                                                ^
cc1plus: some warnings being treated as errors

Example 7 compiles and runs,
Example 10 compiles and runs.

Best regards,
Wolfgang

Originally posted by @imalipusram in #48 (comment)

Thank you for your great software! Compiling and running it on ESP32 with ESP-IDF. Enjoying it a lot. :)
Issue below:

Problem:
I am presenting data on different pages (e.g. Log, Settings, etc..). I also want to display some status information all the time (battery status, wifi connectivity, etc.), regardless of which page is selected. At the current moment, I would need to create a separate 'Status page' and switch to it periodically (or on request), or I would need to create an element multiple times for each page, and update all of them,

Idea:

1. Option: Elements can be added to multiple pages at once
2. Option: Multiple pages can be displayed at once: display the "banner" page on top of another page (either in horizontal/vertical direction or in layer direction).

With both options, the library user needs to be mindful of leaving space for the "Status" related elements (either leaving space inside the page for these elements, or leaving space as the area will be overlapped by a status page). But I think this is not an issue, as it does not differ much from the current situation. After all, we are doing embedded programming and not some HTML ;)

I could imagine possible necessary code changes would relate to issues #9 and #24

I am currently looking at the code, see if I can add this functionality to my fork. Is this functionality that could be added rather easiliy (by myself) or do you think this would require more rework / is not possible?

(I also added drivers/support for loboris TFT driver for ESP32, let me know if you'd like a pull request - currently a bit concious of my coding and git abilities)

Bug in current code causes a zero value to be omitted when using debugger output (lightweight printf).
Should be an easy fix in gslc_DebugPrintf().

Currently gslc_DrvDrawImage supports rendering images from PROGMEM (Flash) if they are monochrome. It would be very useful to support color bitmaps as this would enable much faster image/icon/button redraw than having to depend on reading images from an SD card.

Add feature to support rudimentary clipping (via DrvSetClipRect()) in the Adafruit-GFX driver layer (GUIslice_drv_adagfx). As not all users will require clipping, consider adding #define to enable support with no performance cost to those who don't need it.

using the dynamic gslc_DrvRotateSwapFlip() does not work for me going from landscape to portrait.
The function does not exchange
pGui->nDispW
pGui->nDispH
in the case that the swap setting changes.
I can try to do a PR fixing this taking in mind that this also requires an update of
// Defaults for clipping region
gslc_tsRect rClipRect = {0,0,pGui->nDispW,pGui->nDispH};
gslc_DrvSetClipRect(pGui,&rClipRect);

Setting:
#define DRV_TOUCH_XPT2046

Arduino: 1.8.5 (Linux), Board: "Generic STM32F103C series, STM32F103CB (20k RAM. 128k Flash), BMP (Black Magic Probe), 72Mhz (Normal), Faster (-O2)"

/home/goki/Arduino/libraries/GUIslice/src/GUIslice.c: In function 'gslc_ElemEvent':
/home/goki/Arduino/libraries/GUIslice/src/GUIslice.c:1989:7: error: a label can only be part of a statement and a declaration is not a statement
void* pvData = sEvent.pvData;
^
/home/goki/Arduino/libraries/GUIslice/src/GUIslice.c:1990:7: error: expected expression before 'gslc_tsElemRef'
gslc_tsElemRef* pElemRefTracked = NULL;
^
/home/goki/Arduino/libraries/GUIslice/src/GUIslice.c:2000:7: error: 'pElemRefTracked' undeclared (first use in this function)
pElemRefTracked = pElemRef;
^
/home/goki/Arduino/libraries/GUIslice/src/GUIslice.c:2000:7: note: each undeclared identifier is reported only once for each function it appears in
/home/goki/Arduino/libraries/GUIslice/src/GUIslice.c: In function 'gslc_InitTouch':
/home/goki/Arduino/libraries/GUIslice/src/GUIslice.c:2921:3: warning: implicit declaration of function 'gslc_TDrvInitTouch' [-Wimplicit-function-declaration]
bOk = gslc_TDrvInitTouch(pGui,acDev);
^
/home/goki/Arduino/libraries/GUIslice/src/GUIslice.c: In function 'gslc_GetTouch':
/home/goki/Arduino/libraries/GUIslice/src/GUIslice.c:2946:3: warning: implicit declaration of function 'gslc_TDrvGetTouch' [-Wimplicit-function-declaration]
return gslc_TDrvGetTouch(pGui,pnX,pnY,pnPress);
^
...
Error compiling for board Generic STM32F103C series.

The current checkbox / radio button implementation registers a default touch callback function (gslc_ElemXCheckboxTouch()) that handles basic checkbox / radio button operations. There is also a function gslc_ElemXCheckboxGetState() that can be used to fetch the current state of the checkbox.

However, it would be very useful to add a user-defined callback function that is invoked whenever a checkbox / radio button is toggled. This way the user code can take action upon a change in state, rather than polling for changes.

One implementation of this may be to add a callback function pointer member pfuncXToggle to the XCheckbox pXData structure. A new call ElemXCheckboxSetToggleFunc() would assign this callback (like in ElemXSliderSetPosFunc()) and then the callback would be invoked whenever ElemXCheckboxSetState() is called.

In an effort to increase robustness of the verification environment for GUIslice, I have been considering ways that I can improve the test coverage across the many display and configuration modes.

I have already created a compiler-based regression suite in #65 that enables me to test compilation under a wide range of modes for both Arduino, variants and LINUX. However, that suite only identifies issues that impact compilation.

My hope is to automate some of the testing for the library's runtime operation. I intend to use this issue to capture some thoughts on this potential feature, and would welcome anyone's input on the strategy.

One approach I am considering is the following:

• Create a GSLC_TOUCH_TEST driver. This driver would only be integrated if enabled in the configuration, so the test strategy shouldn't affect normal operation in any way.
• The Touch Test driver would emulate a touch device and accept a sequence file that dictates a set of coordinates (position and pressure). This sequence would be replayed in real-time (according to some cycle count markers), and then the GUIslice library would react accordingly.
• The net result would be that I could predefine a set of sequences to test each example.
• There would have to be some form of output from the library to confirm that various UI element interactions were as expected. Thus, after compiling and executing the test (eg. from Linux VM), the calling script could self-check the results and move on to the test configuration.
• The above could work quite well for testing the core GUIslice library functionality, but it may not directly offer the ability to test the code that is compiled specifically to Arduino and related variants.

Enhancements for Arduino runtime testing

• While testing the LINUX targets should be relatively straightforward (especially since the compiler and program execution can all output results back to the calling script), it seems much harder to support closed-loop automated testing of the Arduino runtime.
• One idea I had here was to potentially write local stubs for each of the Arduino-specific display libraries, which might enable me to execute the Arduino variant code on a LINUX gcc compiler. This way I could still perform some testing of the Arduino, ESP and Cortex builds in an automated runtime environment.

I just did a quick and dirty test, and implementing antialiased fonts seems feasible for at least Text Buttons and other elements where background color is known (?).
In gslc_DrvFontAdd() I added

  if (eFontRefType  == GSLC_FONTREF_FNAME){
    m_disp.loadFont((const char*)pvFontRef);
    return NULL;
  }

And was able to load the example antialiased font from the TFT_eSPI example from SPIFFS (which would be neat for images too, especially since TFT_eSPI supports jpeg). The lib also ignores the call to setTextFont(1) in the gslc_DrvDrawTxt* functions when we return NULL.
Then I hardcoded the background color in the two m_disp.setTextColor() calls, which also needs the BG color as second argument for blending against the background of the text.
It works and the output looks so beautiful, but it still needs some tinkering so the necessary BG color is chosen by the "parent" element's color, which might not be that obvious. Thrilling?

I am pleased to announce that @Pconti31 has managed to create a front-end GUIslice Builder desktop application that can help generate GUIslice layouts!

The cross-platform program includes a graphical editor that enables drag & drop placement of UI elements. Once a GUI has been laid out, the Builder can then generate the functional GUIslice skeleton framework code, for both Arduino and LINUX targets.

The generated output code (.c, .ino) includes all of the necessary defines, UI storage elements and initialization in addition to the placement of the UI elements. This should greatly improve the ease in creating a new GUI.

One nice feature is that the user is then able to add their custom application code to the framework and then continue to make UI revisions within the Builder.

Status: The GUIslice Builder tool is in very early beta testing at the moment. Initial beta release will include a java archive (.jar), with full source to follow later. Further updates will be posted to this issue.

Documentation: GUIslice Builder wiki (in progress)

Acknowledgements: A huge thanks again to Paul for taking the initiative on this!

As pointed out by @Bodmer in #15, GUIslice doesn't currently support the XPT2046 resistive touch controller.

I understand that the TFT_eSPI library already provides support directly, so I intend to start with that as a driver. Later, I may look at supporting PaulStoffregen's XPT2046_Touchscreen library for those who aren't using TFT_eSPI.

The DEBUG_ERR mode is a convenient means of debugging new GUI configurations as it enables a large number of debug output error messages throughout the code. By default, DEBUG_ERR is enabled in the configuration to assist new users.

The message format strings are stored in FLASH. On low-memory devices (such as the baseline Arduino), these error messages can account for a moderate amount of FLASH memory consumption (eg. 3.5KB).

Since most error messages are very similar in nature and only differ in the inclusion of the function name, it would seem that significant optimization may be available by sharing the message format strings globally. A set of common error message strings could thus be defined. Ideally, the general idea could be something along these lines: (note that a change may be required to handle the constant format string, ie. not calling PSTR in the macro expansion)
ERRSTR_NULL = "ERROR: %s() passed a NULL pointer\n";
... followed by the per-function usage:
GSLC_DEBUG_PRINT(ERRSTR_NULL,"ElemSetTxtStr");

GUIslice is currently most useful for displays that have touchscreens. However, it should also be possible to enable the GUI elements to be selected using either a keyboard (for Raspberry Pi) or buttons / switches (on Arduino, M5Stack and similar devices).

I was thinking of adding modes for these (such as DRV_TOUCH_KEY and DRV_TOUCH_PIN) and they would probably operate along these ways:

• A "next" key/button moves focus to the next GUI element, skipping over any elements that can't accept focus
• A "prev" key/button moves focus to the previous GUI element, skipping over any elements that can't accept focus
• A "select" key/button selects the currently focused GUI element
• The focused GUI element is shown by using the "glowing" color attribute
• The display begins with no element in focus
• One the next/prev advances past the last GUI element, it goes back to "no elements in focus" and then wraps back to the start
• Selecting an element will make the glowing state return to the normal fill state, and carry out the action
• Later, I might explore ways to handle sliders as well
• Elements would have a config bit that indicates if it can accept focus (eg. text elements can't, but buttons, checkboxes can, etc.)
• Focus order would be dictated solely by the element creation order (at least for now)
• Keyboard / pin binding would be maintained in a separate mapping structure

With the above, it may be possible to expand the usability of GUIslice to many other displays. In fact, I could enable the M5Stack driver to connect directly to this capability as the device has integrated buttons. E-ink displays could also benefit as they usually don't have touch screens.

Any feedback or suggestions on this idea would be greatly appreciated!

Migrating @rtwfroody comment from #10:

I'm experimenting with using the Bodmer/TFT_eSPI library in my project, which consists of an Adafruit Feather HUZZAH 8266 with the 2.4" TFT touch screen. Graphics display works great (fast!) with this setup (using #define DRV_DISP_TFT_ESPI), but I can't make the touch screen part work. #define DRV_TOUCH_NONE compiles and that's how I've been testing. I'd like to use #define DRV_TOUCH_ADA_STMPE610 but that code is deactivated in GUIslice_drv_adagfx.cpp by a check for DRV_DISP_ADAGFX early in that file. I may try to separate that out later, but I wonder if anybody has already done that.

Hi Tim! Yes, I can definitely add support for the Bodmer/TFT_eSPI mode to use Adafruit STMPE610 & FT6206 drivers for touch handling. I had started with the TFT_eSPI's integrated touch handling mode, but these other external drivers will be useful too. Your GUIslice_config.h file will just need to define DRV_DISP_TFT_ESPI and DRV_TOUCH_ADA_STMPE610. The only thing missing in the library should be the additional includes at the top of GUIslice_drv_tft_espi.cpp. I will be posting an update shortly for you to test.

What can be the problem here?

/media/nasFiler/Programmering/Arduino/sketchbook/libraries/GUIslice/src/GUIslice_drv_tft_espi.cpp: In function 'bool gslc_DrvGetTouch(gslc_tsGui*, int16_t*, int16_t*, uint16_t*)':
/media/nasFiler/Programmering/Arduino/sketchbook/libraries/GUIslice/src/GUIslice_drv_tft_espi.cpp:822:21: error: 'class TFT_eSPI' has no member named 'getTouch'
   bPressed = m_disp.getTouch(&nX,&nY);
                     ^
exit status 1
Error compiling for board WeMos D1 mini Lite.

I have a ST7735-baseddisplay without touch.

Amazing work!

As I'm completelly on the ESP8266 I could not determine how far this would be possible to run on this Arduino board?
Afaik the best library which is also Adafruit GFX compatible is https://github.com/Bodmer/TFT_eSPI
Would it be possible to extend in this regard?

Thank you!

Adding the attached to the root folder means the Arduino ID recognises the
library.properties.txt

library.

Attached as a text file so delete the .txt in the file name.

Feature request: add support for read-only text strings located in PROGMEM (flash)

• Enabling such a method would support optimized SRAM usage on Arduino
• User calls with PSTR(). ElemCreateTxt() / ElemCreate() may require typecasting param with (const char *)
• DrvDrawTxt() could use pgm_read_byte()
• Consider creating enum (GSLC_TXT_PROGMEM with negative value) in place of buffer length to flag the string as requiring PROGMEM access versus SRAM. Change nStrBufMax params to be int16_t instead of uint16_t.

Example:

  static const char mstr[] PROGMEM = "Count:";
  pElem = gslc_ElemCreateTxt(&m_gui,GSLC_ID_AUTO,E_PG_MAIN,(gslc_tsRect){20,60,50,10},
    (const char*)mstr,GSLC_TXT_PROGMEM,E_FONT_TXT);

Build a keypad element. For flexibility in supporting custom button appearance by users, it may be easiest to use the compound element definition (simple example in XSelNum).

Probably want to support a couple variants:

• Numeric
• Alphanumeric

Ideally, we would have a textarea, a set of input keys plus a Save and Cancel button.
To keep things simple, the textarea can be static and not accept touch presses itself.

Enhancements:

• Backspace character
• Flashing cursor indicator

In order to speed up tests with different touch displays I have created a touch handler cpp touch driver class and included this in the GUIslice lib as an own driver which can be selected as the others via a define. It can then be configured and connected to any touch in the app. If you think this is useful for others I can prepare a PR including the abstract driver and an example.
Here a slight overview:

the touch handler class

class TouchHandler {
 public:
  TouchHandler() {};

  void setCalibration(uint16_t ts_xMin, uint16_t ts_xMax, uint16_t ts_yMin, uint16_t ts_yMax);
  void setSize(uint16_t _disp_xSize, uint16_t _disp_ySize);
  //order: map, swap, constraint, flip 
  void setSwapFlip(bool _swapXY,bool _flipX,bool _flipY);

  THPoint scale(THPoint pIn);
  virtual THPoint getPoint(void);

private:
    //landscape perspective: x: width, y: heigth
    uint16_t disp_xSize = 320;
    uint16_t disp_ySize = 240;

    uint16_t ts_xMin = 398;
    uint16_t ts_xMax = 3877;
    uint16_t ts_yMin = 280;
    uint16_t ts_yMax = 3805;
    
    bool swapXY = true;    
    bool flipX = false;    
    bool flipY = true;    
};

including the touch handler in the main

In the application progam it is included with the XPT2046 as an example by

#include <XPT2046_touch.h>
#include <GUIslice_touch_handler.h>
SPIClass mySPI(2); //Create an SPI instance on SPI1 port.
XPT2046_touch touchDriver(PB12, mySPI); // Chip Select pin, SPI port
class MyTouchHandler: public TouchHandler {
   public:
      THPoint getPoint(void) {
          TS_Point pt = touchDriver.getPoint();
          THPoint ps = scale( THPoint(pt.x,pt.y,pt.z) );
          return ps;
      };
};
MyTouchHandler myTouchHandler;

void setup()
{
  //Start touch driver
  touchDriver.begin();

  //Set the used touch handler
  setTouchHandler(&myTouchHandler);
...

The debug_print() macro in GUIslice.h should be revised to support output to Serial (for Arduino targets) from errors occurring in the GUIslice core. Currently, the macro will work for the user program and GUIslice_drv_adagfx.cpp but not GUIslice.c. The primary issue is that Serial.println() will be reported as "not defined" because it is a C file and not a C++ file. Renaming GUIslice.c to GUIslice.cpp would likely work but is an undesirable workaround. Perhaps we can provide a wrapper function for Serial output that is available from the C compiled file.

I am using ESP8266-01 with Arduino Mega 2560...i want to know how to send user-defined data to a server, if for example my website name is "www.mysite.com" and my php file there is "receive.php", and the whole link of php looks like ,
www.mysite.com/project/receive.php where i receive one value in string form
How will i do the code for posting this to web server? please help with hint codes

It's a nice package but it does have a few drawbacks. First there is a fair amount of book keeping to keep track of the number of UI pieces. Various defines, enums, and UI storage have to be declared. UI pieces must have x, y coordinates, along with height and width. Colors and fonts need to be selected and mapped.

Defining DRV_TOUCH_ADA_SIMPLE together with DRV_DISP_TFT_ESPI results in

undefined reference to `gslc_TDrvInitTouch'

undefined reference to `gslc_TDrvGetTouch'

So one can not use an ILI9341_8BIT with 4-wire resistive touch on ESP32 with the recommended TFT_eSPI driver.
As already mentioned as TODO in the comments, the include of TouchScreen.h, settings of ports and init should not be done in GUIslice_drv_adagfx.cpp, but in a more independent place.
Thanks, Lukas.

try to compile sample at Stm32.

'class Adafruit_ILI9341_STM' has no member named 'setFont'

Is it possible to add combobox to the library?

Hi,

I'm using the GUIslice and it works perfectly for DRV_DISP_ADAGFX_ILI9341_STM with the default setting
#define GSLC_ROTATE 1

When setting
#define GSLC_ROTATE 2

clipping is wrong.
Exchanging
pGui->nDispW = ILI9341_TFTHEIGHT;
pGui->nDispH = ILI9341_TFTWIDTH;
with
pGui->nDispW = ILI9341_TFTWIDTH;
pGui->nDispH = ILI9341_TFTHEIGHT;
seems to work.

Best regards.

As the number of examples has grown, it would be helpful to create a set of pages in the wiki to show what each of the examples look like and the features that each demonstrates.

In addition, a gallery of each element type should also be provided.

Hello,

I tried to find other people that had the same issue but no luck.
I'm trying to use the library with a huzzah32 (ESP32) using the TFT_eSPI library and the FT6206 capacitive library. I have the 2.8" TFT LCD with Cap Touch.

But I can not get it to compile, it gives me the error:
lib/GUIslice/src/GUIslice_drv_tft_espi.cpp:822:21: error: 'class TFT_eSPI' has no member named 'getTouch'

I got the TFT_eSPI working before, so I know that my configuration is OK under the "User_Setup.h"

Even if I try to disable touch on "GUIslice_config_ard.h" the error still persists. It's always trying to include and compile this section of code inside the GUIslice_drv_tft_espi.cpp

/ Confirm that TOUCH_CS has been defined otherwise the
// m_disp.getTouch() call won't be defined in TFT_eSPI
#if defined(DRV_TOUCH_TFT_ESPI)
  #if !defined(TOUCH_CS)
    #error "To use DRV_TOUCH_TFT_ESPI, TOUCH_CS needs to be defined in TFT_eSPI User_Setup"
  #endif
#endif

bool gslc_DrvGetTouch(gslc_tsGui* pGui,int16_t* pnX, int16_t* pnY, uint16_t* pnPress)
{

  if ((pGui == NULL) || (pGui->pvDriver == NULL)) {
    GSLC_DEBUG_PRINT("ERROR: DrvGetTouch(%s) called with NULL ptr\n","");
    return false;
  }

  // Use TFT_eSPI for touch events
  uint8_t     bPressed = 0;
  uint16_t    nX=0;
  uint16_t    nY=0;
  int16_t     nOutputX, nOutputY;

  bPressed = m_disp.getTouch(&nX,&nY);

  // Perform any requested swapping of input axes
  if( pGui->nSwapXY ) {
    nOutputX = (int16_t)nY;
    nOutputY = (int16_t)nX;
  } else {
    nOutputX = (int16_t)nX;
    nOutputY = (int16_t)nY;
  }

  // Perform any requested output axis flipping
  if( pGui->nFlipX ) {
    nOutputX = pGui->nDispW - 1 - nOutputX;
  }
  if( pGui->nFlipY ) {
    nOutputY = pGui->nDispH - 1 - nOutputY;
  }

  // Assign coordinates
  *pnX = (int16_t)nOutputX;
  *pnY = (int16_t)nOutputY;

  if (bPressed > 0) {
    *pnPress = 1;
  } else {
    *pnPress = 0;
  }

  return true;
}

It's very likely that I'm missing something, could you give a hint?

With the launch of the GUIslice Builder (#79) as a beta release, it is likely that issues may be encountered in its operation or associated documentation. This issue will be used to capture user feedback concerning these reports.

This particular entry will also be updated periodically to reflect any known open issues, so as to avoid report duplication.

Bug Report Info

For any reports, please indicate the following details:

• Operating system (eg. Windows 10)
• GUIslice version (eg. 0.10.5)
• GUIslice Builder version (from About menu, eg. 0.10.4-beta5)
• Target platform; defined in Edit -> Options -> Target Platform (eg. arduino)
• If a crash occurred, it would be helpful to attach the crash log created in the Builder /logs/ subfolder

Current Known Issues

• Please refer to the entry associated with the specific release below

Hi ImpulseAdventure.

since the aeb6100 commit the GUIslice examples are under INCOMPATIBLE and I get the follwing compiler warning:

WARNING: library GUIslice claims to run on (avr, esp8266, esp32, stm32, samd) architecture(s) and may be incompatible with your current board which runs on (STM32F1) architecture(s).

Adding STM32F1 in the libaries.poperties file solves the issue.
The resulting line for architectures is then

architectures=avr,esp8266,esp32,stm32,samd,STM32F1

I don't know if the stm32 is useful or required.
Best regards.