Joel Bodenmann

Hello and welcome to the community! Please read the following threads for more information: https://community.ugfx.org/topic/316-ugfx-amp-chibios-stm32f746g-discovery https://community.ugfx.org/topic/311-newbie-trying-discof746-demo https://community.ugfx.org/topic/289-ugfx-ltdc-and-chibios The short version is that last time we checked (which is about half a year ago) there was compatibility issue with the ST headers used by ChibiOS/RT and our demo. Either of the two used the incorrect / outdated headers. The linked threads explain what steps are required to resolve this issue.

This looks awesome, great work! I haven't had time to look at the code yet but the video looks very promising We will review the code (which might sadly take up to two weeks) and eventually add it to the repository. In the meantime I will create a blog post to inform people. Great work, keep it up!

The GMISC module provides array/matrix operations including translation, rotation and scaling. These operations can be applied on polygon items. Hence you can draw a needle using a polygon and rotate that using the GMISC functionalities. In fact, there is a demo that shows this: /demos/modules/gdisp/polygons Let us know if you need any further help / explanations. We are happy to help wherever we can. The µGFX-Studio currently doesn't allows adding custom widgets. However, that feature is now at the very top of the ToDo list. Either the next or the over-next version of the µGFX-Studio will definitely include this feature. The next four weeks we won't have any time left to work on the Studio, however, after that we will put some serious time into it.

Note that you can use a different Cygwin / MinGW version that runs on your system. All you have to do is setting up a corresponding build configuration under Preferences -> Build.

Hello bluexp and welcome to the community! I'm sorry but we don't provide any support for Windows XP. We recommend that you simply use the µGFX-Studio on a different machine or that you run it in a VM.

We will investigate - this shouldn't happen. The GAUDIO module is supposed to automatically enable the GTIMER module and just showing a compilation warning. The file /src/gfile/gfile_fatfs_diskio_chibios.c implements a default disk interface that works with most ChibiOS/RT setups. You might need to modify it to your needs in case of you are using other card interfaces. You will still have to enable all the required stuff in ChibiOS/RT itself (halconf.h and mcuconf.h files). µGFX can't enable the MMC or SDIO interfaces and other required stuff for you in the ChibiOS/RT files. We strongly recommend getting your SD-Card up and running in a bare ChibiOS/RT project before you slap µGFX on top of it. That's way easier to debug. As soon as your SD-Card is working with ChibiOS/RT itself it will most likely just work out of the box with the GFILE module of µGFX. I hope that helps

Using flags for a partial redraw is indeed the recommended / intended way to go. You'd set a flag that either indicates that only a partial or a full redraw is required in the functions that modify the string content. In the rendering routine you'll simply read that flag and draw the stuff that needs to be drawn accordingly. I hope that helps. Please don't hesitate to ask if you have any further questions. We are happy to help where we can.

This is strange. The rules set of the GAUDIO module should automatically turn GFX_USE_GTIMER on if you enable the GAUDIO module: #if GFX_USE_GAUDIO #if GFX_USE_GEVENT && !GFX_USE_GTIMER #if GFX_DISPLAY_RULE_WARNINGS #warning "GAUDIO: GFX_USE_GTIMER is required if GFX_USE_GAUDIO and GFX_USE_GEVENT are TRUE. It has been turned on for you." #endif #undef GFX_USE_GTIMER #define GFX_USE_GTIMER TRUE #endif #endif Is there any way you can reproduce this problem?

Wow, those look great! Nice work! Would it be possible for you to share the actual widget source? We'd love to add this spinbox widget to the official repository! From the video it seems like you are always redrawing the entire string. As an optimization it would be possible to just redraw the value string without the unit string.

Hello and welcome to the community! Thank you for bringing this to our attention. We will have a look at this and fix what needs to be fixed. However, this might take a couple of days. Please excuse the inconvenience.

Thank you for sharing your port! We will have a look at it and integrate it in the repository. During the next couple of days/weeks.

Glad to hear that you got it working using the toolchain that came with µGFX-Studio! We will have a look at this and update the documentation accordingly to match the new package names in case of they changed. However, this might take a week or two. Sorry for the delay!

Edit: Original post below is not longer accurate. The Windows binaries of the font encoder/converter have been updated to resolve any kind of compatibility issues: Hello and welcome to the community! We decided to stop supporting the pre-build binaries of the font converter a few years ago as we introduced the online font converter. We recommend using the online converter. If this is for a commercial environment, we can build and provide pre-build binaries for you as part of a commercial support package. Please don't hesitate to contact us directly (through a direct message or e-mail) if you are interested into this option.

Glad to hear that everything is working as expected!

I quickly fired up the µGFX-Studio to give this a try and it appears like everything is working correctly: // Create label widget: ghLabel1 wi.g.show = TRUE; wi.g.x = 210; wi.g.y = 310; wi.g.width = 120; wi.g.height = 20; wi.g.parent = ghContainerPage0; wi.text = "Label1"; wi.customDraw = gwinLabelDrawJustifiedLeft; wi.customParam = 0; wi.customStyle = 0; ghLabel1 = gwinLabelCreate(0, &wi); gwinLabelSetBorder(ghLabel1, TRUE); // Create label widget: ghLabel2 wi.g.show = TRUE; wi.g.x = 210; wi.g.y = 340; wi.g.width = 120; wi.g.height = 20; wi.g.parent = ghContainerPage0; wi.text = "Label2"; wi.customDraw = gwinLabelDrawJustifiedCenter; wi.customParam = 0; wi.customStyle = 0; ghLabel2 = gwinLabelCreate(0, &wi); gwinLabelSetBorder(ghLabel2, TRUE); // Create label widget: ghLabel3 wi.g.show = TRUE; wi.g.x = 210; wi.g.y = 370; wi.g.width = 120; wi.g.height = 20; wi.g.parent = ghContainerPage0; wi.text = "Label3"; wi.customDraw = gwinLabelDrawJustifiedRight; wi.customParam = 0; wi.customStyle = 0; ghLabel3 = gwinLabelCreate(0, &wi); gwinLabelSetBorder(ghLabel3, TRUE); This code produces the expected result: Can you please double check your code and show it to us if the issue remains? A test case that allows us to reproduce the problem would be preferred.

We just pushed a fix for this to the repository. Thank you for contribution!

This is the related code from /src/gwin/gwin_wm.c: void gwinSetVisible(GHandle gh, bool_t visible) { if (visible) { if (!(gh->flags & GWIN_FLG_VISIBLE)) { gh->flags |= (GWIN_FLG_VISIBLE|GWIN_FLG_SYSVISIBLE|GWIN_FLG_BGREDRAW); _gwinUpdate(gh); } } else { if ((gh->flags & GWIN_FLG_VISIBLE)) { gh->flags &= ~(GWIN_FLG_VISIBLE|GWIN_FLG_SYSVISIBLE); gh->flags |= GWIN_FLG_BGREDRAW; _gwinUpdate(gh); } } } void _gwinUpdate(GHandle gh) { if ((gh->flags & GWIN_FLG_SYSVISIBLE)) { if (gh->vmt->Redraw) { getLock(gh); gh->vmt->Redraw(gh); exitLock(gh); } else if ((gh->flags & GWIN_FLG_BGREDRAW)) { getLock(gh); gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gh->bgcolor); exitLock(gh); if (gh->vmt->AfterClear) gh->vmt->AfterClear(gh); } } else if ((gh->flags & GWIN_FLG_BGREDRAW)) { getLock(gh); gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gwinGetDefaultBgColor()); exitLock(gh); } gh->flags &= ~(GWIN_FLG_NEEDREDRAW|GWIN_FLG_BGREDRAW); } Note that gwinShow() and gwinHide() are just convenience wrappers for gwinSetVisible(): #define gwinShow(gh) gwinSetVisible(gh, TRUE) #define gwinHide(gh) gwinSetVisible(gh, FALSE)

That is the expected behavior. When you hide the widget the window manager has to do something to get rid of them. It can't just "disable the pixels", it actually has to "overwrite" them with something. That something is the background color that is specified in the widget style that is applied to widget. Therefore, to get "transparency" effects you want to use the same backgrounds colors for all the related elements. The other solution / workaround is to redraw the element that is below the widget after the hiding operation. That way the underlying widget will overwrite the newly drawn background color rectangle with whatever is supposed to be there. Note that this is inefficient as some as the pixels that in the area of the widget that you are hiding get a new color twice: First the clearing with the background color and then the underlying widget that draws above them. Depending on your platform/setup/resources this isn't a big deal as even the cheapest embedded LCD controllers have rectangle-filling functions that make sure that the filling with the background color is very fast. However, if that is not the case you might want to consider rendering everything in a pixmap before you write it to the actual LCD (framebuffer). This is a classic trade-off between memory and CPU time so depending on what you have and what you need this might not be the best solution.

Thank you for mentioning this. I took the liberty to edit the topic title to prevent confusion and increase the quality of search results.

Thank you for bringing this to our attention! We will take a proper look at this during the following days and fix what needs to be fixed

As there's nothing obviously wrong with your code we will have to take a look at this in the following couple of days. Sadly we are currently very busy. If this is a time critical issue we'd recommend purchasing a support package.

Can you please provide a minimum working example (test case) that allows us to reproduce the problem?

This issue has been fixed for the 0.15 release of the µGFX-Studio (the variable has now been renamed to glistener).

Thank you for your contribution, we appreciate it a lot! We will have a look at this during the following days and include it into the repository.

There is no global "update everything" command. The way that GWIN is build implies that each element is only redrawn when needed to. If you call gwinSetText() the corresponding widget(s) will be redrawn automatically. If you implement a custom widget that has a setValue() method you are supposed to call _gwinUpdate() in that function. this means that if you have the need to manually update widgets or the entire display you are doing something wrong. I hope that helps. Let us know if you have any other questions.