Joel Bodenmann

As @inmarket mentioned the implementations of things like malloc(), setjmp() and so on are often buggy on standard libraries provided with the toolchains for embedded targets. That's why we provide our own generic implementations that work anywhere. The configuration allows to choose any of the options which means that the user of the µGFX library can always pick what's best for his case.

Here you go. Let me know whether that worked out for you.

Hello and welcome to the µGFX community! The list widget uses the fill property of the widget style to highlight the currently selected item (line 782 in /src/gwin/gwin_list.c). A display driver for a monochrome display controller usually interprets the color 0x000000 as black and everything else as white (or what ever the two colors will be). Currently you set all your values to non-zero values. Try setting the fill property to 0x000000. However, that will most likely not be satisfying as you'll no longer get a visual indication for which item is currently selected. In that case, you want to write a custom rendering function for the list widget so you can either invert the colors of the currently selected item or you can add some sort of arrow indicator. Writing a custom rendering routine is very simple, there's a guide: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine You'd usually start of by copying the built-in rendering function and then modifying it to your needs. I hope that helped.

Hello @Oshel and welcome to the µGFX community! Thank you very much for your positive feedback - we appreciate it a lot! Regarding the win32 stuff: I can upload a bare win32 demo project (basically a hello world) that uses Makefiles if you'd like. It's well tested.

Hi, Can you please try to run the /demos/modules/gwin/keyboard demo without modifying it at all?

Thank you for your feedback regarding the documentation. But did you have a look at the /modules/gwin/keyboard? It shows clearly how to use the virtual keyboard. It doesn't get much more detailed than that. It even shows how to grab virtual keyboard visibility changes. Please stop highlighting me or inmarket in your posts just in hopes that we reply sooner. We reply when we have time for it.

I'm sorry, I don't understand what you want to achieve. Why do you want to have a button in focus that is on a different display page?

Sounds great! Looking forward seeing the final example project

Just for clarification for people that come around this post: This is not because µGFX doesn't support pixel read-back or doesn't support it well. It's just that, as @inmarket explained, it's often not supported by the hardware itself. µGFX has everything required to read back pixel values. That's correct, I fully agree. But that's also the reason why it would be awesome if somebody else would pick up this task

Hello Kevin, No, we currently don't have built-in anti-aliasing for shape rendering. The goal is to offer that as a 2nd set of functions. If you'd be interested in helping to implement those we'd highly appreciate it. Anti-aliasing for font rendering is fully implemented though.

You never get back a string, you always just get a single character because each time a character is pressed on the keyboard an event gets generated. Therefore, just listen to the event as shown in the demos mentioned in my previous post and create an array from them yourself. It's really just a matter of having an array and a write pointer or an index variable. If you need something more flexible than arrays you might want to consider using GQUEUES.

Hello @manoj, When using the virtual keyboard the keyboard input layer of the GINPUT gets enabled. When that is the case, keyboard events get distributed to the widget in focus. A widget can be focused by either clicking it or by using the arrow or tab keys of a keyboard to move the focus to the next widget in the widgets list. When a button has focus it can be clicked by pressing the enter or space key on a keyboard. This is most likely what is happening here. I'm not sure whether that is a bug in the distribution of the keyboard events to a widget in focus or whether you're doing the visibility handling wrong. It's actually not that unlikely that this is a bug in the µGFX library. I'd recommend you to run some simple tests based on what I described above. Start with two push-buttons and a keyboard widget on the same page and then work your way from there.

Hello @jtronix and welcome to the µGFX community! Thank you for sharing your example sketch. Things like this are always very helpful for other people. Do you feel like the sketch is "good enough" to be added to the downloads section on this website as an example project? Regarding the ADS7843: I don't know of any existing board file for that setup. There's a GDISP board file for Arduino in the /boards/base/ArduinoTinyScreen/ directory but I guess that won't help much as you already got everything working. At the end the stuff you have to do in the ADS7843 board file is exactly the same as for a GDISP board file: Implement the different functions to talk to the hardware (eg. SPI in this case) and that's it. You can find a template board file in the ADS7843 driver directory. If you're having trouble understanding what each function should do we're happy to help where ever we can. If you're having troubles with the Arduino library I guess the folks over at those Arduino forums will be happy to help where ever they can as well

If you didn't find the problem until now there are three things you can easily do: Instead of changing the page, just printf() something. This way you don't run into another issue upon changing pages that might look like the button stuff is not working. Run the button demo that you can find under /demos/modules/gwin/button Quickly fire up the µGFX-Studio (that you can download from this website under Downloads). It allows you to create very simple GUI pages and it generates an event-loop for you. Add that code to your project and give it a try (you'll still have to call the guiShowPage() functions yourself to actually change the page though. The issue mentioned by @inmarket is definitely something that is wrong here too so you might to keep that one in mind for the future. An additional remark: It's usually very bad practice to load fonts upon switching display pages. Unless fonts are being loaded from an external memory source because they are not byte-addressable they don't take up a lot of space. It's merely a header with a bit of metadata. Therefore, fonts are usually kept open indefinitely for regular applications. But at the end this really depends on what you want to do.

@inmarket already mentioned one of the important things: The header file generated by the file2c tool contains a C-Array of the binary raw data of the file that you fed into it. The actual size of the object in ROM will be a lot smaller as it won't be a textual representation of binary data anymore (eg. think of all the commas in the array to separate the individual bytes. All of those will be omitted). Also, very large files usually get split up into multiple C-Arrays which leads to even more textual overhead that won't add any size to the object itself once compiled into a binary. The GFILE module allows you to load data (and therefore images) from pretty much any source. One of those is the microcontrollers ROM through the ROMFS that we wrote ourselves. However, GFILE can easily interface other file systems such as FatFS that allows you loading images from an SD-Card. Everything is already in place to do that. The STM32F7-Discovery board you're working with also has a mass-storage memory connected via QSPI. It's also possible to interface that through GFILE. Once you managed to get your image through the GFILE API the rest of the library doesn't bother anymore so you really have a vast variety of possibilities where to load your image(s) from. If things really get bad you can always implement your own file system using the USERFS interface of GFILE.

For completeness, we're referring to this one: https://wiki.ugfx.io/index.php/Teensy

Ah yes, that's it. I thought that he removed it as he mentioned that but I guess he removed it just from the Eclipse project files tree thingy which doesn't influence the Makefile stuff when using an existing/external Makefile.

That's weird... did you perform a clean build (make clean) ?

Hello @Johnboy and welcome to the µGFX community! Your GFXLIB path looks correct. To me it seems like your GFXDEMO variable is wrong. You should remove the leading slash: GFXDEMO = modules/gdisp/basics

We can't help you just with these information. We don't even know what underlying system you're using, which compiler, how your GOS configuration looks like and so on. Please provide all of that information.

Hi, Thank you for bringing this to our attention. I'll leave to that to @inmarket as he's the one who wrote the win32 driver(s).

Okay, that makes sense. Sorry for the noise!

Oh right, that's it! Not sure how I could missed that with the forum search... Thank you @cpu20!

There's nothing on the forum but I remember having talked to someone who was successfully running µGFX on an ESP32. Unfortunately I can't remember who it was. There are definitely no technical limitations that would prevent you from doing it. But I understand that a sample project is always very helpful. I'll let you know if I managed to remember who it was... In the meantime, here's one for the ESP8266. Although that will most likely be completely useless to you.