king2

Thank you for answer! You have mentioned that "We will eventually add a transparent background rendering option of the label widget ourselves (I put it on the ToDo list) but this won't happen before the weekend for sure." in other thread. I know how to achieve this right now (and wrote this already), but question was about how to do it right way (assuming 'label allowing transparency' is a part of stock uGFX). I mean that in future user (developer) can use label as now (with background) or can use it without filling label's area. So, label should have special parameter to turn on transparency (turn off filling). Draw routine should call function with fill or not, or just use this parameter to call one function with additional parameter (instead of both existing functions). So will be function like SetBackgroundFill(ghLabel1, FALSE), or wi.donotfillarea = 1, or something like this? I understand that transparent label requires clearing its area before it can be redrawed safely - in some cases (when changing text), or not (when changing just color of text, for example). So I try to guess right way how to do it, to be consistent with built-in transparency later. What about my own color formats and rewriting code, I always try not to make changes that can be avoided and i hate doubling of code like in two functions mentioned in previous message (may I got this some time ago while working with CPUs that had little RAM and ROM space), so it strange for me to trade firmware space for readability of code. This is why I asked about reasons to write two functions (with code overhead) instead of one.

Going deeper into uGFX. How you would implement label with transparent background (i.e. without fill_area)? We need to determine will we call fill_area or not in draw routine (or call one of functions above, or mix both functions into one with new 'fill' parameter). But how we can know that user wants label to be transparent? We cannot use special color for transparent color, because we have no unused color values. So we should add new parameter to label? Can customparam be used for this or this is not a good idea? Also I see two functions - gdispGFillStringBox() and gdispGDrawStringBox(), which differs only by couple of lines (assigning colors and calling fillarea() - fill label area or not). Why was choosed this method of drawing string line by two functions? Why not use one function with parameter, to fill label area or not? Thanks!

No, it won't work at all. When I trying to run it with command: mcufont import_ttf scada.ttf 20 it terminates with message: This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. I have tried this on Windows 8 64-bit and Windows XP 32-bit with same result. I have tried to convert font DejaVuSans.ttf from fonts directory - same error. update: My friend gave me access to linux shell where linux binary runs fine without core dump (on second try), so I can convert fonts now. Multi-range is working, thank you! But windows binary needs to be repaired..

Maybe I overlooked this? How I can supply multiply ranges to mcufont.exe?

I have read both articles and finally got font (maybe it will be useful to write in online converter that custom range should be set not in character codes, but by characters itself?) I got file with size of 251k. I cannot use two fonts because I have to use digits and cyrillic chars in one text. I think multiple ranges is a good idea to save firmware space.

I want to use cyrillic characters and as well as latin, digits and some symbols like 'micro'. How can I convert font? What should I supply as range? 0-451 to get digits and cyrillic chars? Can I supply multiply ranges to get rid of characters that I do not need? Thanks! update: online converter has maxlength=1 in custom range fields.

According to "You are using an un-tested compiler. Please report any compile errors or warnings on the ugfx forum" I reporting warnings here (IAR): (orientation_t and powermode_t): Warning[Pe767]: conversion from pointer to smaller integer gdisp_lld_STM32LTDC.c 318 Warning[Pe767]: conversion from pointer to smaller integer gdisp_lld_STM32LTDC.c 320 Warning[Pe767]: conversion from pointer to smaller integer gdisp_lld_STM32LTDC.c 327 Warning[Pe767]: conversion from pointer to smaller integer gdisp_lld_STM32LTDC.c 331 Warning[Pe767]: conversion from pointer to smaller integer gdisp_lld_STM32LTDC.c 333 Warning[Pe767]: conversion from pointer to smaller integer gdisp_lld_STM32LTDC.c 357 also: Warning[Pa093]: implicit conversion from floating point to integer gdisp.c 1728 Warning[Pa093]: implicit conversion from floating point to integer gdisp.c 1729 Warning[Pa093]: implicit conversion from floating point to integer gdisp.c 1855 Warning[Pa093]: implicit conversion from floating point to integer gdisp.c 1856 Warning[Pe767]: conversion from pointer to smaller integer gdisp.c 2676 Warning[Pe188]: enumerated type mixed with another type gdisp.c 3308 Warning[Pe188]: enumerated type mixed with another type gdisp.c 3368 and last: Warning[Pe1105]: #warning directive: "GDISP: GDISP_NEED_ANTIALIAS has been set but your hardware does not support reading back pixels. Anti-aliasing will only occur for filled characters." gdisp_rules.h 65 I'm using STM32 LTDC driver, that uses part of SDRAM as videobuffer, so reading pixels is possible.

Thanks you for patience. 1. You have added to button possibility to be an arrow, to have rounded corners, to be elliptic, to react on keyboard or dial or touch panel. All these possibilities have corresponding defines that can be enabled or disabled. One more define like GDISP_PASSIVE_EVENTS can make possible reacting on events, so no resources will be lost for users who do not need this. This matches your guidelines about flexibility, power and compact code in one box. I do not understand difference between elliptic buttons and label event generation. Just one more feature that can give more flexibility to user. 2. It is not necessary to implement full event stack for window manager, with full path to parents and so on, I know what is embedded and memory limitations. WM already can handle clicks on widget's area, so we can just generate one single event in situation when event not generated now. I have attached patch in previous message, and label generates event without any problem. 3. It is strange to listen reasons about code size, memory limitations and method with replacing WM or custom draw routines in one message. WM can be replaced at runtime, as well as custom draw routines. So I will have in my firmware stock WM compiled in, and stock draw routines compiled in. All this code will not be used but will take place in final firmware. So, size overhead will be more each time we replace some code at runtime. 4. I understand that Studio is beta, but can not agree that Studio can be used only at start point. It looks like Studio will allow full development process in 0.13 - 0.14 (i.e. in a weeks). It will allow possibility to be used in late stages of development, will it be suitable for this or not - it is not so important. 5. I can make myLabel with events, or I can modify core Label. I agree that modifying core code is a bad idea, but as result I will get same problem - I need to change code when I will upgrade uGFX. Or I will need to apply my patch to core Label, or apply changes in core Label to myLabel. 6. Problem with only one event at a time exists now and will exist later - if I will click two buttons at one time and will not detect event in main loop - I will lost one of these events. Label that can generate click event not differs from another button in window. In other words, there is no need to change event system. Adding events with defines into main repo will not break anything, and will consume no additional resources except few kilobytes for sources on hard drive. Adding events was tested and works well for me. Replacing entire code with another that differs by 1% at runtime - bad idea consuming much more resources in firmware. Adding fullstack events and WM with overlapping objects is not necessary, because now all works well. I'm too deep in uGFX, so I have to use it. I will copy-paste widgets into new widgets with events, or will change them in core code - I do not know. It is simpler to change core code (as this already done), I will get no advantages in upgrading if I will make new set of widgets. I will use labels, progressbars and button as now, one over another, without writing new widget like 'ImageButton with text and progressbars'. Overlapping works fine, I will just react on events in main loop: just one event handler for progressbars, label and its button in switch(). Event generation by labels and progressbars will solve all my problems in GUI building, without need to make new event engine or window manager and without code overheads in firmware. Thank you about mentioning this, but I have no possibility to make such donations (average salary in your country and in my country differs). I think I wanted too much. Sorry.

I programmed on Delphi/C Builder in 90th, and it was great approach - you make display page visually, and then add reaction on events. This was pretty simple to use and to understand. Place items, write event handlers. App is ready. All widgets (all, even label) had basic events like click, dblclick, mouseon, mouseout and similar. If you clicked on label, label's click event raises. If you missed on label and clicked on its container, container's click event was raised. If you missed on container too, window click event. One idea, one behaviour. Was no items with physical possibility to click on them, but with no click event. Each click event was detected, counted, carefully wrapped into gift pack and transferred to its receiver. Or its parent if we was missed a little. "Widgets are defined by their functionality, not by appearance". What if I want to have text label that can be in 4 states? And it really text label, by appearance. Should I use special checkbox with extended quantity of statuses, or write special widget, or use listview with my custom draw routine, producing more and more copy-paste code just to keep idea that 'everything with more than 2 states is listbox'? This is unusual behavior for text label, ok, but why not take label as is, with its excellent appearance (95%), and allow to programmer to add unusual behavior (5%), instead of rewriting it all by copy-paste? What will break if static object will send events? I think I will never understand this.. uGFX allows programmer to customize many things. Plain C allow programmer to customize everything. Sorry, I will not write such thing anymore.

OK, I got the point. So, my patch is useless now for me too, because it will be not applied to uGFX. I can use button instead of text label, but can I have button without border? With auto-width? With word-wrapping? In Studio? This means for me that I have to write my own custom draw routines and widgets for almost everything and makes Studio useless. Thanks for clarifying your position.

Thank you for answer! Indeed, because these reasons TTF engine is not best idea ever

I have forked current uGFX, cloned fork to my PC and added events to text label, progressbar and container. Event numbers - just increments from existing numbers. I cannot make pull requests on uGFX repo (or I do not know how to do this), so I attached patch to this message. If patch will be applied before main repo will change - all should go without problems. I have not added events for image and graph because it is not widgets and have no widget's VMT. patch.zip

If I will make patches, and patches will be applied over uGFX, I will save my time by NOT changing code in newer versions I really think it will be useful even if I will make my own widget, just to make things better (for future users). I use text labels to display values, but I want to change value's units, for example A, mA or uA for current measurement. Best way for me - allow user to do it just by tapping on value, and.. I can't! I will add events to uGFX passive widgets and send patches.

I have changed already gwin_label.c exact way you pointed in your message. It works. Custom widget requires me to write widget with: - progressbars or not, its positions - text or not, positioning, font, fontsize - changing image - ability to react to text tapping as button click, or just as text tapping Each time in similar situations I'm afraid that I will code not so good, or will miss something, and my code will be bad and ugly. After all this, I will get widget that I cannot use with Studio For me, fast way now - is to use event approach I think that modifying core code is a bad idea, this because I'm asking about chances this changed to be a part of core code in future. I can modify library code by myself and send patches to you, if it will be useful and will simplify including this changes into future releases.

Thanks for pointing me to slider. They looks so similar.. But anyway, is there any chance that even passive elements will make touch events in uGFX? If yes, I can just add sending events to uGFX lib for temporary use, and use this approach in future when events will be added to main branch. If yes, I can just react on such events. If progressbar or text label was clicked, I can just send button's click event. If button was clicked, I can just redraw all elements over it. And second reason: I believe that all objects should react on clicking, this makes all widgets similar. One type (widget), one way to react (send click event when clicked). Any tap should raise event associated with some object (widget, or container, or window). I believe this will add flexibility to library.

OK, i got it. But why progressbars exists if I cannot get its change event? OK, tapping on text label will not used by all users (but it will be useful), but progressbar is active widget! User can change its value, but without method of obtaining change event it is just a visual element. I do not understand...

Sure, I can write workarounds, but I hate too much workarounds, especially ones that copies 99% of original code I understand that transparent background requires to redraw underlying objects. I can do it (refresh my button) by myself when updating text in label (but it will be better if this will do window manager for all underlying objects). OK, it is point to decide will I write my own window manager, transparent text labels, sending events by labels and progressbars, and so on, or not... Thanks for answers..

I have tried to disable text label placed over button. This not works Button was not pressed when I clicked to text label over it. This looks like text labels cannot generate touch events at all. As I understand, progressbars too. How can I know in my application that user was tapped on progressbar (value changed) or tapped on text label?

I have read thread about how to make text label with transparent background. As I understand, still no label transparent background patch in uGFX?

Hello developers! uGFX uses converted fonts. If user will use several sizes of same font in application, this approach requires much space in firmware, one for each size. Did you tried to use direct embedding TTF to firmware? In some cases this can save space and make firmware size smaller, and will allow to use any font size! I found gdispScaleFont in gdisp_fonts.c file. Can I use it to reduce space required for fonts if I need same font with different sizes? Thanks!

In my project I must have buttons with other elements over, for example, labels and progressbars. My button is button that have picture and some info inside it, I must refresh some info displayed inside buttons (and I use progressbars to show audio level). You can see screenshot here: viewtopic.php?f=28&t=243&start=80#p2485 But I have a problem, when I click to button, button itself if rising and all other elements is hiding. I need to have them displayed over button all time (more, I need to have button pressed if user was tapped over any area inside button). Can I do this without breaking everything in uGFX?

I looked at graph widget. As I understand, it have no ability to add new point when shifting old points to desired direction, right? So, if I want to make something like slow oscilloscope, I should: - add points to widget, until x=max (this fills empty area with points, one point in a tick) - then for each new point in each new tick I should: - shift data array like Y(n-1) = Y(n) - Y(max) = new value - redraw entire widget with all points from data array Is it right?

Thank you! Sotty, I have overlooked 'Graph', it looked like some abstract module for me

Thanks! But can I place three graphs on same window with another widgets or I can use it as one main window only?

I need to paint graphs in my application, three of them, like in oscilloscope. I cannot use second layer of LTDC because I'm using 800x600 screen and FMC SDRAM, and displaying second layer makes STM32 crazy (not enough bus bandwidth). Should I do this completely manually or uGFX can make my life easier? Can you provide me with some starting point, where to start at? May be some code examples or advices? Thank you in advance!