[interfacekit] Re: Course of action for BScrollBar implementation

The "not being able to change fonts and colors" applied to the MacOSX
example I gave, not to our controls, sorry if there was confusion. My point
was that Draw() should be used to extend functionality (BPictureButton,
BBitmapButton), not just change the look of your app and break consistency.

Rest assured that all the controls I wrote until now take into account the
system colors and fonts. But having tested it, I found that there will be
problems in quite some applications. Not all applications use ui_color(),
but instead hardcode the values, (216,216,216) being the most popular one.
This means that you get a mix of gray and colored controls. Another issue is
the fonts. Developers often hardcode the sizes and positions of controls,
which means that text doesn't fit if the font is bigger.

As an example of this behavior I built StyledEdit with the OpenBeOs
interface kit. I fixed the find dialog, but not the replace dialog. Notice
that the colors don't match, and that the text is cut in different places.

http://alpha.luc.ac.be/~ef00/screen8.png

I took StyledEdit because it's easy to illustrate, I don't mean to say
anything bad about the developers, who did a great job ^_^. The same will
happen in most applications.

Marc Flerackers (mflerackers@xxxxxxxxxx)
Software Engineer
ANDROME NV

> I agree with Ingo. I have quite a number of reasons why I think
> we should at
> least hold off on the server-side scrollbar. A special case adds time. I
> don't want to sound indignant or anything (please don't take it
> as such), but
> right now, Gabe and I have more than enough to do on the server without
> adding to its complexity in another way. BScrollbar is also the
> only class
> AFAIK which is handled by the server in any way except for displaying and
> allocation.
>
> Processor power is also quite cheap right now. While I do want the
> possibility of running OBOS on an old166, I doubt that it will be
> the norm
> with the way that Micro$oft's bloatware is forcing higher hardware
> requirements. I doubt that the additional messaging overhead will be
> significant, but if it is, it will likely be easier to go from client to
> server than the other way around.
>
> Minor customization is acceptable provided that it does not prove a
> hinderance to the user. Alan made a good point in saying that the
> user should
> not be restricted to a particular font, font size, or set of
> colors. One of
> Microsoft's good ideas (there are so few!) was high contrast
> color schemes
> for those who have visual disabilities of some sort. Localization support
> will require different fonts, such as for Hebrew and other Middle East
> languages or for C/J/K. As long as we are conservative about it, there
> shouldn't be many problems.
>
> --DW
>
>


Other related posts: