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

[Doug Melvin]

See comments inline:   ----- Original Message ----- From: Benoit Marchant To: Doug Melvin Cc: [EMAIL PROTECTED] 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 >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 >down/reach an end.   That would be nice.. I can implement it, but as desocvered before, it can be unreliable. I.E. if you happen to move away from the button before letting the mouse button up, there will be no mouseup     >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 >always be equal to the scroller width, but the buttons aren't always square, and the height might be different. Even more >complicated is the emulation of the aqua scrollers. The buttons have to contains the rounded edges, so they aren't squares. >But their size for the calculations is different, it goes from the external side to the tangent of the rounded part. And >the knob will go overlapping the button layers. So in order to 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 on the same side :-) and in that configuration, the 2 >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 >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 >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 >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.