Sting

I copied the List Widget to get a head start on the table widget and the list widget redraws the background and then redraws the text for each row. If there is a large amount of data the redraw shows every line being redrawn.

Easy question: I have the table mostly working but have a question. The standard seems to be to not draw horizontal lines for the rows of the List object. Does this mean it is best to not draw the vertical lines for the columns? If no lines then it seems reasonable to implement gwinTableSetOddBackground(...); and gwinTableSetEvenBackground(...); I have already implemented gwinTableItemSetBackground(=...); This allows for changing the background of the rows to make it easier to follow what is happening and doesn't incur the cost of more drawing, since the row has to be drawn anyway. Also, the entire list is redrawn when a new row is selected, is there a reason I shouldn't optimize this, so only the two rows that changed need to be refreshed? Or doesn't this make a performance difference?

Here is the first pass header for the Table widget. There could be some comments not changed. I used an @warning at the top of functions I had questions about. gwin_table.h

I actually had the idea this morning to build two version: gwinTable: a row oriented widget that uses less resources, basically each element of the single queue is a row element and contains everything for a complete row. In this widget cells are not selectable. In this widget each row can have an image but not each cell. gwinGrid: a cell oriented widget that uses a queue for each column and allows cell wise operations, each cell can have an image. row selection is not an option. If there is no objection, this is what I will plan. I can have the header files done by the end of the day.

Do you mean a queue for each column and add items have to be for a complete row?

Only the number of columns are known for the current implementation. For my project I also know the number of rows, because they are database rows from a select. If that restriction can be lifted I could use an array.

I have a roughed out gwinTable interface definition. I basically took the gwinList and copied it to gwinTable, left in all of the copyrights, and changed the names. I changed how the list_head was allocated to use an array of pointers to gfxQueueASync structures. This will design make it easier to support table cell selection. I thought of leaving it as a single gfxQueueASync structure and have each element represent a complete row. This design will make row selection more convenient. The api is not totally flushed out yet, I figured I would get some feedback before I went too far. Anyway, I want to build this for more then just me, is there a design review process for widgets? If the api is not correct, others won't use it and I will have wasted lots of time.

I think maybe I didn't give enough information What I need is a board that I can connect to a device like a Zynq board where the zynq does all of the processing and then the graphics is output to some controller. One way to use this board is for the STM32 be a uGFX server and the main processor sends uGFX requests across a connection and all of the uGFX is done by the server leaving the main processor to do what it does best. Is this what you had in mind? Or how you use this board currently?

Is there a place where users can post widgets that they make? I either need to find or make a table widget. I have looked into making it and will start coding this weekend if it isn't available. Basically I need a multi-column list with column headers for each row. The number of columns is know when the table is created.

Sorry, this isn't a stong area for me, I am just trying to sort it out to make better choices. Are you saying if I buy the STM32F746G-Discovery card, after I get tired of the small area of the 4.3" display I can replace it with a larger one?

I want to build a project to get an idea of how the uGFX library performs on a larger display board. By larger I mean something around 7". I am building an embedded electronic brewery, but I want to use a board that I might want to use in a production environment. Since I am starting from scratch I can consider anything. Is there a way to understand the boards supported by the uGFX system and the performance constraints?

I was just going to reply, it wasn't so fast. I tried a demo that uses fonts and had a bit of an issue. Because fonts use fancy macro manipulation the font's didn't work immediately. I had to disable the font directory from compiling as a directory because all of the fonts get built but none of them get added to the list. Currently I have to stop automatic makefile generation to get the fonts to work. If I am the only one who cares about this, I will move the macro stuff to each file, the ones I want to use at least.

I forgot another change I had to make and that is I had to not use the following files in GFXLIB directory: mf_bwfont.h, mf_rlefont.h, and mf_scaledfont.h as they prohibited the header files by the same name from being used. I might be able to ssolve this easily by changing the include directory order.

I got a version to work, but I don't think it is the best way and I am not sure it will work in all cases. 1) I started with the demos/modules/gdisp/basics, I copied the main.c and the gfxconf.h files to the project. 2) The project uses the Linux-FrameBuffer board and the X driver so I added links to those directories to my project. I also added a link to the src directory to my project. When I tried to build I would always get duplicate for every function so I created a define #define GFX_USE_ECLIPSE TRUE and surrounded the file gfx_mk.c with the following #include "gfxconf.h" // this will get the GFX_USE_ECLIPSE flag #ifndef GFX_USE_ECLIPSE Original source goes here #endif So the file will be compiled when not using eclipse and will not be compiled when using eclipse. I added the X and pthread libraries cross compiled for the beaglebone and ran it and I got exactly what I would expect. I don't have to muck with any makefiles

I built a new project and put the main.c and the gfxConf.h file from the demos/modules/basic directory. I added all of the include directories so all that remained was the linker finding the object files that were not compiled yet. I then added the lines you suggested to the makefile and changed them to be for my system and to use the Linux_FrameBuffer driver. I was warned that i was modifying an autogenerated file. When I did the next make, the lines I added were removed. I then disabled the autogenerated makefile and added the lines to see if this would be suffucient. The only file that gets compiled is main.c. The only way to get the version of eclipse I am using to compile any file other then main.c is to add the directory to the project via a link. The version of eclipse I am using is: Mars.2 Release (4.5.2)

I hope what I write here does not insult anyone, it is not my intent. I have total respect for the piece of work and all of those who built it. I think this is an awesome piece of software and am working very hard to figure out a way to make it work in the environment that I need. It will be in my favor to figure out how to make it work. My environment forces me to use eclipse. I am working on a project that uses the Xylinx Zynq processor on a board and the SDK for this board is a modified version of eclipse. I also cannot make my own makefile as the zynq sdk builds a makefile based on how I define the hardware for the application I am writing. The Zynq is a dual core arm processor with fpga fabric to allow me to build whatever piece of hardware I need. Add to this requirement the need for a real time os, the application will be an embedded application running the rtos as opposed to a linux kernel. It will be virtually impossible for me to keep all of the makefile differences between these three components in line and will be chasing makefile bugs as well as software bugs trying to integrate these environments with the added complexity of my application. I understand the ugfx is more then a collection of sources, it supports many different pieces of hardware so inherently exhibits a high level of complexity. I am not sure if I can sort it all out, but I hope to as I think this technology will enhance my product. To get to where I can use this in my production environment I am trying to build a prototype without all of the other complexity to find a pattern that I can make work without forcing me to manually pick the files I need to build my system. To build a successful system the application picks a board and a set of drivers for each of the subsystems they want to use. Is this assumption correct? If this assumption is correct then once the application has picked the hardware attributes of the system they intend to build then that set of choices would be implemented with the building of the src directory given hardware choices. This is defined by a set of defines and anything in the src tree that won't be able to work on that set of choices should not get compiled. This will eliminate the makefile chain and be much easier for eclipse to work. I have seen systems that support many different physical environments use a technique like this. In the application config file the use defines all of the switches to define the system they want and the defines prevent the system from attempting to build stuff that is not needed. Ugfx already has the defines like GFX_USE_GDRIVER and instead of using these switches to build a makefile they were used in the source to decide how it is built eclipse would work. Is there a know reason this will not work? I understand this is not a simple job, without some method like this my product will not be able to use this technology.

do you mean that i build my own makefile and not have eclipse do it based on the source files in the project?

Did you have to write your own makefile or is it generated automatically by eclipse?

I have tried to build only adding in the parts of the project that I need and it seems like not the right way to go so I went to including the entire project. I'm not sure which way to proceed.

I started a new project from scratch. I copied the main.c and the gfxConf.h file from the demo directory that I wanted to build. I added the following in the include path ugfx_2.5 ${workspace_loc:/${ProjName}} ugfx_2.5/drivers/gdisp/framebuffer ugfx_2.5/boards/base/Linux-Framebuffer ugfx_2.5/src/gdisp/mcufont Everything compiled with this set of settings I then added the ugfx_2.5 folder to the project as a link and built the project. I got the following errors Building file: /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c Invoking: Cross GCC Compiler arm-linux-gnueabihf-gcc -I/usr/local/arm/ugfx_2.5 -I"/home/ray/Eclipse/brewery/TwoUgfx" -I/usr/local/arm/ugfx_2.5/drivers/gdisp/framebuffer -I/usr/local/arm/ugfx_2.5/boards/base/Linux-Framebuffer -I/usr/local/arm/ugfx_2.5/src/gdisp/mcufont -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.d" -MT"ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.o" -o "ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.o" "/usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c" /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c:85:3: error: #error "GDISP: uGFXnet - The driver pixel format must match the protocol" #error "GDISP: uGFXnet - The driver pixel format must match the protocol" ^ /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c: In function ‘NetThread’: /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c:398:6: warning: implicit declaration of function ‘close’ [-Wimplicit-function-declaration] closesocket(clientfd); ^ It gets a lare way through building, it seems to be building stuff for drivers I don't use, which is where the error is.

I am getting a little further, I can compile it all now but have trouble in the linker because I have probably included things too many times. I will go through it all again but some experience would be good to know what is included more then once I have many statements just like this. ./gDisp/gdisp_mk.o: In function `gdispGFillArea': /usr/local/arm/ugfx_2.5/src/gdisp/gdisp.c:1085: multiple definition of `gdispGFillArea' I also have undefined references ./gDisp/gdisp.o: In function `drawpixel': gdisp.c:(.text+0xa): undefined reference to `gdisp_lld_draw_pixel' ./gDisp/gdisp.o: In function `fillarea': gdisp.c:(.text+0xc6): undefined reference to `gdisp_lld_draw_pixel' ./gDisp/gdisp.o: In function `hline_clip': gdisp.c:(.text+0x1ee): undefined reference to `gdisp_lld_draw_pixel' ./gDisp/gdisp.o: In function `vline_clip': gdisp.c:(.text+0x2e6): undefined reference to `gdisp_lld_draw_pixel Any advise would be good, thanks

Victor: I have made some progress on this if you read my parallel post. To get it to work you need to add directory links to your project and when you do this the autogenerated makefile gets all of the .mk files from all of the directories. Hope this helps. I have a few more problems to hash out and will let you know when I get it. Or, if you come up with something different I would be interested.

I made it to the next step, at least it is one step better: I added link directories as Base => /usr/local/arm/ugfx_2.5 gDisp => /usr/local/arm/ugfx_2.5/srs/gdisp Demo => /usr/local/arm/ugfx_2.5/demos/modules/gdisp/basics And it seems at this point all of the mk files are included into the Makefile and I don't have to turn off automatically generate makefile. I am down to two error: /usr/local/arm/ugfx_2.5/src/gdisp/fonts/DejaVuSans10.c:11:2: error: #error The font file is not compatible with this version of mcufont. and /usr/local/arm/ugfx_2.5/src/gdisp/fonts/DejaVuSans10.c:14:14: error: unknown type name ‘uint8_t’

To set GFXLIB I set environment variables in the properties of the project. So far I have built a normal project that generates it's own makefile. I add all of the includes that I think I need and then change the project to not automatically generate the makefile. A makefile is built and then when I change this switch a new makefile is not generated each time I run make. Then I edit the make file and add the two lines -include gfx.mk -include demo.mk I copied these files into the Debug directory of the project. I will have to change this procedure, I am just trying to figure out what it takes to build a simple project. I build the project and I think the build goes well except I have to find a way to include the ugfx source into the project. I think I need to create a virtual link to the source subdirectory and will try this next. If someone knows a better way, I would appreciate pointers.