|
Rockbox mail archiveSubject: Re: kevin: apps alarm_menu.cRe: kevin: apps alarm_menu.c
From: Kévin FERRARE <kevin.ferrare.ml_at_gmail.com>
Date: Thu, 17 Nov 2005 02:24:10 +0100 On 11/16/05, Daniel Stenberg <daniel_at_rockbox.org> wrote: > On Wed, 16 Nov 2005, cvs_at_labb.contactor.se wrote: > > > replaced all the splash calls by gui_sync_splash, added some missing > remote > > key in the playlist viewer > > > - splash(HZ,true,"Not a rockbox ID3 database!"); > > + gui_syncsplash(HZ,true,"Not a rockbox ID3 database!"); > > (The commit message obviously was not correct.) > > What exacly makes this function called "sync"? > > Also, why oh why didn't you just make your new function use the same name? I > > really don't like seeing every function we have get a gui_ prefix for no > useful purpose. > > -- > Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/ > OK let me explain it 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 2005-11-17 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |