Joel Bodenmann

What's the size of the parent container? It's possible that the window manager is resizing the button widget to fit into the container. The container API provides gwinGetInnerWidth() and gwinGetInnerHeight() to retrieve the inner height & width of the container.

Hello & Welcome to the µGFX community! Unfortunately, the µGFX-Studio is currently not publicly available.

Hi, As of today, we do not provide python bindings. However, as this is a plain C library it would be very easy to do so. In fact, there have been successful efforts in providing a MicroPython wrapper in the past: https://badge.emfcamp.org/wiki/TiLDA_MK3/ugfx https://github.com/pypilot/micropython_ugfx https://github.com/SHA2017-badge/Firmware We'd be more than happy to answer any question you might have when writing bindings. This would certainly be a great addition to the library!

@inmarket and I revisited this today. Both problems you reported are now fixed by these commits: 1235a9056c8324c5552f739114343b3e91dc15fb 7845f44f20034779d7d3c969750279297ff524ce Thank you for reporting these! Your contribution were noted in the corresponding commit messages.

Took a bit longer than expected to get to this but yeah: This is definitely a typo. Fixed in commit 888c7e8640caf02082adc23c967c5c0ba49a5146 Thank you for reporting this! There were some other improvements to the STM32LTDC driver in the meantime (which is why getting to this took a bit longer):

Hello & welcome to the µGFX community! If gfxAlloc() returns NULL, it indeed would indicate an issue with the memory layout/setup/capacity. You are setting GFX_USE_OS_CMSIS to GFXON. Are you actually using the CMSIS OS? Note that the CMSIS OS is a different component than the CMSIS library itself. If you're not using the actual CMSIS OS, you should select the proper OS instead - or use GFX_OS_RAW32 instead. After checking the OS situation: To further debug this, I'd recommend disabling the GDISP Module (setting GFX_USE_GDISP to GFXOFF in the configuration file) and trying to do various calls to gfxAlloc() in your main() right after gfxInit(). This way you can more easily figure out what is actually happening.

We've made changes to the STM32LTDC driver. While the changelog and updated board files reflect the changes necessary this forum post attempts to provide an overview of the changes necessary for migrations: Peripheral clock setups The driver no longer implements the necessary logic to setup the clocks for the LTDC & DMA2D peripherals. Instead, the board file now contains the new functions: void init_ltdc_clock(void) void init_dma2d_clock(void) Prior to this change, the driver itself setup the clocks. This change was made to increase portability and remove any dependency of underlying HAL definitions for RCC. This change also makes the previously existing LTDC_NO_CLOCK_INIT option obsolete and was removed accordingly. Renaming existing configuration options For consistency reasons and easier upgrading to µGFX v3.x, the following changes were made to the configuration options: ALLOW_2ND_LAYER -> STM32LTDC_USE_LAYER2 GDISP_LTDC_USE_RGB565 -> STM32LTDC_USE_RGB565 LTDC_DMA_CACHE_FLUSH -> STM32LTDC_DMA_CACHE_FLUSH LTDC_USE_DMA2D -> STM32LTDC_USE_DMA2D Double Buffering The STM32LTDC now supports double buffering. This feature can be enabled via STM32LTDC_USE_DOUBLEBUFFERING. For more information on this, see the readme.md in /drivers/gdisp/STM32LTDC.

Here's the `gdisp_lld_Win32.c` file I was using for this test (this is the same as in the current `master` branch): gdisp_lld_Win32.c That sounds like something worth contributing

I am working on reproducing this. Unfortunately, I was unsuccessful so far. Here's my simple test case following your pseudo code: #include "gfx.h" int main(int argc, char* argv[]) { (void)argc; (void)argv; gfxInit(); // Open image gImage myImage; gdispImageOpenFile(&myImage, "640x480.bmp"); // Create pixmap GDisplay* pm = gdispPixmapCreate(640, 480); gdispGImageDraw(pm, &myImage, 0, 0, 640, 480, 0, 0); // #1: blit the entire pixmap on the display - works correctly gdispGBlitArea(GDISP, 0, 0, 640, 480, 0, 0, 640, gdispPixmapGetBits(pm)); // #2: Blit a partial pixmap on the display with source coord (0,0) - works correctly gdispGBlitArea(GDISP, 0, 0, 200, 200, 0, 0, 640, gdispPixmapGetBits(pm)); // #3: blit a region from the middle of the pixmap to the display (source coord != (0,0)) - PROBLEM!! gdispGBlitArea(GDISP, 200, 200, 200, 200, 200, 200, 200, gdispPixmapGetBits(pm)); // Close the image gdispImageClose(&myImage); // Keep the application alive while (gTrue) gfxSleepMilliseconds(100); return 0; } When running this, the window (display) shows the image as expected without any defects. Am I missing something obvious here? For reference, here is a ready-to-run Win32 project with the code shown above and the corresponding asset(s): win32_blit_test.zip

I might have a look at this in the meantime. Could you provide the exact font you used (ideally both the font source file (if possible due to licensing) as well as the output of the font converter).

We're currently in the process of migrating our git server. Up until now, we were running Gogs but we're changing over to Gitea. Any user accounts with last activities older than 6 months will not be migrated to the new server. If you'd like to get an account on the new git server (once migration is completed) please get in touch with us.

Thank you for bringing this to our attention. Any form of feedback & possible bug report is welcomed I'll be working the STM32LTDC driver in an upcoming project (few days/weeks from now). I will look into it then.

Thanks, we will look into this!

Thank you for bringing this to our attention! Can you supply a minimum test-case that allows reproducing the bug(s) and corresponding patch(es)?

I haven't had time to check out your code yet - just the video. Looking good! What was their reasoning that it wouldn't be possible? if you like we might be able to improve this together and eventually put it into the official µGFX library so it's supported out-of-the-box

For paid support options/discussions, please contact us via e-mail: info@ugfx.io

Hi! As you stated the existing text edit widget only allows for one line of text. The proper way of doing this is creating a new widget called MultilineTextedit and implement the functionality. It might make sense to use the exsting Textedit widget as a base for this (i.e. copy-paste & modify). Other than the API documentation you can find documentation on creating your own widget here: https://wiki.ugfx.io/index.php/Creating_a_widget Alternatively we can implement the widget for via paid support.

Hello & welcome to the µGFX community! Yes that is still true. If you purchased an µGFX 2.x unlimited commercial license you can still use any 2.x release without any additional costs. This also applies if it's a new/different project or product as long as the license holder noted on the licensing document is executing the development/sale.

@inmarket any insights from your side?

The FT6x06 driver was contributed by a community member. It's likely that not everything in there is optional. We welcome any kind of contribution to improve the state of community-supplied drivers

What GINPUT driver are you using? This might very well be a driver "problem" (or feature). Can you reproduce the problem when you take you application code and compile it into a native Windows, Linux or MacOS application?

Hello & welcome to the µGFX community! There are various ways of achieving this. For example, you can have a look at the /demos/applications/notepad demo which is a small paint-like application. To draw without handling the touch (mouse) inputs through widgets. Instead, it uses ginputGetMouseStatus() to retrieve the current mouse status. You can use the GTIMER module to implement the screen timeout easily.

Did you manage to get this working?

In that case I'd recommend to adjust whatever GDISP driver you have to handle that adjustment for you. How to do this depends on the GDISP driver model used but the overall idea remains the same: shift each pixel before the display controller gets access to it.

Hi, I'll have to look into this at a later point but the mouse wheel is definitely not supported as of now. You should be able to click on the up and down buttons though. Controlling the list via the keyboard requires linking/setting-up the keyboard keys to the list widget using the GINPUT module.