Joel Bodenmann

Ah yes, that's it. I thought that he removed it as he mentioned that but I guess he removed it just from the Eclipse project files tree thingy which doesn't influence the Makefile stuff when using an existing/external Makefile.

That's weird... did you perform a clean build (make clean) ?

Hello @Johnboy and welcome to the µGFX community! Your GFXLIB path looks correct. To me it seems like your GFXDEMO variable is wrong. You should remove the leading slash: GFXDEMO = modules/gdisp/basics

We can't help you just with these information. We don't even know what underlying system you're using, which compiler, how your GOS configuration looks like and so on. Please provide all of that information.

Hi, Thank you for bringing this to our attention. I'll leave to that to @inmarket as he's the one who wrote the win32 driver(s).

Okay, that makes sense. Sorry for the noise!

Oh right, that's it! Not sure how I could missed that with the forum search... Thank you @cpu20!

There's nothing on the forum but I remember having talked to someone who was successfully running µGFX on an ESP32. Unfortunately I can't remember who it was. There are definitely no technical limitations that would prevent you from doing it. But I understand that a sample project is always very helpful. I'll let you know if I managed to remember who it was... In the meantime, here's one for the ESP8266. Although that will most likely be completely useless to you.

Hi, The USERFS allows you to implement your own filesystem handlers. That is only used when none of the already existing file systems can be used. When enabling USERFS you have to provide your own implementation of the GFILEVMT somewhere in your application/project code. You can have a look at the GFILEVMT documentation/declaration and the existing file system implementations to learn how to do that. Additionally, there has been a thread on this forum already where somebody dropped some code on how they are doing it - that might help too.

I found two more things: Line 133 through 148 are obsolete and can be removed. Orientation handling is taken care of in the gdisp_lld_control() function as the display driver supports this natively. It's just dead code. Line 188 seems to do a funny or operation on zero. Looks kind of obsolete to me too unless I am missing something. Other than that the driver looks very well built and very mature. Great work!

You are not really giving us any information to work with. Did you check whether the software is still running? Do you have some sort of heartbeat? There are tons of examples. The most obvious one would be /demos/modules/gwin/button.

Ah, empty project name Glad to hear that you managed to get it working. Good work!

Hello @Werner and welcome to the µGFX community! The error message is pretty self explanatory: "Your directory contains spaces. Gmake barfs at that. Please define PROJECT. Stop.". Did you check your path? The last time I used ChibiStudio you were required to have it under C:\ so that should be the issue, but the path reported is relative so we don't know what it gets expanded to. Can you please first make sure that the expanded path still has no spaces and if that doesn't work please investigate that PROJECT thing. That is ChibiStudio related. I have no idea what it is.

Oh wow, didn't know about that one. Great!

I could watch your video - no problems with that. Did you make sure that the maxSize parameter you pass to gwinTexteditCreate() is sufficiently large?

Hello @PaulS, Sure, you can compile anything into a static or shared library. You just have to setup your compiler the right way. If the question is whether we have any guides for doing that with the µGFX library or whether we have support for that built-into our Makefile system then the answer is "no". But the process is the same as for any other thing you'd compile. In general you wouldn't really want to do that in most cases though. The µGFX library is very small and compiles very fast, especially when you use the single-file compile (when using our Makefile system, you can set GFX_SINGLEFILE or something like that to TRUE).

Hello @PaulS and welcome to the µGFX community! I can confirm that there is support for the touch via input system but currently none for the keyboard. It's simply missing because nobody needed it so far - there's no technical limitation or something. So it's really just a matter of writing the driver which shouldn't be too hard.

@ronan_rt?

Great work! We'll integrate your driver into the repository soon.

Hello @aeroman and welcome to the µGFX community! Thank you for sharing your driver with us, we really appreciate it. I gave it a quick look and so far it looks quite good. We've seen way worse. That's pretty good for your first driver, well done! I'm not sure on the command buffer thing but then again I didn't yet find enough time to properly investigate. I think that this is good enough to be included into the repository. The board file template needs to be created but that's easy. What do you think, @inmarket?

Hello @malachib and welcome to the µGFX community! I'm glad to hear that you managed to solve your issue and that everything is running now. Thanks for bringing the issue with the readme to our attention (again).

Hello @besitzeruf and welcome to the µGFX community! The unlimited license allows the license receiver (eg. a company branch or an individual) to use the µGFX library commercially on as many different devices from as many different products/projects as he likes as long as the license receiver is the responsible entity of the product/project. There are no royalty fees and it's a one-time fee. I hope that answers your question. Please don't hesitate to ask if anything is still unclear.

Great work guys! Much appreciated!

From personal experience I can confirm that that is indeed the truth. I'm gonna leave that to @inmarket as he's the original author of the makefile wizardry. It's complex, especially when things like auto-substitution of cygwin paths come in and so on.

Is it just me or is the demo missing the gfxInit() call?