Joel Bodenmann

Thank you very much for bringing this to our attention and providing a corresponding patch. We just applied the patch to the repository: https://git.ugfx.io/uGFX/uGFX/commit/b9b555eae26a539ee71b30668f8e3fdb343e6ac1 Update: Blog post:

No problem Greg, you are very welcome Please don't hesitate to ask if you have any questions. We are happy to help wherever we can. In the meantime we also created another example widget: A statusbar. That widget actually reads the touchscreen coordinates and sends events. You might want to have a look at that one as well:

Personally I don't think that it will be any more complex to make it work with a generic tree structure rather than your application specific two-level forced approach. Actually, I feel like maintaining, debugging, extending & modifying will be a lot simpler if you go the generic approach. This way you only have one item to worry about, otherwise you will have to worry about two types of items. I've no idea about your setup, but have you considered having a main list and a back or up button instead? This way the user can select an item in the list, the list will clear and populate the area with the selected items children. That frees a lot of space which allows using bigger icons. The up- or back-button would allow the user going one level back. A community member wrote a custom rendering routine a few years ago for the list widget that converted the linear list into a grid of icons, similar to the app launchers of smart phones. This gives a lot of room for large, finger-friendly icons.

Hello Greg, We created a small example of a passive dial widget for you. We hope that this helps you to understand the process. First of all: I'm not a graphics designer. I created a simple dial face graphic in Inkscape and it took me longer to get that done than writing the rest of the widget code. So please feel free to ignore the dial face image and replace it with something nice looking in your mind: The button and the slider below are part of the demo/example program: The button can be used to enable a timer that automatically sweeps the needle over the dial. The slider below can be used to manually set the needle position. The widget we created is a bare minimum implementation example. We tried to keep the bloat as low as possible so you can focus on how it works without being distracted by "unnecessary" things. That being said, our implementation is anything but efficient and contains numerous limitations. There are many modifications and optimizations that could (and should) be made to improve resource requirements. The most important ones are: The widget expects that the supplied dial face image (last parameter of the dialCreate() function) has the same dimensions as the widget itself. The widget doesn't implement handlers for mouse, keyboard, toggle or dial input events. That means that it's currently a passive widget. Therefore, it could be implemented as a window rather than a widget to save a few more bytes of memory. The Polygon gets "recalculated" each time the widget is being re-rendered. That is not necessary. This can be optimized so that the polygon is only calculated when creating the widget. The entire image is redrawn when the angle of the needle changes. This operation could be optimized by just clearing the area the old needle covered. However, that depends on the dial face graphic. In our example you could just draw the minimum rectangle that contains the old needle using the background color. That wouldn't be possible if the dial face image also has "content" below the needle. The example program uses a PNG encoded image for the dial face. That is anything but efficient on a low-power embedded platform. The current version of uGFX doesn't provide anti-aliasing for arbitrary shapes. Therefore, the needle will look quite "zaggy" in some positions. You can reduce the effect by making the widget large enough. Theoretically it would be possible to use the existing slider or progressbar widget and implement the dial as a custom rendering routine. However, that would impose certain limitations when implementing handling of touch events. You can use fixed instead of floating matrix operations in the drawing function to transform & rotate the needle polygon to improve resource requirements. Along with that, you can use GMISC_NEED_FASTTRIG to use lookup tables for the calculation of the rotation angle rather than using the clib implementations. We hope that helps. Please don't hesitate to ask if you have any questions. Here you go:

There's currently no tree widget planned on our side and we don't know of anyone who would be working on one. You are more than welcome to pursue the idea Personally I wouldn't recommend having two different types of times. In a tree structure, any item/node should be able to have children. An item with children only different from an item without children by not having children, that's all. Having a list for the children in an item is the most straight forward implementations. However, you might also consider using just one global list. Each item would then have a pointer to its parent node. The order of the list determines the order of the children. That is how the GWIN module keeps track of all the widgets: As you know you can assign child widgets to containers. It's possible to create an arbitrary hierarchy/tree structure that way. But the GWIN module only maintains one global list. Note that you can always make a primary implementation to have something that is working and improve it later on. I'm definitely keen to see what you come up with. It would be an interesting addition to the library and I'm sure I'm not the only one who has multiple uses for that in mind

1) We recommend using ChibiOS. It's a great RTOS with an awesome community. µGFX actually started off as a ChibiOS add-on called ChibiOS/GFX. Although µGFX has become a standalone project we are trying to stay close to ChibiOS. Almost all of our regular in-house tests that use an underlying RTOS are made using ChibiOS/RT. Therefore, our recommendation is to use ChibiOS if you can and want to. However, µGFX will work on any kind of operating system. We have also used ChibiOS/RT with LwIP for some projects that involved TCP/IP and it worked great. There are also some official demos that use LwIP that come with ChibiOS/RT. Disclaimer: We have no idea what the current support status of ChibiOS/RT for the STM32F7 is. 2) Our users & customers use a broad range of different IDEs. Some people just use a text editor & make, others use Eclipse, Keil µVision, IAR, CrossWorks, ... the list is very extensive. Besides the financial aspect, the choice of IDE is usually quite subjective. @inmarket usually works with eclipse (using external makefiles) while I just use a text editor. However, depending on customer projects I also work often with Keil µVision and other IDEs. The choice really is up to you. You should definitely be able to use uGFX in Eclipse without any hacks. The recommended way is to setup an Eclipse project that uses external Makefiles. 3) Personally I don't know anything like that. I guess google will help although you will most likely end up implementing your own application specific solution. You can use the GFILE module of the µGFX library to interface files. It comes with built-in FatFS support. Can't wait to hear and see more of your project. Please keep us up to date

Great work, this seems to proceed quite well! I really can't wait to try it! Regarding the header color: In general adding new colors to the widget styles wouldn't be a huge problem as they usually end up in ROM/flash which is a lot less critical than RAM. The only reason why we wouldn't add specific stuff like this is because other widgets wouldn't have any use for it. If it makes sense to add a secondary fill color or something like that we are very open for any kind of discussion. Also, the end of the competition doesn't mean that it's the end of your widget development

We just ordered a display module with an ST7735 display controller. We'll get that driver done. Once we receive it.

Very nice work!

Don't worry about it. We all started at some point with absolutely no knowledge of C or C++ Good luck with your project. We are very keen to see what you come up with. Please keep us up to date! Also don't hesitate to ask if you have any questions. The forum is always available.

We have community members as well as industrial commercial customers who are successfully running µGFX on a PIC32 platform. You should be able to run µGFX on a PIC32 without any modifications. The code generated by the µGFX-Studio is 100% portable. If you have a working base-project that run µGFX on your hardware you will be able to just copy-paste the files generated by the µGFX-Studio to your project and it should just work. The studio doesn't generate any platform or system dependent code. I just remembered that we have also seen somebody running it on a PIC24. You should definitely be able to get this running without any modifications at all. It always takes some time until the first build works as integrating the library can be somewhat cumbersome for someone who doesn't know it well but that is where the documentation comes in and we are happy to answer any question we can.

We're sorry about the confusion with GINPUT_MOUSE_MAX_CALIBRATION_ERROR. That's a relic from an earlier/previous version of the GINPUT module. We'll look into it and clean-up / update the wiki accordingly. Please excuse the inconvenience.

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.