[interfacekit] Re: implementation

>> 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 
>
>By "indiscriminately wreak havoc", so long as the protocol only 
involves
>drawing or splicing in bitmaps, I don't see what the problem is.  the 
API
>already allows for this -- the BPicture class.  I'm not talking about
>compiled code (as in a plug-in) here.  If you load up a skin (which
>would be a plug-in) then, I say you run whatever risk you want to
>take.  But since BeOS (unlike windows) doesn't easily allow for 
messaging
>to do crazy stuff like "execute code at this memory slot", I think
>security-wise, the app-server should be safe.

What you're talking about is really not that much different than what 
already exists: controls "draw" themselves by calling the various 
client-side APIs -- which then send messages to the app_server, which 
does the actual drawing.  If I'm understanding you correctly, you simply 
want to send these commands *once* to the app_server where they would be 
cached and used as necessary.  What about state changes, when the 
control wants to be drawn differently?  I suppose it could send a new 
set of drawing commands, which app_server would replace the original set 
with.  While I'm a little intrigued by the idea -- caching the commands 
would remove the latency of app_server->client view->app_server 
communication -- I'm worried that the cache management would negate the 
benefits.  And it would either change how drawing is done for clients 
(they'd have to know when to send a command set, rather than just 
"drawing" when told to) or require some major voodoo on app_server's 
part.  Actually, I don't think app_server could do what would be 
required here; the change would have to be on the client side.  And 
app_server would still probably need to ping the control before drawing 
to make sure the current command set it still valid.

Well, it's a big enough change that it would get bumped to R2, and it's 
an optimization that I don't think is going to be worth the trouble for 
the most likely scenario -- regular desktop usage.  Being as premature 
optimization is the root of all evil, I think it would be wise to wait 
until we're actually capable of rendering over the network and seeing it 
this is really necessary.  You are, of course, welcome to code up the 
prototype and change my mind. =)

>> 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, 
>
>Well, I think it should be (and is) *hard* to deviate from normal
>behavior, as it is now (do many people really take the time to overload
>BButton?) but if it calls for it (like how GoBe does cool things with
>menus, etc) then the effort is worth it, and the developer would be
>inclined to do a good, clean job with it.

AFAIK, every control *but* BScrollBar allows the developer to usefully 
overload Draw() to customize how the control looks.

>Anyway, if someone wants a customizable scrollbar, then shouldn't they
>just make a BSlider?  I guess you're screwed, though, if you wanted to
>make a vertically customizable scrollbar, but that would involve 
changing
>BSlider (or adding BVSlider, or something).

I would refer you to the documentation for BSlider::Orientation() and 
BSlider::SetOrientation(). =)

e

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)

Other related posts: