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

[Benoit M. <mar...@ma...>]

On Tuesday, March 25, 2003, at 05:27  PM, Doug Melvin wrote:

> See comments inline:
> =A0
> ----- Original Message -----
> From: Benoit Marchant
> To: Doug Melvin
> Cc: dyn...@li...
> Sent: Tuesday, March 25, 2003 10:15 AM
> Subject: Re: [Dynapi-Dev] Here it is.. the first DynAPI 3x widget=20
> port: scrollbar_light
> =A0
>
> >Just tested it. Very nice !
> 2 missing things I believe. First, when you keep mouse down on the=20
> scrollers buttons, you would expect the scroller to keep
> >scrolling until you release the mouse button or the scroller is at=20
> his maximum.
> >And the same is true if you click in the scroller outside of the=20
> knob. The scroller should scroll until it reach your mouse
> >down/reach an end.
> =A0
> That would be nice.. I can implement it, but as desocvered before, it=20=

> can be unreliable.
> I.E. if you happen to move away from the button before letting the=20
> mouse button up, there will be no mouseup
But you get a mouseout, and when you get one, it needs to stop. If you=20=

get mouseover and still no mouseup, than start again.

> =A0
> =A0
> >I looked at the code, and there's a few things that should to be=20
> defined on their own. I guess the buttons width will
> >always be equal to the scroller width, but the buttons aren't always=20=

> square, and the height might be different. Even more
> >complicated is the emulation of the aqua scrollers. The buttons have=20=

> to contains the rounded edges, so they aren't squares.
> >But their size for the calculations is different, it goes from the=20
> external side to the tangent of the rounded part. And
> >the knob will go overlapping the button layers. So in order to=20
> implement that, I would need the scroller to be able to deal
> >with these differences.
> >To make things a little more interesting, the scroller buttons can be=20=

> on the same side :-) and in that configuration, the 2
> >buttons don't have the same height !!
> =A0
> This is a light-weight scrollbar. it is simple in it very nature.. Why=20=

> complicate things?
> In fact, when you start moving the buttons around, it's no longer even=20=

> a scroll bar.
Sure, that could lead to absurd positioning ... but that's not how I=20
meant to use it :-)
> =A0
> On of the things that is most important witht he DynAPI is ensuring=20
> that new user can _USE_ it.
I totally agree. But the flexibility I require is meant to be able to=20
represent an Mac OS X Aqua scroller. Once we provide a set of pre=20
defined skins, most users will likely use one of them, and never deal=20
with the definition of a skin, they probably will stick with one of=20
them. And if they want a new skin, then these pre defined ones will=20
serves as examples.

> If every single widget is super complex with 53 different arguments=20
> 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. :-)
The most important thing to make the Aqua one is the INTERNAL use of a=20=

scrolling rectangle. Once that is done in the lightweight version, I=20
can eventually subclass it to make the Aqua one. But if it doesn't=20
exists as an api on the lightweight, I would have much more code to=20
overwrite. Introducing that design will make the lightweight version=20
much more usefull as a super class/skinnable class.

I'm fine with adding the skin in another class. But a too lightweight=20
version won't be used by anyone either if it doesn't look good or close=20=

to other known skin, most likely well known os skins.

Benoit

> =A0
> >So I think a good and simple way to implement this is to define the=20=

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

> but it should be used internally for the calculations.
> =A0
> What?
> =A0
> >For skinning the knob button, I'll need to be able to use 3 images:=20=

> the rounded edges and a repeating >background.
> >The skinning, on top of the images/size of the buttons should also=20
> contains their location.
> >As you can see, in the case where the buttons are together, there's=20=

> still an image on the top ....
> >I previously used skins as dictionary, defining a bunch of defined=20
> properties.
> =A0
>
> =A0