Joel Bodenmann

I finally got my hardware back so I could test it out. You were right, there was a bug. It's fixed. Thank you very much for finding and reporting! ~ Tectu

Thank you very much for finding and reporting. I have currently lend my SSD1289 hardware to a friend - I'll digg into this within the following week. ~ Tectu

That's really impressive, thanks for sharing! I added your video to our demos section 8-) I also let the people from the ChibiOS/RT community know. Please keep us up to date. ~ Tectu

Note that this would require to save the actual information for the background display somewhere. The displays we are using are simple memory mapped display and we cannot afford double buffering or any other kind of "information memory". What I want to say: When you want to draw something to the part of a background window that is overlapped, then you cannot display it directly, so you have to save it to some other memory location. After the overlapping foreground window has gone, you have to read your memory to see what needs to be drawn to the newly revealed area. This would involve a huge amount of memory. ~ Tectu

I recommend you to take the gdisp_lld_board_template.h you can find in the driver directory and start filling out the needed routines. There's no real difference between 8- and 16-bit mode apart from how you actually talk to the display. You can take a look at the tdisp_lld_board_st_stm32f4_discovery.h which you can find in the HD44780 driver directory of the TDISP module. It shows how different bus widths can be handled. Just as a side note: Make sure your display itself is in 8-bit mode. Many of these display modules you get from e-bay required to change a solder bridge or any other kind of jumper to select the 8-bit mode. However, some just might need a different initialization value. ~ Tectu

I've added a full example using cyrillic fonts to the repository. You can find it in /demos/modules/gdisp/gdisp_fonts_cyrillic. I added some more documentation about how to use the font converter etc. ~ Tectu

Thank you very much for your contribution. Your work seems very good so far. I added the driver to the repository. Could you please give it a try to confirm that everything works as expected? You may want to tell me your real name, in case of you want to see it on the contributors page.

Uhm, that's strange... I'll try to find some time to look into this. Can you probably clean up your code in the meantime and upload the latest version? ~ Tectu

Did you make sure that it's not a stack issue? ~ Tectu

Hey mate, I'm sorry. There was a huge spam attack going on over night and I had to delete several accounts, most of which were inactive like yours. I observed that you where online many times but you never actually wrote something, so I thought you might have been some sort of scan bot. Please don't take this personally. You're totally welcomed here. ~ Tectu

Can you please describe what exactly you did? There happened some real life stuff and I won't be able to put together a full tutorial before wednesday. ~ Tectu

Maybe it would be a nice idea if we'd introduce some value widget. It would be like a label widget, but you can only display digits. You give it the amount of digits before and after the decimal point and then you can simply display integer values. It can then recognize the changes very easily and just update the changed ones. Let me know about your results. ~ Tectu

Redrawing any GWIN widget does indeed clear the entire widget are with the background color and redraw from ground up. The label does the same. To optimize this, you'd need to know the current content of your display memory and with most setups you don't do that (no double buffering). You'd first have to read back that pixel and then decide if it would need to be updated or not. Just redrawing every pixel is way more efficient there. However, usually you don't redraw yourself anyway. The widget recognizes itself when its content changed. As soon as you call gwinSetText() on your label, it will update while the others stay the way they are. ~ Tectu

Making a widget unvisible using gwinSetVisible() will clear the entire widget area with the currently set background color. That's the reason why you get a differently colored rectangle there. Furthermore, a widget does have a clipped area using gdispSetClip(). However, destroying a widget should reset the clipper - I'll take a look into this. To draw anything on the screen, you should just create a plain GWIN window and draw to it using all the gwinDrawXxx(GHandle, ....) API calls (Take a look at /demos/modules/gwin/basic). This will workaround your clipping problem too. ~ Tectu

I just found time to add a very small step-by-step guide to the font documentation. I hope that this helps for the meantime. Please let me know about any upcoming problems. ~ Tectu

You will have to use the toggle driver of the ginput module. You can find several examples on how to use it within the /demos directory (search for *Toggle*). Currently there's just the input driver for the ChibiOS/RT PAL HAL (I assume that is what you're using). Therefore there shouldn't be a lot of trouble to get it working. You can take a look at the example file for the olimex board to see how it's done. I'll add this to my ToDo list to write proper documentation about it. ~ Tectu

Why do you want to do that? The way it's meant to be done is that the button sends an event when it gets touched. In case of you want this to set some "pressed animation", that is also a job that's handled by the button widget. ~ Tectu

Which toolchain are you using? The recommended toolchain for ChibiOS/RT is the GNU ARM GCC. You may also want to run uGFX natively on you host computer to simplify the development process and finding bugs. ~ Tectu

The GWIN documentation mentions what steps need to be done for a custom render routine. You can also find a thread with sample code here. You can find all the required information about the widget in the GHandle: typedef struct GWindowObject { #if GWIN_NEED_WINDOWMANAGER // This MUST be the first member of the struct gfxQueueASyncItem wmq; // @< The next window (for the window manager) #endif const struct gwinVMT *vmt; // @< The VMT for this GWIN coord_t x, y; // @< Screen relative position coord_t width, height; // @< Dimensions of this window color_t color, bgcolor; // @< The current drawing colors uint16_t flags; // @< Window flags (the meaning is private to the GWIN class) #if GDISP_NEED_TEXT font_t font; // @< The current font #endif } GWindowObject, * GHandle; I'm going to prepare an example showing how to use cyrillic fonts within the following days. ~ Tectu

Yes, the code runs here too. Also, I suggest you to use GIF images for animations like your "WELCOME" text, if you have the required amount of memory. Furthermore, you don't need to create a window all over screen. This is automatically done when you initialize GWIN. You're also using the old fonts. Make sure you read the blog from time to time. ~ Tectu

Hello debayan and welcome to the forum, I just grabbed my embest board and flashed a working button example. Then I rotated the display and everything is still working nicely: gdispSetOrientation(GDISP_ROTATE_90); Could you please attach your code? On what release are you? I tried it out with the current master. ~ Tectu

Hey man, sorry that this took a bit longer than expected but I finally found time to include it into the repo. It looks good to me so far. Can you please get the latest master and try to use the implemented driver? You may want to tell me your real name for the contributors table. ~ Tectu

Can you please show how to reproduce your problem? The source does clearly show how the passed handle is used: void gwinDestroy(GHandle gh) { // Remove from the window manager #if GWIN_NEED_WINDOWMANAGER _GWINwm->vmt->Delete(gh); #endif // Class destroy routine if (gh->vmt->Destroy) gh->vmt->Destroy(gh); // Clean up the structure if (gh->flags & GWIN_FLG_DYNAMIC) gfxFree((void *)gh); gh->flags = 0; // To be sure, to be sure } ~ Tectu

This clearly is a documentation typo. It's supposed to be gwinDestroy(). Thanks for finding, it has been fixed! However, if you need different sets of controls, the tab widget might be of your interest too. The /demos/modules/gwin/widgets demo shows how it can be used (along the very simple example on the tab widget documentation page). ~ Tectu

Two lined button text is currently not possible. Of course you could add the text in the image of the button, if you're using the custom rendering routine. Please open an appropriate thread for future questions. ~ Tectu