Items list on top of other graph objects

[naftilos76]

Hi,

I noticed that while setting visibility of an items list to "on" on top (overlapping) of a GGraphObject window area, where a waveform is being drawn, the waveform draws on top of the items list instead of staying in the background. So my question is whether an items list can exist unharmed (not affected) on top of other windows or graph objects (within a window) while drawing operations take place on them.

Regards

naftilos76

[inmarket]

GWIN comes with a VERY basic window manager. Whilst it handles visibility etc, it currently does not support overlapping windows. Drawing is only clipped to the window boundary not to the windows expose area. If fact, with the current window manager, an expose area for each window is not even kept. This restriction is fine for most small embedded systems as it is simple and requires minimal RAM and speed overheads to manage.

This principal of keeping things tiny and simple even extends to some of the window types. Whilst all widgets can redraw themselves if requested (eg if they are revealed by the removal of another window), other window types like graph and console cannot. To enable them to do so would require that they "save state" in RAM and this would make them very expensive for small CPU's (and possibly impossible due to insufficient RAM).

As the window manager is now a "plug-in" interface it should be possible to write your own more complex window manager and use it by calling gwinSetWindowManager(). See src/gwin/gwm.c for the implementation of the current basic window manager.

I suspect that extra support will be required in the basic GWIN code to help support this, simply because GDISP currently only supports simple box type clipping area's. This is not insurmountable however if you implement a box region cache within the window manager. When the first window manager gets written that supports overlapping windows we can adjust what is necessary in the basic GWIN code.

This is not simple stuff to get right and so for now it has been on the back-burner as we implement higher priority items.

We would love it if someone (perhaps you) took on the challenge of writing a window manager capable of handling overlapping windows and then contributed it back to the project.

[naftilos76]

Thank you sir for your time to clarify on my issue.

My thought is that any window drawn over another could impose a clipping area that would prohibite the window on the back to draw there. After setting visibility of the foreground window to false then the window on the back could be redrawn / refreshed etc. However i have not studied the background code of they window manager inside uGfx and therefore i may just being silly!

Anyway, i got my answer and will probably will find an indirect way to do things like i am now. That is, i stop all activity on the background window when i trigger a menu items list to appear on it an re-start it when the list goes invisible through the use of semaphores as i am using a few threads.

Thanks again.

Regards

naftilos76

[inmarket]

Currently the GDISP clipping area is an inclusive clipping box i.e. the area INSIDE the box gets drawn, anything outside does not.

I can see that for menu's and other "pop-up" or on top items an exclusive clipping area would be useful (only things OUTSIDE the box get drawn). If I get time I might add support for an exclusion area to the new GDISP code I am currently working on. This would certainly be useful for single window overlaps like menu's. It would have to be called manually when displaying your pop-up until GWIN supports maintaining an expose list.

[Joel Bodenmann]

My thought is that any window drawn over another could impose a clipping area that would prohibite the window on the back to draw there. After setting visibility of the foreground window to false then the window on the back could be redrawn / refreshed etc.

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