[interfacekit] Re: Course of action for BScrollBar implementation

> I'm writing at the moment a client side BScrollBar (and I'm writing
> BScrollView too ^_^), but I really would like to replace it with a 
> server
> side one when the app_server is ready for it. There are many 
> applications
> that benefit from it (listview with lots of items,

I can't see, why the number of item in the list view should affect the 
scrolling behavior. Obviously a sane list view implementation should 
only draw the visible items. And even, if you have a large screen and 
see some hundred items, I can't believe, that it would make the 
scrolling sluggish. Unless you are doing something nasty.

> spreadsheet views,

Same here.

> database views,

If the database is not in memory -- what DBs usually aren't -- then one 
would to run a separate querying thread anyway.

> render views(fractals/raytracing),

A perfect example for a separate thread.

> views with tile
> caches(photoshop/gimp),

A loader thread.

> etc.

The latter examples all have in common, that in worst case preparing 
the data may take a really long time (in real time terms). If you 
prepare the data for drawing in Draw() in these cases, then your GUI 
will be sluggish, or, even worse, unresponsive. Such annoying effects 
like that you can't operate (e.g. close) the window for several seconds 
after scrolling can occur, because the window thread is busy with 
processing data.

> I think if it wouldn't be needed, they would
> have changed it after 5 releases,

According to a rule of thumb, programmers are lazy bastards. If a 
solution is implemented and works, then why change it? I believe, that 
app server side scrollbars made sense, when they implemented it, but at 
that time the number before the MHz had only two not four digits (not 
mentioning the Gfx specs). Today it's simply unnecessary to implement a 
special handling for scrollbars -- processors and graphics cards can 
easily draw the whole screen 20 times or more a second (unless you set 
the pixels individually maybe), and thus the scrolled contents should 
be rendered fast enough to let the scrollbar look perfectly fine. The 
same reason for which you want to have the scrollbar drawn app server 
side can be applied to a slider, e.g. if that slider controls a 
parameter of your favorite raytracer view.

> but anyway we'll be able to test it.

Yep, test it.

> We can always ship the client side one for customization.

Actually I've really not much interest in customization. My point is, 
that you would implement a special handling -- that makes the code more 
complex -- to unnecessarily over-optimize an aspect.

> As for customization and overriding Draw() of BScrollBar. I don't 
> think
> developers should change the look of controls (and not only because I 
> spent
> hours to get the drawing code good ^_^). People should stick with the
> default look, not try to brand their application by making it look
> completely out of place. I think the direction Apple took for the 
> MacOSX gui
> is perfect, for users and developers. They have clear guidelines so 
> that
> apps look consistent, and once you can use one, you can use them all, 
> and
> they all fit nicely together. They don't let users change colors or 
> fonts,
> which makes it much easier for developers. I know theming is popular, 
> but I
> don't think it's something that is necesary/usefull, it doesn't make 
> users
> work faster (especially not if you they tweaking everything the whole 
> time
> or browsing for themes), and developer resources are much better 
> spend
> elsewhere.

I totally agree.

CU, Ingo

Other related posts: