Joel Bodenmann

No problem! Never hesitate to ask if there's anything unclear.

This is one of the questions that can't really be answered in a generic way: It depends a lot on the circumstances, the available resources, how often the widgets are used and so on. Never the less I'll try to explain the philosophy behind the current version of the GWIN module in order to make you aware of some of the issues/considerations: The GWIN system can be used with fully static memory or fully dynamic memory. You might have noticed that you can pass a pointer to the corresponding widget object as the first parameter to each gwinXxxCreate() function. This allows to create a static object somewhere on the stack and the create call will simply initialize the required fields which is usually a very quick operation and never fails. If you pass a null-pointer, the GWIN system will automatically allocate the required object. Dynamic memory allocation is a very non-deterministic operation and can take up a lot of time. Therefore, if you need to switch the pages often and performance is a critical issue it's not recommended to destroy the widgets each time - that is if you have the required memory to spare. If there are any real-time constrains then you definitely have to work with static objects and therefore you are not supposed to ever destroy the widgets. Another issue to consider is that if you destroy a widget and you have to recreate it afterwards, you might not have enough memory to do so on an embedded system. Are you able to handle that case? If the user wants to open a settings dialog and you can't construct one this can definitely be an issue. In that case not destroying the widgets of the settings dialog provides the advantage that the required memory is already 'reserved'. Regarding the use of the same widget on multiple display pages: Currently a display page is defined as a container that covers the entire display area. Each widget gets the display page container passed as the parent argument. This way changing display pages is simply a matter of controlling the visibility of just the display pages. However, the display page container controls the visibility of all its children. If you hide a container it will ripple through and hide all child widgets in that container. This raises the limitation that you can't put a widget on a display page and simply show it on other pages as well: You'll have to create one widget for each page. In certain situations there's a work around: For example, if you need navigation buttons to change between display pages you can add the navigation control elements to the bare display and make all display pages smaller so that the display page container doesn't cover the entire area. Note that as per the previously noted definition of "a display page" this won't be a display page no more but just a regular container on the display. That's also the reason why the µGFX-Studio (currently?) doesn't support this feature. In order to stay away from the workarounds you're supposed to have one individual widget object for each display page. To summarize: One individual widget object per display page Only destroy the widgets if you have the memory to re-create them afterwards (or if you can handle the out-of-memory situation) Only destroy the widgets if you can cope with the resulting performance drop if working with dynamic memory. I guess that helps somehow... Please don't hesitate to ask if you have any other (more specific?) questions. We're happy to help wherever we can.

A widget like that (spin box) is on the ToDo list but with a very low priority. Due to other more important tasks we won't tackle this within the next couple of months. However, as you mentioned it's possible to create a widget yourself. I can recommend you having a look at our brand new "HowTo: Create a widget" article that is currently work in progress but already very usable: http://wiki.ugfx.org/index.php/Creating_a_widget Any feedback is highly welcomed. Let us know if you have any questions. We are happy to help you wherever we can.

You can get that information from the keyboard event structure. You are supposed to cast the generic GEvent struct to a GKeyboardObject to access the event arguments. You can find the struct definition at line 31 of the file /src/ginput/ginput_keyboard.h. I'd recommend you to have a look at the demo /demos/modules/gwin/keyboard which shows how to do all that. Please don't hesitate to ask if you have any further questions.

Please tell us exactly what doesn't work. We can't just guess. This applies to all your posts. Please inform us about the exact issue that you are facing. "Doesn't work" it not helpful at all. We are not going to look at that code and just guess what could be wrong I mean... we don't even know if it's a compile error, whether it just doesn't do anything or whether it crashes. We are of course very happy to help wherever we can. But we need the corresponding information.

The function gwinImageOpenMemory() expects a real image, not just a pixel buffer. An image consists of an image header and the payload. A pure pixel buffer is not an image. For this function to work, you'd have to create an image from your pixel buffer. To be a bit more verbose: You must create a BMP, GIF, PNG image. If you really want to do that: The easiest one to do is BMP as the image data itself is not encoded/compressed. You'd just have to add the BMP image header and it should work. If your display uses the same pixel format as the camera (RGB565) you could even go a step further and directly use the native image format. However, that's probably not what you want to do. The only reason why you would do that is because you want to store the images anyway or if you want to take advantage of the GWIN system features (visibility, translation, ...). If you just want to display your camera pixel buffer somewhere on the screen you should use the gdispBlitArea() function. API documentation: http://api.ugfx.org/group___g_d_i_s_p.html#ga5bc91fdc9d56fc51d278abfe4c0c50fa

You want to use gwinSetText() for that. API documentation: http://api.ugfx.org/group___widget.html#ga0d2b40a6ef33c7be87f77876a94b9561

1) You need to be more verbose. Please tell us exactly which values aren't saved properly and we'll take care of it. 2) That kind of behavior is not as easy to implement as it might look. The current solution is to properly split up the code into individual files. Also note that you can invoke custom scripts after the code generation. Many people use these to modify the generated code and to copy things around. You can find more information about post-generation scripts here: https://community.ugfx.org/articles.html/ugfx-studio/post-generation-scripts-r3/ I'd also like to take the opportunity to link to an article that our community member @king2 wrote where he explains how he works with the µGFX-Studio. He's a professional and explains how he optimized his workflow: Please leave any further feedback regarding the µGFX-Studio in the corresponding thread that you can find here:

I'd like to point out that the proper way of doing this is to implement your own custom widget. You can use the existing graph window as part of the widget or implement everything from scratch. In either way, your custom widget will contain a list of the points that need to be redrawn. Under certain conditions this can be optimized as @inmarket mentioned. You can find a guide that explains how to implement custom widgets here: http://wiki.ugfx.org/index.php/Creating_a_widget If you have any questions, please don't hesitate to ask. We are happy to help wherever we can and we'll improve the documentation where needed to clear things up. The only reason why you can use pixmaps is when you are using the single-file build mechanism. If you're using the makefile build system (or manually compiling each file) you should be able to use the pixmaps without any issues. There's no action required to use the pixmaps when you're using the makefile.

Glad to hear that you got it working! Thank you for letting us know!

That's the right decision Let us know if you have any questions.

Thank you very much for your feedback. We put everything into our ToDo list.

Hello Serge, Although the GINPUT module provides the necessary infrastructure to detect short and long clicks (GMETA_MOUSE_CLICK and GMETA_MOUSE_CTXCLICK), these information aren't being forwarded to the GWIN module. Each widget interprets the mouse actions separately as it turned out that meta information such as click and long-click have very little semantic use on the widget level. Widgets receive mouse down, mouse up and mouse move events. There's no "click type" or other meta information inside the GWIN module. There are two possible things that you can do: Manually hook up a listener to the mouse that receives and processes the click and longlick events provided by the GINPUT module. Then you'll have to map those to the button widget events. That's a very cumbersome solution and not the recommended way of doing this. Create a custom button widget that sends the click type information via the event structure. This is the recommended way of doing this. You can copy-paste the existing button widget (the files /src/gwin/gwin_button.c and /src/gwin/gwin_button.h) and start a GTIMER in the mouseDown() function of the widget and stop it in the mouseUp() function. If the timer fires within that time you know that a long-click happened, otherwise it was a short-click. You can then add that information to the event structure that is sent to the connected listeners. We strongly recommend following the proposed solution 2. It's the proper way of doing this and it fits the uGFX philosophy and won't cause any problems when updating to future versions. There's an article that talks about custom widgets, we strongly recommend giving it a read: http://wiki.ugfx.org/index.php/Creating_a_widget Please don't hesitate to ask if you have any questions. We are happy to help whereever we can.

@czhou Could you try the driver that's now part of the official uGFX repository and let us know whether everything works as expected? Thank you again for your contribution! We appreciate it a lot.

We took a look at the issue with the monospaced font. The problem is that the font that you're using is already broken. It seems like all characters use a width of 547 but the space character is only 500 wide. Therefore the font engine encoder doesn't recognize the font as a monospace font and the width calculations won't be correct. According to FontForge the font has some other issues as well. I'm sorry but there's nothing we can do if the font itself is broken.

I just checked your project configuration: The reason you don't see the startup logo is because the startup logo is drawn using a white color. Your startup color is white too so you just don't see it Note: You should take the gfxconfig.h file out of the uGFX library directory and place it in your Inc directory. It's part of YOUR project, not of the uGFX library. If you want to update to a different uGFX version in the future you just want to replace the uGFX directory. If you'd do that now, you'd loose your configuration file. I'm sorry but I don't understand your question regarding the FatFS. Can you please explain what issues you are facing? My previous post contained the information what you have to do. Yes, it's possible to dump raw pixel data anywhere on the display. You can do that by using the gdispBlitArea() function. For more advanced needs, you might want to consider the use of pixmaps. Note that the pixel buffer you pass to the gdispBlitArea() function needs to use the same pixel format as your display driver. Therefore, if your display driver is not using RGB888 you will have to convert the pixel format prior to calling gdispBlitArea().

That might be related to a rounding issue. Thank you for providing the corresponding font files - we'll have a look at it during the next week. Well, as you mentioned this topic has been discussed already multiple times. Please follow the advice/guide in the corresponding forum thread. Note that you will find other similar forum threads using the forum search. Especially note the known issue where pixmaps can't be used in single-file-compilation mode as the documentation mentions. We (inmarket) is currently working on resolving this issue. If you are not able to track down and resolve the issue with the existing information, please let us know what compilation errors you get. We can't help you if you don't provide all the available information.

There's no other dependencies for the startup logo. The logo is very crude as it's drawn with nothing but rectangles to ensure that it doesn't take up any code space and that it works on any platforms. If the GDISP module is enabled, the startup logo will show when GDISP_NEED_STARTUP_LOGO is set to TRUE. The µGFX-Studio is currently in beta and that for good reason: As you mentioned it's far from complete. Right now the µGFX-Studio is useful as a layouting and prototyping tool to get started quickly. Both the download page AND the "New Project Wizard" inform you that the µGFX-Studio is far from complete and not meant to be used in a productive environment. We are working on the µGFX-Studio but right now it has lower priority than the µGFX library itself. We are happy to hear your feedback, bug reports and feature suggestions in the corresponding µGFX-Studio forum thread: https://community.ugfx.org/topic/371-release-beta-v014/ After all the more user feedback we get the more we'll put time into it. What problems are you facing? You need to give a lot more information than just "I am having a problem" or "It doesn't work" in order for us being able to help you. As mentioned in the previous post you might want to start off using the built-in FatFS module to ensure that everything is working. Then, if you want to replace it with a different version, just replace the FatFS directory under /3rdparty. Depending on the changes to that version you will have to slightly modify/update the FatFS wrapper which you can find in /src/gfile/gfile_fats_wrapper.[ch].

The proper way of doing something like this is having to separate labels: One for the text and one for the numeric value. This helps with a. If you want to further decrease flickering (and improve the overall FPS performance) you might want to consider using pixmaps: http://wiki.ugfx.org/index.php/Pixmap The way you solve b. might be a bit over complicated for no reason: Simply use a mono-spaced font. You can apply a font to just one individual widgets. Therefore, you can have a monospaced font that you just apply to the labels that contain numeric values and you can use a different font for all the other widgets. You apply a font by using gwinSetFont(). Note that having one label per digit is a very bad idea in terms of flexibility and especially memory and CPU requirements. Regarding c.: I'm not sure what you mean. The label widget comes with three built-in rendering routines: Align right, align center and align left: https://bitbucket.org/Tectu/ugfx/src/25802124fb64a949971a89dd2ef34b749d949494/src/gwin/gwin_label.h?at=master&fileviewer=file-view-default#gwin_label.h-112 Please do not hesitate to ask if you have any further questions or if we need to clarify something.

Ah okay, sorry for not providing a helpful answer then. Glad to hear that you got it working, though!

I'm not exactly understanding your question / your concern. You are not supposed to mess with ginputCalibrateMous() or anything else yourself. Implement the board file and that's it. The struct you have in your board file allows you to configure many things like the calibration tolerances and so on. Don't modify anything else. If you are just using a regular setup with just one touchscreen there's also no need to ever manually use any of the GINPUT API. The ginputCalibrateMouse() function is called automatically for you unless you have disabled it. It's also possible to load calibration data that has been obtained by a previous calibration process. If the loading of calibration data succeeded, the calibration screen won't be shown on startup. You can find all the information needed here: http://wiki.ugfx.org/index.php/Touchscreen_Calibration

Are you able to drawing anything else on your display? If the startup logo doesn't show up when GDISP_NEED_STARTUP_LOGO is set to TRUE this most likely indicates that the display isn't working at all. This can either be a physical issue (eg. wiring) or an error in your board file. The µGFX library includes its own copy of the FatFS library for compatibility reasons and for ease of update. If you don't want to replace the actual FatFS directory in the /3rdparty directory of the µGFX library (which we don't recommend) we'd suggest you use the one provided by µGFX. You can access the built-in FatFS library from outside the µGFX library without any problems. Note that we strongly recommend to ALWAYS use the high-level API provided by the GFILE module. This keeps your application portable, allows you to use multiple file systems at once and brings a few other advantages.

Glad to hear that you got it working! Regarding the startup logo: You can find the corresponding setting in the configuration file documentation. It's explained here: http://wiki.ugfx.org/index.php/Configuration Look out for GDISP_NEED_STARTUP_LOGO

Yes. The linked forum post lists the available options: Use a library that provides working setjmp() and longjmp() implementations Get the provider of your library to fix their broken implementations (experience tells that they won't care much) Implement your own setjmp() and longjmp() functions Implement your own context switching assembly code in the existing GOS threading Use an RTOS Sorry, there's not much else we can do here. We try our best to be as flexible as possible but if the 3rd party underlying system is broken it's difficult to make something functional out of it. For instant success you definitely might want to consider using an RTOS. Personally I may recommend ChibiOS/RT and FreeRTOS.

Well either the registers are incompatible - in which case you might be able to simply copy and modify the existing code for the Cortex-M0 - or the assembly syntax used isn't compatible with the compiler that you are using which is a huge pain in the ass.