Joel Bodenmann

There's a flag that you can put in your mouse driver for that: GMOUSE_VFLG_DEFAULTFINGER. Works like this: const GMouseVMT const GMOUSE_DRIVER_VMT[1] = {{ { GDRIVER_TYPE_TOUCH, GMOUSE_VFLG_TOUCH|GMOUSE_VFLG_CALIBRATE|GMOUSE_VFLG_CAL_TEST|GMOUSE_VFLG_DEFAULTFINGER, sizeof(GMouse) + GMOUSE_MCU_BOARD_DATA_SIZE, _gmouseInitDriver, _gmousePostInitDriver, _gmouseDeInitDriver }, ..., ... }};

Can you please create a test-case (smallest possible program) that allows us to reproduce the issue including instructions on how to reproduce it?

Very nice! We can't wait to see it in action.

There is no need to pass that GHandle around. Just make that GHandle a private member of your wrapper class. The reason we need those handles is because there are no objects in C. The handle is the object. When you wrap a C++ class around it, the object/instance of that class "becomes" the handle. This is how we are doing it (I stripped the unrelated parts out): wrapper.h wrapper.cpp

Participating in this competition gives you the chance of winning one of two new, unused STM32F746G-Discovery boards. The goal of the competition is to create a widget. The widget can either be something very generic or a more application specific widget. The only constrain is that it has to be useful in other applications as well. Basic information: Competition task: Create a widget Competition prize: One of two STM32F746G-Discovery boards Competition end: 2016-08-15 23:59 UTC+01:00 Rules: Any widget that is not already part of the µGFX library can be submitted. Only the author of the widget is allowed to submit it as an entry to this competition. The widget must work with the most recent release of the µGFX library. You are allowed to use any kind of help (don't miss the creating a widget documentation). The widgets of the winners will be included into the µGFX library. This means that the authors of the widgets have to allow the µGFX developers to re-license the widgets under the µGFX license. The µGFX developers (namely @inmarket and @Joel Bodenmann) are the judges and elect the winners at the end of the competition. Criteria: The competition entries will be judged by the following criteria: Stability & Flexibility Documentation Example / Demo Screenshot / Photo / Video of the widget in action Performance Submitting an entry To submit an entry to this competition, create a new topic in this forum. You are allowed & welcomed to create a topic before your widget is finished to post about your progress and to gather suggestions & feedback from other users. Please feel free to post any questions below.

You can use the GFILE module which provides high-level API to access and manage files. It comes with a backend for FatFS which would easily allow you to store your calibration data on an SD-Card. The diskio.[ch] interface implementation required by FatFS are already implemented for ChibiOS. Unless the newer versions changed something, you should be able to just use the existing code. Corresponding documentation: http://wiki.ugfx.org/index.php/GFILE http://wiki.ugfx.org/index.php/FATFS You can of course store your data however and where ever you want. The only thing that matters to uGFX is that the data you provide through LoadMouseCalibration() is exactly the same as the one you get from SaveMouseCalibration. In between those two calls you can do whatever you like: Store them in a file on an SD-Card (most common), store them in an EEprom, FLASH, ... Heck, you could even give your device internet access and store them on a remote web server

Glad to hear that you got it working! We added a note about this to the readme of the Linux-Framebuffer board file: https://bitbucket.org/Tectu/ugfx/commits/a972649d65b545031de1e88023acb39b1d7a26e3

the '??' are the "missing/unknown glyph" of the DejaVu font. It means that it doesn't know the glyph that it is supposed to render. The fonts that are built-in into the library have been encoded to be as small as possible. The filtering range most likely didn't cover the degree symbol, but it's just a guess. I'd recommend you to pick any font you like and convert it yourself, choosing filter ranges appropriate to include the degree glyph. The documentation tells you how you can use custom fonts. Well, the actual recommendation is to use the snprintf() equivalent of the GFILE module (which is snprintg() if I remember correctly). This way you don't have to include the string.h file from your clib and your stuff stays small and portable.

We'd strongly recommend you using the snprintf provided by the GFILE module. This way you don't pull dependencies from your c standard lib and therefore your program stays as small as possible and your code is portable across any platform. More information can be found here: http://wiki.ugfx.org/index.php/GFILE#String_manipulation_.26_printing Regarding the actual issue: You are using the UI2 font. This is a font that we designed ourselves to both look well at small resolutions and to take up as little memory as possible. Following the second goal, we kept the character set at a minimum. This means that the font only contains alphanumeric characters, numbers and some other special characters. Most likely the degree symbol is not part of the font. @inmarket might confirm this as he's the one who designed the font. Also, the UI2 font isn't an unicode font. It wont help to enable unicode support there. So to get a degree symbol on your display you have to use a font that actually contains the degree symbol.

Hi, Sorry that you have to wait so long. We are currently putting all our time into developing the next version of the µGFX-Studio and handling support requests. We are maintaining this community forum in our spare time. If this is time critical, please consider submitting a support ticket to the Technical Support department where your issue will be handled as quickly as possible. Other than that I can try to make some time to have a look at this tonight or tomorrow evening. For that, please upload a ZIP archive of an entire µGFX-Studio project that allows us to reproduce the problem.

Can you let us know what you had to do in order to resolve the problem? This means that the frame buffer provided by your Linux host is using a 24-Bit pixel format while your µGFX one is configured to a 24-Bit pixel format. You can overwrite the default pixel format by setting GDISP_LLD_PIXELFORMAT in your configuration file. You should be able to figure out which format your Linux host uses first.

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.