Steffen

- - Good point on needing to be able to change them later. A better pick might be `gwinCheckboxCheck` where the bool parameter should be const'able without much hassle from what i can tell. Another might be `gwinGCheckboxCreate`, the pointers for `g` and `pInit` can have a const added (for the pointer, not the content. i.e GDisplay * const g) unless those are left changeable by design decision too. While i didn't try it i could imagine that all the custom drawing functions end up using more space than a switch() for the same purpose within the regular drawing function (in regards to something simple like text justification). Additionally a switch() could also be easily wrapped with an ifdef to completely remove it if the functionality is not needed. Of course the custom drawing functions do have their use and should not be removed. I just feel that text alignment and the like doesn't really belong there. Again i could imagine the custom drawing function to render the checkbox as button using more space than the few flag checks that would be needed in the button code. Its no major issue of course, using the checkbox works fine it just seems a little odd. - - Couldn't you build the public ones in each variant (language selections) and then just include the proper file depending on the defines? - The strings work for now and even their addresses could be used i suppose. Though that is a little hacky, having a proper api for it would be nifty. - - The api from 12. would do the job for me in this regard. Getting things out of the interrupt context and such can be left to the user while still offering the option to be able to use interrupts.

Heres a few things that come to mind as sort of a wishlist. Though some things may not apply to 3.0 if you are primarily focused on specific modules. For a few of those i might also make pull requests myself if we actually require them. Add prefixes to all public types, defines and functions to avoid conflicts with other code. This specifically refers to things like `TRUE` which you already mentioned but also extends to many others like `justifyLeft`, `powerOn` or `color_t` of which some are quite likely to cause issues with other code. I'd recommend having v2 compatibility turned off by default as it is only relevant for those upgrading the library. If it is on by default then people may mistakenly use it for new projects and run into the same old issues. More use of `const` to allow for better optimization. Many of the apis (i.e `gwinCheckboxIsChecked`) don't use `const` despite only reading from the arguments. Widget options should use flags or variables on the widget object rather than custom drawing functions for things like text justification. This would seem more fitting and can be handled consistently across all widgets for common things like borders and text justification. The label widget already does this partially in its internal code. The custom drawing functions seem more like a dirty hack at the moment. Add a toggle mode for the button widget, when used the button stays pressed and only is unpressed when used again. Currently the checkbox widget seems to be abused for the same functionality via a custom drawing function. This could be handled via a flag. This should come with new events for this mode (toggled on, toggled off). Add a monospaced font (i know i can add my own, but its inconvenient) Add more size options for the UI1 and UI2 fonts. Depending on the display the regular one might be too small while the larger one is already too large. Add support for chinese and other characters to the included fonts. These can be disabled by default via an #ifdef but being able to just enable them on demand would be much more convenient over dealing with fonts and their licenses to get my own. Some way to draw lines, boxes and circles inside containers/widgets would be neat. Using the gdisp/gwin functions does not really work for that as they will not remain on their own on a redraw. I suppose this could be done by having basic widgets for boxes, lines and circles. A way to identify the widget type from a `GHandle`. This currently can be done with `gwinGetClassName` however comparing those strings isn't particularily efficient. A enum value would be much nicer to use. Have a user settable pointer per widget similar to the tag but usable for any kind of data. This would allow quick access to user data from event callbacks without the need for additional lookup tables or such. This could probably replace the tag entirely. (Already suggested in another thread) For inputs (keyboard, mouse, toggle, ...) provide api functions to trigger them from software for more flexibility. I.e similar to `gwinTextEditSendKey` but on driver level so that it works with any widget that takes keyboard events. Interrupt driven mode for toggles, currently only polling seems to be possible despite our µC having nice interrupt notifications for each pin. With the functions from the previous point this could be handled easily, just would require some extra work to get out of the interrupt context.

That would be neat since once there is a release the api no longer can be changed as easily. I suppose i could also throw together a list of things based on 2.8 which you then can consider for 3.0.

Alright i'll put them up as i get around to it. As for 3.0, is the current state accessible somewhere? I assume you are using the version jump to break some of the api which might be a good opportunity to provide further feedback on some things that we'd like to see changed/improved, but which cannot be done without changing the api.

Hi! What is the current situation regarding pull requests for 2.8? Does it still make sense to open new PR's for 2.8 or will those not be accepted due to 3.0 being around the corner? The 3.0 topic hasn't seen an update in a while so this is a little unclear. I do have a bunch of additions (i.e #26) that i need for our product and would prefer to have those in upstream rather than maintaining local patches. However so far there hasn't been any activity there.

Thanks. I worked around this by just disabling the buttons which actually works even better for my use case, so there's no hurry on this from my side. But of course it still should be looked at

I was using 2.8 but also just tried the current master from https://git.ugfx.io/uGFX/uGFX/ which shows the same behaviour. FreeRTOS is used with GFX_USE_OS_FREERTOS enabled.

Hi, i tried using gwinDetachToggle to temporarily disable some buttons. While that does work fine i'm not able to enable the same button again with gwinAttachToggle despite the return code indicating success. The affected button no longer sends its button event after attaching again and the "pressed" graphic also does not show. Only if i comment out the call to geventDetachSource in the gwinDetachToggle implementation it will work as expected, so i guess something gets messy with the listener there. I suppose the person in the linked post below ran into the same issue.

Hi hi, i'm trying to have some windows(containers) that are overlapping others. This is a popup menu which is drawn over whatever else is on the screen. With this i now have the problem that if the screen content is updated periodically (i.e new line printed to console) the popup menu is not redrawn. The console will just draw over it and make parts of it vanish unless i manually request a redraw. From what i already gathered the default window manager will only handle overlapping for children widgets of a parent, so in this case the popup window never gets its redraw flag set as it has no parent set. Is there any convenient way to have such toplevel/popup windows with the default window manager or is a custom window manager the only way?

Thanks, the tags in combination with the source object is what i ended up using and it worked out rather well thus far. One thing you could perhaps consider for future versions is to have a option to set user pointers for the tag rather than an u16. This would make it a lot more flexible and in some cases could even remove the need for additional switch cases (i.e directly calling a function pointer from there).

How do i attach a specific button/widget to a listener? Using gwinAttachListener will get me the events from the button but to my understanding also those from all other widgets which is a little impractical when there is a lot of them. I also found geventAttachSource but could not get this to work as i do not have a GSourceHandle for my button and using the GHandle did nothing. Some of the demo code used gwinGetButtonSource to do that but this function does not seem to exist anymore. What is the proper way to have only events from specific widgets on a listener?

I suppose you are refering to GWIN_CONSOLE_HISTORY_AVERAGING? I do not have this defined so the buffer should be allocated for the entire window. There are no font or size changes after creating the console window, only its visibility is changed.

For this you need to change the style either during the initialization or with gwinSetStyle. Something like this should work: const GWidgetStyle MyCustomStyle = { HTML2COLOR(0xFF0000), // window background }; GWidgetInit wi; // Apply some default values for GWIN gwinWidgetClearInit(&wi); // Apply the container parameters wi.g.show = FALSE; wi.g.width = 200; wi.g.height = 150; wi.g.y = 10; wi.g.x = 10; wi.text = "Container"; wi.customStyle = &MyCustomStyle; ghContainer = gwinContainerCreate(0, &wi, GWIN_CONTAINER_BORDER); wi.g.show = TRUE; More info on styles is on https://wiki.ugfx.io/index.php/Widgets

I do have GWIN_CONSOLE_USE_HISTORY enabled in my actual development code. The console is only emptied if the window was completely full. If there is only a few messages they do remain through the invisible setting so it does seem to work for that part.

Hi hi, as the title suggests i'm using a console widget and get crashes when using gwinPrintf/gwinPutString on it while it is hidden. However this only seems to happen when the console was completely filled previously. I tested it with µGFX 2.8 as well as the current git master (though thats just one commit ahead of the tag). To reproduce it more easily i took the gwin/console demo and modified it for the purpose. The Attached archive includes the modified demo and a Makefile for Linux X11, though by adapting the Makefile this should work on any platform. To reproduce it just unpack the archive, then copy/clone µGFX into the new directory or alternatively change GFXDIR in the Makefile. Then run make to compile. I captured the following information from the crash with gdb: (gdb) r Starting program: /tmp/crash_example/.build/crash_example [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Running GFX Window in 24 bit color [New Thread 0xf7c2bb40 (LWP 18352)] [New Thread 0xf72ffb40 (LWP 18353)] Thread 1 "crash_example" received signal SIGSEGV, Segmentation fault. 0xf7dae379 in ?? () from /lib/i386-linux-gnu/libc.so.6 (gdb) bt #0 0xf7dae379 in ?? () from /lib/i386-linux-gnu/libc.so.6 #1 0x56559016 in scrollBuffer.lto_priv.15 (gcw=0x56568450) at uGFX//src/gwin/gwin_console.c:191 #2 0x56556a1b in gwinPutChar (gh=0x56568450, c=53 '5') at uGFX//src/gwin/gwin_console.c:548 #3 0x5655735d in gwinPrintf (gh=0x56568450, fmt=0x565608ba "\n") at uGFX//src/gwin/gwin_console.c:823 #4 0x56557fe4 in main () at uGFX//../console_crash/main.c:76 (gdb) frame 1 #1 0x56559016 in scrollBuffer.lto_priv.15 (gcw=0x56568450) at uGFX//src/gwin/gwin_console.c:191 191 memcpy(gcw->buffer, p, gcw->bufpos); // Move the rest of the data (gdb) print gcw->bufpos $1 = 4294967295 (gdb) print dp $2 = 2 (gdb) print gcw->buffer $3 = 0x56575450 "\n42\n41\n40\n49\n3\n38\n37\n36\n3\n35\n433\n34\n3\n34\n333\n2\n3\n30\n31\n\n3\n\n626\n27\n\n2\n\n24\n2\n2\n17\n18\n19\n8\n17\n16\n15\n14\n13\n12\n11\n10\n19\n\n\n\n\n\n\n\n" (gdb) print p $4 = 0x56575452 "2\n41\n40\n49\n3\n38\n37\n36\n3\n35\n433\n34\n3\n34\n333\n2\n3\n30\n31\n\n3\n\n626\n27\n\n2\n\n24\n2\n2\n17\n18\n19\n8\n17\n16\n15\n14\n13\n12\n11\n10\n19\n\n\n\n\n\n\n\n" (gdb) print gcw->bufsize $5 = 4601 Seems bufpos is slightly off there. Am i using the widget wrong or is this an actual bug? In my actual code i for now worked around this by stalling the print calls until the console becomes visible. Though when the console is filled and i hide it then it will be emptied once i set it visible again, only the newly added lines will appear at the top rather than being appended to the old content. Not sure if that is intended or possibly related (GDISP_NEED_SCROLL is disabled but the buffer should handle it i guess?). crash_example.tar.gz