Re: [Dynapi-Dev] Here it is.. the first DynAPI 3x widget port: scrollbar_light

[Doug M. <do...@cr...>]

See comments inline:

----- Original Message -----=20
From: Benoit Marchant=20
To: Doug Melvin=20
Cc: dyn...@li...=20
Sent: Tuesday, March 25, 2003 10:15 AM
Subject: Re: [Dynapi-Dev] Here it is.. the first DynAPI 3x widget port: =
scrollbar_light


>Just tested it. Very nice !
2 missing things I believe. First, when you keep mouse down on the =
scrollers buttons, you would expect the scroller to keep=20
>scrolling until you release the mouse button or the scroller is at his =
maximum.
>And the same is true if you click in the scroller outside of the knob. =
The scroller should scroll until it reach your mouse=20
>down/reach an end.
=20
That would be nice.. I can implement it, but as desocvered before, it =
can be unreliable.=20
I.E. if you happen to move away from the button before letting the mouse =
button up, there will be no mouseup
=20
=20
>I looked at the code, and there's a few things that should to be =
defined on their own. I guess the buttons width will=20
>always be equal to the scroller width, but the buttons aren't always =
square, and the height might be different. Even more=20
>complicated is the emulation of the aqua scrollers. The buttons have to =
contains the rounded edges, so they aren't squares.=20
>But their size for the calculations is different, it goes from the =
external side to the tangent of the rounded part. And=20
>the knob will go overlapping the button layers. So in order to =
implement that, I would need the scroller to be able to deal=20
>with these differences.
>To make things a little more interesting, the scroller buttons can be =
on the same side :-) and in that configuration, the 2=20
>buttons don't have the same height !!

This is a light-weight scrollbar. it is simple in it very nature.. Why =
complicate things?
In fact, when you start moving the buttons around, it's no longer even a =
scroll bar.

On of the things that is most important witht he DynAPI is ensuring that =
new user can _USE_ it.
If every single widget is super complex with 53 different arguments then =
you start to loose some of your audience.
Leave the light scrollbar as a light scrollbar please.
If you want an advanced scrollbar then code one. :-)

>So I think a good and simple way to implement this is to define the =
scrolling course on the button as a sub rectangle. Then=20
>you get to tell it's y/height for vertical and it's x/width for =
horizontal. And by doing that, it removes the relation=20
>between the actual size/location of the buttons, and the scrolling =
logic.
>Still, by default that rectangle should be calculated the way your =
example is if that's the most usefull configuration for=20
>most people, and then you can override that ractangle if necessary, but =
it should be used internally for the calculations.

What?

>For skinning the knob button, I'll need to be able to use 3 images: the =
rounded edges and a repeating >background.
>The skinning, on top of the images/size of the buttons should also =
contains their location.
>As you can see, in the case where the buttons are together, there's =
still an image on the top ....
>I previously used skins as dictionary, defining a bunch of defined =
properties.