[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, spreadsheet views,
database views, render views(fractals/raytracing), views with tile
caches(photoshop/gimp), etc. I think if it wouldn't be needed, they would
have changed it after 5 releases, but anyway we'll be able to test it. We
can always ship the client side one for customization.

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.

Marc Flerackers (mflerackers@xxxxxxxxxx)
Software Engineer
ANDROME NV

Other related posts: