Joel Bodenmann

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.

Hi, The USERFS allows you to implement your own filesystem handlers. That is only used when none of the already existing file systems can be used. When enabling USERFS you have to provide your own implementation of the GFILEVMT somewhere in your application/project code. You can have a look at the GFILEVMT documentation/declaration and the existing file system implementations to learn how to do that. Additionally, there has been a thread on this forum already where somebody dropped some code on how they are doing it - that might help too.

I found two more things: Line 133 through 148 are obsolete and can be removed. Orientation handling is taken care of in the gdisp_lld_control() function as the display driver supports this natively. It's just dead code. Line 188 seems to do a funny or operation on zero. Looks kind of obsolete to me too unless I am missing something. Other than that the driver looks very well built and very mature. Great work!

You are not really giving us any information to work with. Did you check whether the software is still running? Do you have some sort of heartbeat? There are tons of examples. The most obvious one would be /demos/modules/gwin/button.