Joel Bodenmann

We'd love see your code once it's ready. In fact, there are waiting other people to see it as well It's really a nice demo you made there.

Glad to hear that you managed to locate & resolve the issue. Problems like that are the reason why the new µGFX-Studio will use the µGFX library natively for rendering:

Hi, Can you please create a minimum test case that allows us to reproduce, observe & examine the problem? A minimum test case consists of nothing else but the absolute minimum code to show the problem. In your case that would be the application code with nothing but a label, the configuration file and the corresponding font files. There really shouldn't be anything else in there. This way we can ensure that it has nothing to do with other parts of your application and we can try it on multiple platforms.

Oh wow.... I don't know what to say, that is just amazing! We would love to see more of your project, it really looks very very very very well. Ideally we'd like to put a picture or two of that application in our demos section of the website as nice demos is what we are currently lacking. Would it actually be possible to get the source or is this a closed-source project? Could you at least share how you implemented the gradients & transparency of those very nice looking arcs? That is µGFX. It's just amazing & very impressive to see what people can do with it

Hello Richard and welcome to the community! µGFX provides different simple & well documented interface for creating custom widgets. Examples are available for download as well. However, unfortunately it's mostly industrial/customers that actually implement custom widgets. In fact, most applications only consist of custom rendering functions and custom widgets. The problem is that all of these projects are closed source and if we get the source it's protected by an NDA. Therefore, these types of widgets never make it to the downloads section or into the repository itself. Our community member @Smd implementer a very nice list-based menu widget about three years ago. I'm not sure if that's available now. @Sting created a table widget and mentioned being busy working on a tree widget. Other than that: You are welcomed to post any questions you have on this forum. We are happy to help wherever we can.

No need to delete the topic. If you can leave an answer to your question this might help other people in the future that have the same question Official the answer is: Use gwinSetFont() to set a widget specific font Use the Font property combobox in the µGFX-Studio widget editor on the right side to set a font in the studio

Just an insider information in case of @madhu decides to implement it that way: The list that the built-in window manager uses is a uni-direction list in order to safe resources. Back-Tab is currently not supported/implemented at all. Code needs to be added that overflows the list to find the previous item. That being said, it's also possible to write your own window manager and using that by using gwinSetWindowManager().

What you see there is called Tearing and it is probably one of the most common phenomena with displays. The effect is caused by modifying the framebuffer while the display controller is looping through the framebuffer to refresh the actual display panel. There are two (common?) solutions to this problem: Vertical Synchronization: Display controllers often provide a signal or flag that informs you when the framebuffer sampler finished refreshing the display. Then you have a specific/known amount of time (like a time window) during which you can modify the framebuffer before the sampler starts scanning through it and updating the display again. Double-Buffering: When multiple framebuffers are available, you can write to one framebuffer at any time and once the framebuffer sampler completed a frame you simply swap the buffer so it will loop through the new one while the other one can now be modified. Tearing prevention is something that has to happen on the driver level. The GDISP driver API has been designed to be flexible enough to support these kind of things. For example, a gdispQuery() command can be implemented to check whether the display controller is currently refreshing the display panel. You can have a look at the uGFX microPython wrapper that implements this feature. However, unless it got fixed by now they are not doing it through the gdispQuery() API like they should but instead they implemented a specific function in the ILI9341 driver that they use for that specific project. Although that is the wrong approach (this really has to be done through gdispQuery()) it shows how to deal with tearing prevention. The same goes for using the 2nd layer of the LTDC of the STM32. More information can be found here. Although in case of double-buffer that could be done manually using Pixmaps instead so that the second layer is still available to use the other fancy features. I hope that helps.

Yes, we tried it with your config file. Enabling containers definitely shouldn't lead to a crash or any other unexpected behavior. We'll give it a try and let you know. However, this might have to wait until Monday.

You can change the image of a pushbutton (presuming that you use the built-in image rendering function) at any time by calling gwinSetCustomDraw() passing a pointer to a different image as the custom parameter. However, I assume that you talk about the state of the button (the different images for the three states "enabled", "disabled" and "pressed" which are just one image file). Using a pushbutton widget without GINPUT/GEVENT doesn't make much sense and is actually impossible (it won't even compile!). Can you please be more specific?

Yeah, that's what I did - it appears to work correctly unless we missed something less obvious. As @inmarket mentioned, this might be an platform specific issue. It is usually a good idea to develop the entire application on a desktop system. The entire µGFX application code is completely portable and you can compile native applications for Windows, Linux, Mac OS X and BSD. Developing a µGFX application on a desktop system is a lot faster, less cumbersome & easier to debug.

I just tested it on an Ubuntu 16 64-bit computer - works well. All keys are recognized as they should be including the arrow keys. The /demos/modules/ginput/keyboard demo together with the /drivers/multiple/SDL driver was used for testing. If you are using some custom made driver for a custom keyboard as per your initial question - most likely there will be something wrong in your mapping.

We couldn't manage to reproduce the problem yet. So far everything appears to be working as expected. Does this mean that it crashes if the console widget is partially off-screen?

Either the archive is broken or the corresponding files are missing. As mentioned, please give us a minimal test case that allows reproducing the problem. There is tons of stuff in that archive that has nothing to do with this problem. A minimal test case consists of nothing but the most minimal code required to reproduce the problem.

Sorry for the inconvenience, but can you please attach it to a forum message in this topic (for security and historic reasons)?

Yes.

Can you please provide us with a ready-to-compile test case (ZIP archive containing the entire application code & configuration file) that allows us reproducing the problem?

With these kinds of things it's usually a good idea to keep it as simple as possible. Don't forget that this is a GUI toolkit designed to use as little resources as possible meant for embedded systems. Auto-resizing is ALWAYS very expensive and a lot of trouble - things we don't really want to spend resources for. So far we only added auto-resizing for one widget/case and we regret it a lot. Don't forget that the kind of GUIs you create with µGFX are usually (as in almost always) static.

Thank you very much for sharing! It is always nice & interesting to see for what and how people use µGFX. We'd definitely love to see more! I love the temperature (?) gauge in the middle. Is there any chance for you to share that one? I guess that would be a very nice example for the example widgets of the downloads section. On a side note: Unfortunately we haven't had time to include your table widget into the repository yet...

What kind of troubles did you have with it? We are happy to help wherever we can. LST_VERT_PAD doesn't specify the height of an item, it's only padding. You will notice the difference once you start using a font with a different height. That is also the reason why the current implementation of the list widget doesn't have an absolute "list item height" setting.

Hello @Stefano and welcome to the community! The redrawing is handled by the window manager. It's possible to use no window manager at all, the built-in window manager or you can write and use your own window manager using gwinSetWindowManager() if you have any specific needs. With the built-in window manager you should achieve an instant-redraw of a widget by setting GWIN_REDRAW_IMMEDIATE to TRUE and calling gwinRedraw(). However, that setting is a global setting that will affect redrawing of all widgets. It will cause all redrawing requests to take place immediately - even when a widget requests a redrawing by itself. One of the jobs of a window manager is to figure out when and how to redraw things. If you can explain why you need this / what you want to achieve we might be able to help you in a better way.

That's a very interesting approach. Thank you very much for sharing! We're always interested in seeing the results of projects & products that use the uGFX library.

Sorry, I didn't mean to be offensive or anything. It's just always good to know what factors people are taking into consideration when choosing their platform. With larger displays it is quite common that you purchase the display panel and the touch panel separately and stick them together yourself. That is also the reason why you won't find a display + touch combination that has the exact same connector like the one that came with the discovery board. When the touchscreen and the display panel share the same flex cable connection they usually tend to be manufacturer specific.

I'm not really sure where to go with this... As mentioned this definitely seems to be an issue with the video mode settings. However, the driver would call exit() to stop the execution of the program and print an error message to stderr if any of the initialization code failed. Did you try playing around with the defines in the board file as @inmarket mentioned in his first post? #define USE_SET_MODE // Optional - comment this out to not to try to set the color mode we want //#define VTDEV_PATH "/dev/tty0" // Optional - if defined use this tty to switch from text to graphics mode

Is it possible to get some images/screenshots of those? Thank you very much, we appreciate it a lot! There's currently no generic donation running. We prefer to create dedicated donations for cases where we "really need the money". So far we only did that once when we added Mac OS X support for the µGFX-Studio: However, if you really feel like it, we appreciate any kind of donation - which would be used to keep the servers, this forum and other infrastructure up & running. We'll sit together and discuss the option of having an always-open donation running. We'll get back to you in a couple of days. Thank you very much for your support!