Joel Bodenmann

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!

Hello Dave and welcome to the community! As @inmarket mentioned the issue is that the window manager doesn't know about your primitive line shape. Therefore, it never knows when to clear and redraw it. Here's an example of a custom rendering function for the container which acts like a background: static void containerDraw_MyBackground(GWidgetObject* gw, void* param) { (void)param; // Clear container area gdispGFillArea(gw->g.display, gw->g.x, gw->g.y, gw->g.width, gw->g.height, gw->pstyle->background); // Draw the elements gdispFillArea(10, 10, 10, 460, silver_studio); gdispFillArea(10, 20, 620, 10, silver_studio); gdispFillArea(30, 10, 10, 460, silver_studio); gdispFillArea(50, 10, 10, 460, silver_studio); } When creating the container, just pass the function pointer to the initialization struct or use gwinSetCustomDraw(): // create container widget: ghContainerPage0 wi.g.show = FALSE; wi.g.x = 0; wi.g.y = 0; wi.g.width = 640; wi.g.height = 480; wi.g.parent = 0; wi.text = "Container"; wi.customDraw = containerDraw_MyBackground; wi.customParam = 0; wi.customStyle = 0; ghContainerPage0 = gwinContainerCreate(0, &wi, 0); And that's it! This way the window manager will always render those primitives in the custom rendering function whenever needed. You can find more information about custom rendering functions here: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine

May I ask why you change your platform/system all the time? You should be able to use almost any display panel that offers the compatible RGB interface (and works with the electrical specification). Worst case is that you have to create some sort of adapter board. There are literally hundreds to choose from. These are the ones from the same manufacturer as the stock display of the STM32F746G-Discovery board: http://www.rocktech.com.hk/pro.aspx?TypeID=2

@inmarket didn't we encounter some issues with that approach quite a few years ago with some noisier touchscreen controller outputs and decided to "change that"?

Yourread_xyz() function is supposed to return FALSE if the retrieved touch coordinates are invalid. In that case, the GINPUT module won't read the GMouseReadings struct at all and you can simply leave the coordinates and the buttons unchanged. There's not much more to say. I hope that that answers all of your questions. Otherwise, don't hesitate to ask

Hello @timandr, Please excuse the late reply. I'm not sure what happened. It looks like I didn't properly hit the "Submit Reply" button... Did you get everything up and running or do you still have questions?