Joel Bodenmann

In order to make the label and the progressbar widget sending events you will have to modify the actual widgets code. What you need to do is implementing the MouseDown function and register the corresponding function pointer in the widget VMT. You can find the definition of the GWIN widget VMT in /src/gwin/gwin_class.h. However, for your particular case I would STRONGLY recommend following the advice I gave in your other thread (viewtopic.php?f=9&t=341#p2546) and implement a custom widget that does what you want for the following reasons: This is the intended usage of the GWIN module It is proper as it doesn't include any hacks or work-arounds It's a portable and future proof solution. You can upgrade to newer uGFX versions in the future without any hassle as all your custom code is outside of the actual library. Thank you for your feedback. We will consider this for future releases. ~ Tectu

Note that a progressbar is just a passive element like a label. It's only purpose is to provide a visual representation of something. A progressbar shows a state of something - the user is not supposed to interact with the progressbar. If you want a progressbar where the user can change the value then you want to use the Slider widget. In fact, the default rendering functions make them look very similar - just that the slider accepts mouse input while the progressbar doesn't take any input at all. ~ Tectu

Well, in this case it's not a workaround as being able to submit custom rendering routines is expected usage and in fact one of the main goals of the GWIN modules: Everything is supposed to be fully customizable. That is also the reason why you can submit your own window manager. Most other libraries don't offer this Note: Judging from the screenshots that you've shown in the uGFX-Studio thread it seems like you only need to be able to stack widgets because you want a special button that shows an icon, two volume levels and a text. Personally I think that in your case it's the best solution to write your own widget that does exactly that. I guess 90% of the rendering function of this new custom widget can be copy-pasted from the button, the progressbar and the label. That custom widget would then provide an interface like myWidgetSetLevelLeft() and myWidgetSetLevelRight() for the two volume progress bars and so on. As you only need one text attribute (again, judging from what we've seen in your studio screenshots) you can keep using the built-in text attribute from the GWIN base class. When you take a closer look at some of the built-in widgets you can see that most advanced widgets are implemented this way. Take the frame widget for example. The frame widget provides buttons in the window decoration (window border). However, these buttons are not real GWIN PushButtons. Instead it's just an area that gets drawn in the rendering function using primitive gdispDrawXxx() calls and in the touch coordinates handling functions we just check whether the touch occurred inside of those areas. The same applies to the list widget (the scroll bar) and so on. This technique allows to implement advanced widgets using very little resources. This keeps your application small and fast even when you need such an advanced widget as in your case. We are happy to help you where we can whenever you have any questions. ~ Tectu

Adding a drawing function for the label widget that doesn't clear the background (so it's transparent) is fairly easy and you can either do that yourself by creating your own custom rendering routine as explained in this article or we can add it to be an official built-in rendering routine for the label widget. It's really just a matter of minutes. The reason it's not there yet is because it doesn't make much sense. When you change the text of the label you NEED to clear the previous text - otherwise you'll just stack the two texts. Clearing the previous text happens through filling the label area with the background. When using a transparent background we don't know the background in the label rendering function so we can't clear it. This would mean that when using a label with a transparent background you'll have to clear the area yourself before the label gets redrawn. ~ Tectu

Yep, we thought that this won't work As mentioned this is untested as it is not the expected behavior / usage. Yes, that is correct. You can see in the implementation of the label that it didn't register any functions to handle mouse interaction (line 54:56): https://bitbucket.org/Tectu/ugfx/src/a7 ... label.c-43 The same goes for the progressbar: https://bitbucket.org/Tectu/ugfx/src/a7 ... ssbar.c-38 You cant (with the default implementation of the widgets as linked above). You'd have to create your own specialized widget class for that. As inmarket explained the best and most proper solution is to write your own window manager and register that using gwinSetWindowManager(). ~ Tectu

Both ChibiOS 2.6 and ChibiOS 3.x are known to work very well with uGFX. ChibiOS is what most uGFX users use as uGFX originated as a ChibiOS/RT extension/add-on. However, there's a known issue with the STM32F7 board files of uGFX and ChibiOS. It appears that the STM32F7 headers used by our board file and the one used by ChibiOS/RT are incompatible. Sadly we haven't had time to track down the issue ourselves so far. Last time we checked it seemed that ChibiOS/RT uses older headers than uGFX. But it's possible that it's the other way around or maybe the issue resolved itself by now - we haven't checked up on the state of the STM32F7 support on the ChibiOS/RT site of things for quite some time now. Note: The issues are really just related to the peripherals (LTDC, FMC and so on). The CPU part and all that magic works just fine. We would really appreciate it if you would have a look at the problem and potentially fix it. You can find further information here: viewtopic.php?f=23&t=334 ~ Tectu

A short follow up on the first post: If you'll implement your own widget and you need lists, take a look at the GQUEUE module. This module provides different (highly optimized) queues and buffers. The GQUEUE module is used internally by the GWIN module so it's already enabled anyway. This means that it won't add extra overhead. ~ Tectu

Well, that doesn't make writing that custom container widget easier First of all, can you please tell us what hardware you're using? Eg. the used microcontroller, the display controller, the used interface between the two and so on. It's possible to reduce the flickering with your current solution by just caching the image or by storing the image in the native format. ~ Tectu

When a container gets redrawn, it first clears the entire client area and then iterates through its list of children and redraws each child. This means that whenever you move your element by even just one pixel and in the container then call gwinRedraw() everything gets redrawn and that is what causes flickering due to low hardware performance. The implementation of the currently existing container doesn't allow partial redraws. Depending on your needs I guess the best solution for you is to write your own (container) widget from scratch that is specifically designed to contain a number of widgets that can be moved around and it will just redraw the background area that needs to be redrawn. Of course the actual implementation depends a lot on your needs. When the background is just a solid color then it will be very straight forward. If its an arbitrary pattern that is not known then it will be a bit more difficult as you basically have to buffer the entire background. Sadly there is no official "how to write your own widget" guide at the moment. However, it is rather easy and very straight forward. Basically a widget is nothing but a table of functions that get called by the GWIN module. There's one function that gets called when the widget is supposed to get redrawn, one function that informs the widget about touch coordinates, another function for when a key press event happened and so on. Nearly all of these functions are completely optional. As there are already a lot of different widgets available you should have enough examples to get started. If you have any question regarding the implementation of widgets we are of course very happy to help you where ever we can. I hope that helps. ~ Tectu

Yeah, we have seen that problem many times in the past. The ILI display driver family is a big mess. Anyway, happy that you got it working! ~ Tectu

Hello Kenneth and welcome to the community! I just verified that the gdispFillCircle() function is working as expected. Therefore, this must be an issue inside the driver that you are using. As every drawing function in uGFX, the gdispFillCircle() function will try to use hardware acceleration wherever possible. As the ILI9325 doesn't support hardware acceleration for circle drawing, it will rely on using hardware fills (gdisp_lld_fill_area()) or streaming (gdisp_lld_write_xxx()). Looking at the current state of the ILI9325 it seems like it doesn't support hardware filling either. Therefore, the problem must be inside the streaming function. To verify this, you can disable the hardware streaming support in the drivers configuration file (/drivers/gdisp/ILI9325/gdisp_lld_config.h). You should then be able to draw filled circles without any artifacts. Once you confirmed that that's the problem, the next step will be to figure out whether the problem is inside the actual driver itself or in your board file. As there's not much happening for hardware streaming in the driver itself (it's just wrapping the calls), the problem will be most likely in your board file. I hope that helps. Please do not hesitate to ask should you have any other questions. ~ Tectu

That sounds good to us! We are happy to answer any of your questions to help you figuring out what causes the problem with the F7 port. It's just that we are currently drowning in work so we don't have time to get to it ourselves. ~ Tectu

Glad to hear that you got it working - does this actually solve your issue/answer your question or should we still have a look this when we get to it? ~ Tectu

The built-in graph widget only provides very basic functionalities. It doesn't have an internal list of points. Each time the graph is redrawn you must redraw your points manually using gwinGraphDrawPoints(). This means that if you want to scroll your graph you'll have to shift your points manually using the process you described. If you have needs for a graph that can shift points I would strongly recommend implementing your own graph widget! ~ Tectu

Displaying multiple graphs at the same time is not a problem at all. You can have as many windows and widgets on your display at the same time. Just think of the graph window as if it were a regular widget like a button or a slider: You can have as many of them as you want, working independently. That is also why I used the term "graph widget" instead of "graph window" in my first post - to avoid confusion. ~ Tectu

uGFX comes with an existing graph widget: http://wiki.ugfx.org/index.php/Graph Examples: https://i.ytimg.com/vi/WcNgBEWWnrc/maxresdefault.jpg http://wiki.ugfx.org/images/b/b4/Graph_demo_640x480.gif Whether you want to use the existing graph widget or not is up to you. The graph widget is one of the first widgets that we created. It isn't the most used thing in the uGFX library and therefore we didn't spend a lot of time extending and optimizing it. Don't get me wrong, the code that is there works very well and there are many people who use it. It's just not the holy grail for all your graph needs. Writing your own graph widget would be very easy as the graph itself is not a widget but a window (read the GWIN article in the wiki for more information). The basic difference is that a window doesn't take any user input while a widget does. Therefore, creating a custom graph window is just a matter of using the already available GDISP drawing functions to make it look and behave like you want. You can look at the existing graph implementation (/src/gwin/gwin_graph.c) to learn how to implement your own, it's really straight forward. Please do not hesitate to ask should you have any other questions regarding the existing graph widget or writing your own. We are happy to help wherever we can. If you decide to either write your own graph from scratch or extend the existing one, we would of course be very happy if we can add your contribution to the library so others will benefit too ~ Tectu

Hello SimonRogers and welcome to the Community! Sorry for the late reply. We are currently very busy. Sadly I can't promise you that we'll have time to take a look at this before Monday morning. The last time we checked the demo worked the way it should. There are also a lot of users that successfully use the uGFX library with cyrillic fonts so we don't expect there to be a big issue. Did you try to use a different font? This article explains how you can use any Cyrillic TrueType font that you can find on the internet: http://wiki.ugfx.org/index.php/Font_rendering ~ Tectu

Hello Sillvers, You change the buttons text like you change the text of any widget by using gwinSetText(). API Documentation: http://api.ugfx.org/group___widget.html#ga0d2b40a6ef33c7be87f77876a94b9561 Please do not hesitate to ask should you have any other questions. ~ Tectu

Hello Kent and welcome to the community! I'll fix and update the project over the weekend. Sorry for the inconvenience! ~ Tectu

Nothing in uGFX is being redrawn periodically. When using a plain gdispImage you have to redraw the image yourself when it needs to be redrawn. When you are using the ImageBox widget the image will automatically be redrawn if it needs to, eg. if something covered it and moved or when the visibility changed. In either way, there are no periodic redraws. ~ Tectu

Well, glad to hear that you got it working Let's hope we'll be faster next time ~ Tectu

We are glad to hear that you got it working! Happy to hear that you like the uGFX library ~ Tectu

Using RLE fonts is the way to go then ~ Tectu

Glad to hear that you like what you see Note that you can run uGFX on any RTOS (or bare metal without any operating system at all). The decision whether you want to use uGFX or not shouldn't be influenced by the underlying system. Please do not hesitate to ask should you have any other questions. We are happy to help where we can. ~ Tectu

1. The most proper, most reliable and most portable way of doing this is creating your own widget that allows to input a date/time. The widget would behave just like the other widgets such as the buttons and the sliders: You can create an instance, you can place them anywhere on the display and you can give them any size. The widget would sent an event through GEVENT when the date/time has changed just like the slider sends an event when the slider position has changed. You can also add different functions eg. to query the current date/time and to change from 12 to 24 hour mode. Those are of course not necessary but writing a real widget helps you to add functionalities in the future while being completely portable. Writing your own widget is not as complex as it might look at the first glance. Essentially it is just a VMT (table of function pointers) where you register your functions that handle touch inputs and so on. Everything is nicely commented and documented. As there are already quite a lot of different widgets you have many different examples that will help you to understand how to write your own widgets. We are also happy to answer any of your questions (please make a new forum thread for that). I would really encourage you for writing a real widget for this. The widget class is really just a container and it won't be more difficult than writing this manually. There is one function that renders the widget and in that function you call gdispDrawXxx() and gdispFillXxx() functions just as you would outside of a widget and there are other functions that tell you when a touch happened and at what position. It's straight forward - really. Just read some of the existing ones and let us know when you have any questions 2. Using the gwinButtonDraw_Image rendering routine is the correct way of doing what you want to do. You can replace the image at any time by just calling gwinSetCustomDraw() with a different image pointer. That function will also take care of redrawing the button widget so you don't have to take care of that yourself. Important note: Many people want to change the image during runtime because they want to draw different images for the pressed and the released state. However, that is not necessary. .The gwinButtonDraw_Image already takes care of that for you: The image you pass by gwinSetCustomDraw() can either have one time, two times or three times the height of the actual button widget itself. When the image is twice the height than the button then the top half of the image is used for the 'released' state and the bottom half is used for when the button is in the 'pressed' state. The same applies to when then image is three times the height: Top for pressed, middle for released and bottom for when the button is disabled. Here's a very basic image just to make sure that you understand what I'm trying to say: