GUI abstraction

[Tectu]

The TOUCHPAD_USE_CONTROLLER macro is just to specifiy the matching driver. The touchpad.c file does use the TP_ macros itself (for CS line and IRQ).

We would need a generic USE_TOUCHPAD here. This would be easy to implement.


~ Tectu

[Tectu]

Okay guys, as more as I think about it, I see more and more that I don't know where to start, implementing the new GUI abstraction layer. I am pretty sure that you guys have a few good ideas.

After restructorizing the current lowlevel drawing functions like lines, circles and strings, which do have now a worker thread, it would be nice when we would have a cool and fancy GUI abstraction layer.
My main problem is that, I don't have any experience wich such a thing and I am not sure which is the best design and where to start, implementing this design.
I guess it would be nice, if we have something more object oriented, like other big libraries like gtk and qt use it. Something like:

Code: Select all

struct button_t *b = malloc(sizeof(struct button_t));

guiAssignEvent(b, clicked, ptr_to_function);


I am not sure, if this could make a few problems because we are on an RTOS, regarding atomic reads of the values etc., maybe it would be more useful using the event stuff of ChibiOS? I am sure Giovanni can help here.

What do you think? What's your suggestion, should we have a struct per GUI element, or some general thing?


~ Tectu

[Badger]

We should probably stick to statically allocated objects. I don't think we'd gain much by allocating them dynamically?

I suppose at a basic level we have the controls that make up the user interface: buttons, sliders, windows, text input (? would require an onscreen keyboard).

Each of these elements should have some sort of event driven interface. So for a button there would be a 'button pressed' and maybe 'button released' action. Slider might have 'value changed' and 'value set' (so the application could respond to the slider as it moved, or just when it was released).

a window could be some sort of hierarchy, maybe better to name it frame. A frame would contain buttons, graphs etc.

probably a difficult part of the implementation will be deciding on what data structures we use to represent all of this. Here is where research of other GUI libraries comes in handy! I plan to review some this weekend.

[Abhishek]

I don't know, but I think it shouldn't be a big trouble implementing a dynamic approach to GUI as we have in the interim implementation, the overhead shouldn't be too large. It'a more of a developer's choice and a question of convenience.

I'd reserve virtual keyboards for later revisions of the lib. But I'd like to add a list control and implement a fully-functional file browser in the current lib. This is where the dynamic implementation would come handy. Although I don't know when I'll be able to put that in code.

Would it be worth it for the graphics lib would be to enable it to use external SPI flash to store fonts and images that could be loaded with an external bootloader, reducing wear stress on the internal flash memory? Of course we could use SD cards and FatFS straightaway but I feel it puts a lot of overhead. Alternatively some linker magic to ensure that font and pictures go into the bottom of the flash and fill it bottom up? And then add pointers to it in the programs, reducing programming time by 8K bytes or more.

I once stumbled across a link with an impressive C++ Graphics lib implementation for Arduino platform. Maybe we could learn a few points from here: http://andybrown.me.uk/wk/2012/06/04/no ... rt-2-of-2/ , especially picture rendering (it uses a compression algorithm for storing images.

Making another post for a GUI impl idea.

Abhishek.

[Abhishek]

We'd divide the attributes of the control into two parts: one common to all control like bounds, a pointer to text, a state variable, a pointer to image, ... And the next section to properties exclusive to that control. Similar to the way a SerialDriver inherits from BaseSequentialStream, we could implement it in structures.

For events I guess we could add a EventSource for each event like Clicked, Hold, Slide.. The thread that created the control would register for the events using chEventxxx API. Events can then be handled as usual.

What do you think? (@Badger and Tectu)

Giovanni Sir, can I also ask you for your comments on this approach (for event handling)?

Abhishek

[Badger]

Abhishek, those are some nice ideas but I think a lot of them are not aspects of the GUI, but rather the system built on top of the GUI. For example a file browser shouldn't be considered part of the GUI layer, but rather the system built on top of it to provide 'nice' features to the developer (the virtual keyboard would also fall under this). If we design the GUI layer right then it should be easy to implement stuff like file browsers.

Of course I think the project should have these features, but they should be discussed as a separate component.

As for dynamic vs static, I can't see where a dynamic interface would have any advantage; surely the interface will be completely defined at compile time? the only advantage I can see to dynamic is that you could dynamically add new buttons / windows etc, but I'm not sure why you'd want to do that anyway, this isn't really an issue as the dynamic allocation would occur in the user's application, not the library, so it is up to the user as to how memory is allocated. For a file browser yes you might want some dynamically allocated memory to store the file list, if it is going to be scrolled off the screen. Even then it might prove easier to just re-read the file system data than store it in memory.

So I propose we split the discussion into two; the actual GUI aspect, and the cool interface stuff that is built on top of it.

[Giovanni]

An old idea of mine is some kind of format of "graphic resource" as a const data structure.

The draw subsystem would have a single API, gfxAddCompositeResource(&parent, &resource, p1, p2, p3, ..., pn), the variant parameters would be resource-specific attributes.
Imagine a resource as an array of encoded drawing primitives (lines, boxes, text) and interaction primitives (callbacks, events, messages...) with some fixed parameters and some indirect parameters that are the function Pn.

The a library of standard resources would be created, for example a resource "button" would be a rounded box, some lines, a text and a callback, it parameters would be rx, ry, width, size, text, callback pointer.

Initially resources would be hand coded but it would be possible to create a visual tool for forms design like VB or Delphi.

Structures could be combined, their coordinates are always relative to a "parent" resource, for example a window resource would have the screen as parent and could contain buttons, text fields and other widgets.

The trick would be in defining this compact resources format and the engine behind it, I call it engine because it would handle a "live" scene containing various resources that could be added and removed at any time, this "engine" would reside in the server thread and interact with the application using messages and/or callbacks.

Giovanni