On Tuesday, March 25, 2003, at 05:27 PM, Doug Melvin wrote:
See comments inline:But you get a mouseout, and when you get one, it needs to stop. If you get mouseover and still no mouseup, than start again.
----- 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
Sure, that could lead to absurd positioning ... but that's not how I meant to use it :-)
>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.
I totally agree. But the flexibility I require is meant to be able to represent an Mac OS X Aqua scroller. Once we provide a set of pre defined skins, most users will likely use one of them, and never deal with the definition of a skin, they probably will stick with one of them. And if they want a new skin, then these pre defined ones will serves as examples.
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.The most important thing to make the Aqua one is the INTERNAL use of a scrolling rectangle. Once that is done in the lightweight version, I can eventually subclass it to make the Aqua one. But if it doesn't exists as an api on the lightweight, I would have much more code to overwrite. Introducing that design will make the lightweight version much more usefull as a super class/skinnable class.
Leave the light scrollbar as a light scrollbar please.
If you want an advanced scrollbar then code one. :-)
I'm fine with adding the skin in another class. But a too lightweight version won't be used by anyone either if it doesn't look good or close to other known skin, most likely well known os skins.
Benoit
>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.
