>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.
What about 3rd party controls? Are we just supposed to let any yahoo
load his control directly into the app_server where it can
indiscriminately wreak havoc? What if the user doesn't have a control
which the remote app uses? How will it get drawn -- especially if the
drawing code branches depending on the state of the control? Take
BButton as a simple "for instance": it's drawn differently depending on
whether it's the default button or not. For these reasons (and, I'm
sure, others that haven't yet occured to me), controls will continue to
do live outside the app_server.
I'm conflicted about the scrollbar issue. One the one hand, being able
to customize the scrollbar drawing would be nice. On the other, when
that poorly written app becomes unresponsive and scrolling can't happen,
I think people are much more likely to blame the system than the app
(because users are, by and large, totally clueless about such things).
It also occurs to me that allowing something as basic as the scrollbar
to be modified from one app to the next could contribute to an
inconsistent UI.
I have an idea that would let the app_server manage the scrollbar as it
currently does now, while allowing for client customization. I want to
flesh it out a bit more; I'll post it in a bit.
e
>
>> I vote for `drop the server-side scrolling'.
>
>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
>
Necessity is the plea for every infringement of human freedom. It is the
argument of tyrants; it is the creed of slaves.
-William Pitt, British prime-minister (1759-1806)