[interfacekit] Re: Course of action for BScrollBar implementation

>The problem of not having server-side scrolling also becomes an issue when
>we want to transmit GUIs across networks.  It is far better to have a
>protocol for server-side drawing of everything.
>
>The application, which is running on a remote system, would say "draw a
>scroll bar", and the local app_server would draw the scroll bar and
>transmit messages according to user interface.  If it were not server-side
>scrolling, then the drawing instructions would have to travel the network
>as well.  This goes for buttons and other GUI components as well.
>
>Having all UI elements being done on the server-side means that
>applications run over networks will be consistent on a particular system
>(as opposed to potentially having different widgets depending on where
>you're running it from), and if you have an API which allows for
>modifications (to UI elements on a case-by-case in a particular
>application), which are transmitted back to the app_server, then it would
>also decrease the necessary bandwith and data throughput, because you
>could transmit the necssary data at one shot, on loadup.
>
>Isaac
Definitely an R2 thing with potential.  However, it doesn't really argue for 
the case of server-side drawing. Because what you have suggested is most 
definitely something for R2, it is irrelevant at this point. I'm *very* glad 
you mentioned it because it might prove to be a solution to those who *really
* like and want skinning for their GUI - having a widget library for the 
app_server which handles drawing standard controls with an option for 
applications to customize the look.

--DW

Other related posts: