chodzikman

Sure, it is fine when you need to write a new thing like a widget, but if I want to replicate a solution or understand/debug something visual inspection of inclusions greatly speeds up the process. The other thing is some of your customers might need to stay along with standards like MISRA C, in this case you will have static code analyzer that checks compliance with allowed subset. (the other thing is if uGFX is anywhere near the subset and if you are interested in this part of market)

I forgotten to ask you to split these two topics Ok, this is exactly the way I am thinking about it. Just wanted to make sure that I am not thinking against design pattern here BTW, In my Eclipse environment I am constantly dealing with ifdef 'misunderstandings' from Indexer Everything else is working fine, but this is somehow frustrating and prevents me from creating tutorial. Maybe some other users will have some ideas...

Ok, additional question: is there any desired pattern for testing if flush operation is completed or should I just test DMA peripheral 'low-levelish' directly inside draw pixel?

I recommend you this one (I guess you will have local distributor of this company around): https://riverdi.com/product/rvt4-3b480272cfwc81/ Or just plain FT800/FT801/FT811 chip to connect standard 4,3" RGB module It seems to be quite popular, and I have been using this chip for one of the projects, so I can advice on any problems

I have to point out that at this moment it is hard to implement uGFX driver for displays that works in approach of command list (this is similar situation as with FT80x), since they have clear limitations with standard pixel drawing method. It can create huge value for some customers if uGFX could create list of primitives to share with graphic coprocessor, since it can allow better styling capabilities than enginge built in hardware driver. As far as I know uGFX would be the only library to provide such behavior at the moment. What I meant was contribution to the library with expansions (hopefully) consistent to current design patterns by simply adding new Optional Routines. EDIT: there will be still some problems with handling texts

Hi, I think you can search where gdisp_lld_fill_area() is called when you draw rectangle primitive, implement draw_circle as gdisp_lld_draw_circle() and add call to this funtion in circle primitive routine same way as it is called in rectangle and proceed with each accelerated functions.

Hi, Woudn't it be nice to have optional C++ wrapper on top of existing gwin functions to simply group all possible calls and its structure for each widget instead of passing pointers to them? It should significantly improve ease of writing it in C++ based systems. The library itself looks for me like it was written with this in mind, what do you think?

Thank you very much, by now I think I know everything to do it following your concept for the library. I didn't noticed these flush calls during my quick research.

Ok! Thank you for the info. I want to add this double-buffering feature (I'll have some time for it within two weeks hopefully - next week I am at Hannover fair...), but I have just jumped through code and the way I want to implement it would require some kind of additional trigger from higher layers - It could be either sent automatically on redrawing widget finished or manually by user. It can make it a bit ambiguous for programmer (manual buffer-swap triggering) or (in case of auto-triggering) make some visible delays between drawing each widgets on lower memory throughput (for example 4 big widgets in each corner of the screen, 8-bit data bus for SDRAM and 4.3" display) due to DMA buffer copying time. Maybe you have some other ideas / advice? As far as I understand, If i were to implement it with the spirit of existing code, I should add definition option for LTDC in main config file and include my code in corresponding ifdefs. Should I know about anything else regarding name convention or anything else? Again, perhaps there should be a guideline for contributors. Perhaps in V3 some generic events/flags from higher levels to the driver should be implemented to create generic way to make display drivers rely on some of driver-specific synchronisation features? (Maybe it already exists and I haven't found it) How it behaves now on larger LCD TFT drivers with slow serial communication? Is it efficient enough (not visible) to draw pixel by pixel instead of sending longer packets? Regarding contribution to V3 - I don't want to promise anything, but I find it interesting to work a bit on things you written in my spare time.

Ok, thank you for the information, it's a start. So few more questions: -Is V3 branch in repo usable at this moment or not at all? -If I want to contribute some high level features, is it possible? Should I do it for V3 or V2? (perhaps I'll write more advanced graph widget)? -If I want to contribute some low level features, is it possible? Should I do it for V3 or V2? (perhaps I'll write driver-dependent advanced anti-aliasing for primitives)? -Are you interested in low-level double-buffering LTDC for 2.x? It would behave like this: Declaring two framebuffers and two pointers, writing to buffer which is hidden, when finished, buffer pointers are swapped and DMA mem2mem is requested to update hidden buffer. It will prevent screen tearing in some rapid redrawing stuff without changing any high-level behavior If you want to gain more contributors to the library itself, I'd recommend you to insert a guide on the wiki, at this moment it feels a bit like you want to develop core of library by yourself and let users contribute some high level stuff (which is understable for me, but it would be better to make it clear).

Is there a list of TODO / new features for version 3.0 available? Also what is planned time to officialy introduce it? I would like to convince my company to purchase the licence, but at the moment it lacks some features which surely will be pointed out (most importantly double buffering for LTDC driver - just by now I can see screen tearing on simple graphs, also anti-aliasing on primitives as an option). Don't necessarily want to feed you with the list of features which hopefully are already on the schedule. On the other hand, regarding release date, don't want to bother implementing needed functions on older version and then challenging compatibility issues. Also at this moment if I want to contribute some code to the project, I risk messing with your plans / vision.

I wanted to check it one more time (also I have figured out problem with Indexer), and suddenly magic smoke escaped from my board due to ESD I am going to receive new one in few days, and will let you know then, ok? BTW I also had some questions regarding more advanced stuff in library, but in this case I need to pass until I will get new one

Hi, I am afraid that implementing FT80x driver is not that simple task since communication with this driver is more like communication with OpenGL library. You are creating command list and as far as I know even if you can draw single pixels it is very ineffective way and display list is 4k or 8k so direct drawing is VERY limited. On the other hand, It is a bit irrational to implement whole library like uGFX to drive such advanced chip which design goal is to get much simpler MCU while achieving nice looking LCD-TFT UI Attached is example how to draw a clock using this chip from its manual.

Attached is template project for Eclipse for F746 discovery (4,3" cap-touch screen) based on make template project from downloads. It was created in Neon.3 CDT version with GNU ARM Eclipse Plugin (no vendor-dependent plugins). Should be added to workspace using Import feature. Works out of box on my machines, including debug features. Due to some search path problems with static code analysis errors and messages are based entirely on GCC output after build (static analysis disabled). When I will find some time, I will try to write some description how I have done it. Please let me know in case of any problems or just that it works properly. f746_downloaded_make_eclipse.zip

Ok, Don't get me wrong, makefile managed Eclipse project is quite consistent way to work (I am not used to do it that way yet, but I need it also for other reasons, most important thing is that your build system is independent from IDE and fully replicable which is essential in continuous integrity development). Again, my thoughts are targeted to beginner who is already pretty much confused with all toolchain / openocd / gdb stuff, it is another thing to distract. I have read (or at least saw) all these guides and found it useful, maybe I am too much concerned about sweet-candy user experience in project targeted to devs (on daily basis I deliver solutions to end client)... Perhaps consistent template projects for more IDEs makes same thing. Thank you for the explanation about config file. Regarding Elixpad - surely I want to try it, I would welcome this binary, but I'll get on it after I get rid of some legacy stuff that bothers me (probably next week or so) Thank you very much for your support, not only it is helpful but also engages me a lot!

Thank you! I also have made long trip between IDEs, at the moment Eclipse feels most comfortable (and I am used to its shortcuts and specific behaviors), but now it makes my butt hurt a lot since I need it to use it in some other than stock (autotools) ways. Does your Elixpad support code completition, call hierarchy etc? If so, is it available to try anywhere? Only mentions I have found were your posts on Qt forum At the moment I am more than busy, but pretty soon I am going to use uGFX in some private projects. I guess I will continue using bare Eclipse with gnu-arm-eclipse-plugin, and when I'll break all the issues I'll share template project for DISCOVERY F746 I personally think that makefile-oriented system is making uGFX less eclipse-friendly. What benefits it gives that cannot be achieved in other ways? Also, don't you think, that example config file should consists of all available options set to FALSE instead of being commented out? (or just commented defines without TRUE / FALSE)

I have few ideas, but they are based mostly on my STM32/LPC and Eclipse experience. Ready-to-run examples for most popular boards are good idea regarding quick-start / demo, but to make it easy to port into your target application and use uGFX in multiple projects, preconfiguration tool could do the job. I imagine it would allow you to choose your IDE, processor family, used display driver and if needed peripherial which handles it, library modules and get template project for your IDE with gfx_config.h in place. Perhaps it should be designed with possible integration to uGFXStudio in mind. In my case selecting System Workbench for STM32 and receiving static library project and configuration file ready to run with CubeMX generated base project seems do the business. BTW I guess most people (especially hobbyists) nowadays generates init functions in CubeMX or similar tools for other manufacturers and possibility to easily integrate library with auto-generated project from it could be a huge advantage. Maybe cooperation with ST to integrate uGFX as third party block inside CubeMX is possible? I guess it should (I have slightly cooperated with them during our student society project and it was fun). It can be nice for them regarding their marketing (if they don't have some sort of exclusive contract with SEGGER). Oh, I almost forgotten that I created this topic to get better environement for working with it at this very moment. Please let me know what is your setup to develop this library, I am pretty sure it will save me some time

Hi, I have been playing with uGFX for a few days, I have made it run on STM32F746 in few different approaches, yet have not found comfortable way to work with it... I have built sokoban example and template project from downloads and launched it, made few very simple tests with buttons, labels etc, then imported makefile project to eclipse, force it to properly build project and launched it with debugger an (static code analysis fails at some points but yeah... surely can get rid of it), yet it was a bit painful way, and still I have had some problems with config of library itself... IMO improving its portability (not meaning platform-wise - it is quite impressive just now, but across IDE's) should be one of the essential goals to reach. I would be more than happy to help on this, but first I need to get more familiar with library itself and at the moment I feel a bit like I am missing something... Please advice or let me know about your setup. And keep working, at first glance it looks very interesting and powerful library driven by community!

I think it is a neat start. Perhaps F746DISCOVERY is also desirable due to capacitive touch and most popular size of screen, but if you want to stick with 2 platforms, I think F429 cuts the mustard. Thank you for considering my comments

Seems like I feel invited Looks like a job for continious integration system like Jenkins New lib release -> rebuilding (and /or remaking IDE templates for) all examples -> tickets for testing -> new examples release At the moment I am implementing similar behavior of our company repository code (not a huge company, ), so in future I may share my experience if you want to. What I actually meant in first post is that you have examples for some boards but as source + makefile, at work it is not certain that you can fulfill i.e toolchain dependencies in few minutes for multiple reasons. Therefore running automated make and binary upload of this demos shouldn't be a problem and since ST-Link2.1 has drag and drop behavior you can test this demo on your discovery board 5 minutes after googling this library. Cheers!