David Kibble

Thanks Guys. Done and working, just detached the source when screen back light goes off then I use a periodic check on the ginputGetMouseStatus() to detect a touch and re-attach the listener. Did that so that it doesn't matter where on the panel is touched.

Thanks Joel - you are a star. That sounds much cleaner than hacking the core uGFX code. I'll have a look at what's needed for the gwinDetachMouse(). Dave

Hi Guys. I'm after some advice on where and how to modify the ginput code so that I can catch and if necessary block a mouse (touch) event. The reason for wanting to do this is that for bedroom usage I need to turn off the backlight of a control panel, that's easy - if no use for > some timeout turn off the backlight. So when it comes to turning back on, I can easily capture a touch event, BUT the problem then is the user might have touched a button without being able to see it triggering an action they may not want, so we need to say "If backlight is off, catch touch event and turn backlight back on but do not pass that touch event to any widgets for processing". I can see a few places where I could add that sort of code, such as within the gmouse_lld_linux_event.c (I'm using a Linux board) or within ginput_mouse.c itself. Or is there a better way to tackle this? Many thanks in advance. Dave

Many thanks - that got it. Maybe it would be worth putting that vital hint on the Wiki in the custom board section along with a sample project and board makefile?

Many thanks

Hi Guys. Could you please give me an official steer on the use of local GHandles. Your examples and Studio always generate global scope vars for all GHandles, but is there actually any problem in taking the approach of using local (within a function) GHandles for graphic entities which are transient and modal such as dialogue boxes? For example you could have a function; showDialogBox(...) { GHandle container; GHandle button1; GHandle button2; etc etc gwinShow(container); <event loop waiting and processing modal events for button 1 and 2> gwinDestroy(container); } I prefer this style wise as it contains the variables and logic, reduces the sheer volume of global vars which you end up with on a large UI project and creates a more easily reusable component. But - are there any negative side effects within uGFX of doing this? I ask because I'm getting some odd behavior now on a large UI where container hierarchies are not redrawn properly and before I start diving into my code, it occurred to me I should check the above pattern with you guys. Thanks

Hi Guys. Not having much luck with this. Following the above advice my project makefile looks like this; GFXBOARD = Linux-Framebuffer-Touch_A13 ... include /home/dkibble/workspace/TouchControl/Linux-Framebuffer-Touch_A13/board.mk The TouchControl/Linux-Framebuffer-Touch_A13/board.mk looks like this: GFXINC += /home/dkibble/workspace/TouchControl/Linux-Framebuffer-Touch_A13 GFXSRC += GFXDEFS += -DGFX_USE_OS_LINUX=TRUE GFXLIBS += rt include /home/dkibble/workspace/TouchControl/Linux-Framebuffer_A13/board.mk include $(GFXLIB)/drivers/ginput/touch/Linux-Event/driver.mk and the TouchControl/Linux-Framebuffer_A13/board.mk looks like thisl GFXINC += /home/dkibble/workspace/TouchControl/Linux-Framebuffer_A13 GFXSRC += GFXDEFS += -DGFX_USE_OS_LINUX=TRUE GFXLIBS += rt include $(GFXLIB)/drivers/gdisp/framebuffer/driver.mk Alas when I execute make I just get; make -f makefile.arm clean /home/dkibble/ugfx/ugfx/gfx.mk:38: /home/dkibble/ugfx/ugfx/boards/base/Linux-Framebuffer-Touch_A13/board.mk: No such file or directory make: *** No rule to make target '/home/dkibble/ugfx/ugfx/boards/base/Linux-Framebuffer-Touch_A13/board.mk'. Stop. and that line in the gfx.mk is; # Include the boards and drivers ifneq ($(GFXBOARD),) include $(GFXLIB)/boards/base/$(GFXBOARD)/board.mk endif Which was my original starting place. Any ideas? I've copied the board.mk files from the ugfx source as that seemed logical. Is that my error? What should a custom board.mk look like? Many thanks

Is cost the main concern for you and do you have stringent real time constraints? If not - maybe look at other embedded Linux boards such as those from Olimex (a20, a13 etc). These boards offer a huge amount of processing power and memory along with good i/o and various LCD interfaces including direct RGB for a reasonable price and size. I've used the A20 and A13 along with RGB 4.3" and 5" 800x480 LCDs from China alongside uGFX. The BuyDisplays LCDs are pretty good in my experience (have used 2.8" SPI + 4.3" RGB models). Touch screens work fine with uGFX as they use the Linux touch driver included by Olimex in their Debian build. The great thing with these types of embedded Linux boards is you can easily move from testing on your Linux PC to the real hardware with good confidence things will work exactly the same. Yes there are some odd differences, but it's a much easier road in my experience compared with truly dedicated hardware. Just an idea in case you are not wedded to the STM32.

Hi Guys. Going back to the original question - did you solve the problem of the double redraw? I'm having something similar on multi-container UIs. Switching between 'screens' using the guiShowPage(...) type approach generates two redraws, the first after the gwinHide, the second after the gwinShow I think. You mention trying different GWIN_REDRAW_IMMEDIATE modes, what did you conclude? Many thanks

Hi Guys. I've got a simple problem which there must be a simple answer to, but I've not found it yet. With the 2.7 release of uGFX I took the opportunity to tidy up my projects and code so that I would not have any modified or non-uGFX files within the uGFX source tree. I have a custom board file for my production hardware which I moved to my project source tree and I use the standard Linux-SDL board for PC based testing. My problem is gfx.mk, it has the section; # Include the boards and drivers ifneq ($(GFXBOARD),) include $(GFXLIB)/boards/base/$(GFXBOARD)/board.mk endif So fairly obviously that fails to find my custom board in my source tree, but works fine when I switch to the standard "Linux-SDL" board. I can modify gfx.mk to work with both my project based board and the standard UGFX boards, but that's breaking my aspiration to not fiddle with anything in the uGFX source tree. What am I missing / not doing here? I've read the Wiki section on custom boards, but it doesn't seem to have any additional steps which I'm missing. My dev environment is Eclipse CDT running on Debian 8. Many thanks Dave

Thanks Joel. I'll certainly cut the code over to using a GTimer and post back here when it's done. Dave

Hi Joel. I could certainly move this to a GTimer but as I wasn't using that module and my hardware is pretty fast I went the dedicated thread route. I hope someone finds this helpful, even if thats just for learning uGFX basics. Dave

Hi All. Not sure if this is the right place to share code, but please find attached some simple code to create a 'spinner'. By spinner I mean a visual indicator of the system being busy or processing, much like the hour glass in old Windows or the rotating circle in Linux, Android etc. It's fairly basic but does the job for me. The code is hopefully self explanatory but just to give a quick summary. The spinner is displayed by a gfxThread which is created the first time you call showSpinner(...), that function takes two params, one is a Boolean (bool_t) which controls if the spinner is made visible or not and the second is a GHandle for the parent under which the spinner is drawn. There are functions to control, colour, size and style of the spinner. I've coded 3 styles, a spinning pie segment, a spinning arc segment and a horizontal bar "knight rider" style. If for any reason you need to stop the thread which runs the spinner just call stopSpinnerThread(), this may save resources on very low spec hardware instead of just hiding the spinner using showSpinner(FALSE,...). I've left a few printfs in there so you can see the thread startup and exit. Just take them out if you don't want them. To use the code just include "spinner.h" in your code, add the spinner.c to your source code folder, add spinner.c to your makefile and then just call showSpinner(TRUE,<parent>) from your code. You can pass NULL for <parent> in which case my code redraws the whole display, e.g. showSpinner(TRUE,NULL); The spinner will run until you call showSpinner(FALSE,<parent>). The speed of the spinner is hard coded, but you can easily change it by altering the usleep(...) in spinner.c line 149. The code has been written and tested on Linux host and targets and uses the default thread stack size with low priority. You can experiment with these values if you need to. You'll need to enable a few things in your gfxconf.h #define GDISP_NEED_CIRCLE TRUE #define GDISP_NEED_ARC TRUE #define GDISP_NEED_MULTITHREAD TRUE Good luck. Dave spinner.c spinner.h

Hi Joel. Many thanks for the reply. Its an ARM Cortex A8 driving a 480x272 RGB mode TFT. The SDL emulator is about 250us. Not tried anything else yet. I've got a BBB knocking around, might benchmark that for fun. Dave

Hi. OK - that is a good call. I'd missed the non-filled gdispGDrawStringBox(...) function. Using that makes the code a lot simpler as now I don't need all the lower level supporting gdisp code for my custom gdispGFillStringBox(...), also thanks for the design guidance re "no gwin calls from gdisp". I'm going to have a look at the streaming API when I get a chance, but the rendering is only taking around 400us max for a whole screen and about 80us for an individual label so it's not a pressing performance issue. Many thanks Dave