I choosed to use the gui_ prefix for each purely high-level display
code (code that is build over the display API).
I think it's a good thing because it makes this category of functions
more easy to recognise when you read the code. Actually I try to
separate the gui processing from the data processing in the
application code, when you read a gui_ call you directly know it's
tightly related to the display and nothing else
In fact, the gui code can be used in a lot of places, this way the
final binary size decreases and the code becomes easier to read since
the app doesn't have to do all the drawings itself.
For example if you had to choose between those two functions names
gui_list_init and list_init, for a function that initializes a
graphical list component, which seems to you the less confusing ?

That was for the gui_

Now about the _sync
the gui code is organized that way :
- a display independant access layer (implemented with a struct
containing function pointers to display functions and data describing
some screen's states and characteristics)
- the drawing code (for example for splash, it's gui_splash) that
displays the component on a given screen (for gui_splash, it receives
the wanted display in parameter)
- a gui_sync layer that handles the component for all connected
screens (some kind of cloning). For example on iRiver, the
gui_syncsplash displays a gui_splash on each screen,
If an application just wants to handle one screen, and do other things
on the other screen, it would call gui_splash and gui_syncsplash
otherwise

The splash call is neither a gui_splash because it can't be displayed
on the screen you want, nor a gui_syncsplash since this one is
displayed on n screens

You could compare splash to gui_syncsplash, but in my opinion, it's
less confusing for the programmer to let him know that he is dealing
with a splash that will be displayed on all screens, and that just by
reading the function's name.

I hope this answered your questions.
You can also read the doc I wrote for this API, it's in the .h of each
file in the gui/ directory. If this one isn't clear, please let me
know !
Received on Thu Nov 17 02:26:03 2005