Joel Bodenmann

According to this topic, this appears to be working very well!

We are very glad to hear that you got it working! Also thank you very much for sharing the steps required to get it working. I am sure this will help many people in the future

Oh, I didn't think of that: You are not supposed to write your widget in C++. You have to write your widget in C and then create a C++ wrapper just as with the already existing widgets.

There is no problem with opening multiple GIF files at once. The only two things that can keep you from successfully opening multiple files at once are: You hit the maximum number of files that can be opened at once. That number is specified with GFILE_MAX_GFILES in the configuration file. Choose the number as low as possible to keep the resource requirements at a minimum. You don't have enough memory left to open more files. As the error return code you get from gdispImageOpenFile() is GDISP_IMAGE_ERR_NOSUCHFILE, you are most likely hitting the first issue. Just increase said number in your configuration file and you should be fine.

This is a long shot, but when listing the files you want to include (the #include lines), can you make sure that all the C++ code files are included BEFORE the µGFX code files?

Try just enabling unicode support in the configuration file and typing the characters directly in the file. Make sure that the file is UTF-8 encoded. That's how we successfully tested unicode support.

As @inmarket mentioned we can't help you without more information. All I can do right now is confirming that µGFX works nice in a C++ application. Currently I am using µGFX in a C++ project and it works very well out of the box.

That sounds like a make clean wound have fixed it Nope, actually I just took that post out of the spinbox widget thread (the first post in this topic was the last one there) and created a new topic out of if because it is in no way related to the spin box widget at all.

If you are using our makefiles you can just use OPT_LINK_OPTIMIZE to no in your top-level makefile to disable LTO.

It is possible (and recommended!) to have all your custom widgets in your project directory rather than inside the library directory. In fact, you never ever want to modify any code inside the library as updating becomes problematic. There's not much we can tell without a test-case that we can reproduce. My guess is that you forgot to add the source file of your widget to the files list in the makefile (or whatever you are using).

Using gwinRedraw() is indeed what should use if you have to force a redraw yourself.

What operating system are you on? We had similar issues before, a simple upgrade to the latest version of the Cygwin toolchain fixed it.

You can have a look at the default drawing routine implementation of the label widget. It allows resizing the widget to fit the text. However, we discourage doing that - really. It goes against the µGFX philosophy. A widget is not supposed to resize itself. The window manager is responsible for the positioning and dimensions of the widgets. To resize, the widget must call the window manager function gwinResize() which will cause a lot of things to happen: It will have to verify the validity of the new dimensions, move the widget if it hits the clipping region, redraw any widget that is now becoming visible and so on. Additionally, it will also issue a redraw of the widget that called gwinResize() and therefore render the widget twice. To overcome some of these problems (including crashes!) we restrict the label widget to only grow larger. If you are writing your own widget you can auto-size it in the gwinCreateXxx() function. The label widget does that too. Note how the auto-sizing happens before _gwidetCreate() is called and therefore before the widget is being submitted to the window manager. @inmarket might have some additional things to say to this but in my opinion you really don't want to mess with things like that. The µGFX library has been written to be as resource friendly as possible to target embedded systems which usually feature static GUIs. It's possible to save a lot of memory and CPU cycles but that imposes these kinds of limitations.

You are not supposed to do that. The window manager is responsible for the positioning and the dimensions of the widgets that it maintains. A widget is not supposed to change its size by itself. May I ask why you would want to do that anyway? The µGFX library has been written to be as small and as fast as possible. The sizes of the images you want to be using for your buttons should be well known at compile time. The µGFX-Studio takes care of that for you and automatically adjust the size of your button to the image size if you select the image rendering routine.

Very nice, great work! Can't wait to see and try the finished implementation of this. When text is being truncated, are you adding some indicator like "..." ?

Thanks for getting this done so quickly! I will have a look at it tomorrow and let you know. If you really hate your life you can enable -pedantic. But the warnings I got I got from regular GCC while compiling on win32. When developing something like a widget you definitely want to use the Windows/Linux/MacOS port, otherwise you have to flash your target each time and debugging is a pain too. Also I got crashes with the spinbox that was supposed to show the days of the week. However, I simply commented it out and didn't investigate due to not having a whole lot of time. I'll try again with the new version tomorrow and let you know how it's looking.

The two most likely issues that cause this error are: Your Linux kernel has not been compiled with framebuffer support or it isn't enabled Your Linux framebuffer is in a non-standard location. Have a look at /boards/base/Linux-Framebuffer/board_framebuffer.h. The board file looks for /dev/fb0 and /dev/fb/0 by default.

I took a closer look at the code. Here are my thoughts: The gtimerInit() function must go into the Create() function. Initialization should only happen once. After that you can use gtimerStart() and gtimerStop() at any time as you are doing now. The callback functions you use with the GTimer don't have the correct signature. They must be of the following signature: void foo(void* param). You are free to cast that void pointer to anything you like inside the function. The drawing function doesn't have the correct signature. It must be the following signature: void foo(GWidgetObject* gw, void* param). Some functions don't use the parameters passed to them. Suppress warnings by using (void)x; the upArrow and downArrow arrays in the drawing function should only be created/declared if GDISP_NEED_CONVEX_POLYGON is set to TRUE. Otherwise you get compiler warnings about unused variables. The configuration macros in the header to set the padding, border width, max. character count etc. should either get a prefix (eg. GSPINBOX_) or should be moved to the C file (recommended!) to avoid naming conflicts. That being said, I'd also like to say that I like your style of commenting things. Well done! If you handle the things listed above we can add your spinbox widget to the library

To further extend what @inmarket said: Until a few days ago, the GWIN module required you to use a mouse (touchscreen). You couldn't just use the toggle inputs alone. This is why you are getting the errors about the missing mouse functions, macros and so on. You need to enable the mouse support by settings GINPUT_NEED_MOUSE to TRUE in your configuration file. However, this limitation has been removed a couple of days ago, it's now possible to use the GWIN module just with the toggle buttons as inputs (without any mouse/touchscreen). To benefit from this behavior you'd have to grab the very latest version of µGFX (newer than the latest stable release 2.5) from the repository. Edit: It wasn't actually the GWIN module that required a mouse input device, it was the widgets module which is a GWIN sub-module. So it has always been possible to use GWIN without a mouse. Just not the widgets.

You are allowed and welcomed to optimize the drawing of your widget

What are you trying to say / ask? @inmarket said exactly that.

Ah, I missed that, sorry. In that case having a row per queue makes sense. Basically this would extend the current list widget with a row option. Sounds good!

Thank you, we appreciate that you want to make something that can be added to the repository at the end. Earlier you mentioned that the number of rows and columns is known/fixed. Why would you mess with using queues then? To me it sounds like you should be using a static array instead. That saves a lot of overhead. If you like you can attach your header file to a post in this topic once you think that it's ready. I can give it a look There are no generic widget design guide lines as there is not much room for customization. The VMT is pretty much gives all the guidelines.

This is entirely possible and a very common technique. If you want to do it like this, we definitely recommend using am STM32F4 or an STM32F7. Note that only the newer models of the F4 have the built-in LCD controller & hardware acceleration.

Yes it's correct that the toggle driver called "Pal" is for the ChibiOS/HAL. Just as with the GDISP module for displays, you will have to write a driver that works with the HAL that you want to use. The driver then uses a board file to interface the actual hardware - exactly the same as with the GDISP module. You basically have to implementing everything in /src/drivers/ginput/toggle/Pal but using the other HAL that you'd like to use. The driver interface can be found in /src/ginput/toggle/ginput_driver_toggle.h. Implementing the palXxx() functions on your platform is definitely not the right way to go. Sorry for the confusion on this. The toggle drivers are not often used and we simply didn't clean up properly after we removed the ChibiOS-only constrain. That's correct. That is up to the driver / board file.