Joel Bodenmann

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?

I'm glad to hear that everything works as expected!

As mentioned in a previous post this definitely seems to be a video mode initialization issue. Stepping through the code might be the most reasonable way to track down & fix this problem. Also, please try, as mentioned, what happens when you call the driver initialization code twice. It would be good to know if this only happens once per startup of the driver or the entire process.

Under which circumstances does the entire keyboard widget get redrawn? That should only happen if visibility and similar things change. If you just press a key on the keyboard (that doesn't change the current layout) it should only redraw that key. Is it possible for you to create a small test-case that allows us to reproduce the problem? That function is supposed to return TRUE if the data in the GMouseReading struct are valid. Otherwise it has to return FALSE. You can have a look at the STMPE811 driver implementation if you'd like to see an example where that function actually can return FALSE under certain circumstances.

The easiest, most flexible & best solution for a use case like this is to write a custom rendering routine. That gives you complete control over how your list gets rendered. There's a guide on that: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine However, depending on your needs (if the features provided by the list widget are not exactly what you want), you might want to write a custom widget instead: https://wiki.ugfx.io/index.php/Creating_a_widget Don't hesitate to ask when you have any questions. We are happy to help wherever we can.

The distorted image you see on the first startup, is that always exactly the same?

There are two very likely causes to this: You don't have your FPU enabled. The shown demo is a very floating point intensive demo. Your clocks are not setup correctly (eg. your CPU runs way slower than it could/should). That strongly suggests an out-of-memory situation. I'd recommend you to step through the code to figure out why gfileOpen() fails. All in all you might want to ensure that all things you want to do work independently first. Eg: Try to create a project that doesn't do anything but playing your MP3. Once that works, create a project that doesn't do anything but implementing the GUI. Once that works, add all the other stuff (eg. peripherals and what not) and ensure that that works. At the end throw everything together step-by-step so you know exactly where and when something stops working.