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

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

On Tuesday, March 25, 2003, at 10:31  PM, Doug Melvin wrote:

> Note in the below conversation the use of the statement=A0What?
> I did not quite understand the use and implementation of the =
rectangle.
> =A0
> I ask only for clarification.
> =A0
> For continuous scrolling.
> We get mousout? Is that in all browsers? Kool, I'll add it. As well as=20=

> autoscrolling.
> =A0
> For the mac osX scroller.. I think if we implement a skinning standard=20=

> that can define location of floating objects
> this need can be most easily met. Or you can simply sub-class the=20
> light scrollbar to be you aqua one.
> I will need to know more about this scrolling rectangle.
> =A0
> Could the dragboundry be read for the purpose of determining scroll=20
> position (scroll ratio)?
> =A0
> I will NOT add 20 arguments to the 'light' scrollbar to allow you to=20=

> define where each and every component
> is, what shapes they will be, what colour they will be on tuesday and=20=

> weather you can see them on wednesday. :-)
> =A0
> It is ment as a very simple, very light scrollbar. If _you_ wish to=20
> subclass it to have parameters or functions
> allowing you to redifine the layout of the objects: be my guest.
> =A0
> The intention was, and I say again, to create a very simple, very=20
> light-weight scrollbar.
> =A0
> I am still willing to discuss adding some modifications to make=20
> subclassing easier.
> I am even willing to discuss modifying it to meet some GUI component=20=

> standard: when we have such a standard.
> (which we do not)
> =A0
> So..
> 1) Tell me about this scrolling rectangle. Can I use the dragboundry?=20=

> I will implement my own interpretation
> =A0=A0=A0 tonight and we can go from there.
I think that's exactly the same thing, you're right ! The drag boundary=20=

already define the rectangle within which the scroll knob can move.

> 2) I will add continuous scrolling tonight.
Great !

> 3) Let's discuss a skinning standard.
> 4) Let's explore the 'skin defined floating objects' concept? Good=20
> concept? Insane? Just plain stupid?
Should 3&4 be talked in the same time ?

Benoit

> 5) should we discuss a GUI component standard? If so, let's do it.
> =A0
> 6) But hey.. if we will have discussions on standards.. let's have one=20=

> at a time, okay?
> =A0
> I vote to start off with a GUI component standard.
> This conversation would not discuss skinning directly, but could cover=20=

> topics allowing
> easier sub-classing of a non-skinned component into a skinnable one.
> =A0
> =A0
>
> ----- Original Message -----
> From: Benoit Marchant
> To: Doug Melvin
> Cc: dyn...@li...
> Sent: Tuesday, March 25, 2003 5:28 PM
> Subject: Re: [Dynapi-Dev] Here it is.. the first DynAPI 3x widget=20
> port: scrollbar_light
>
>
> 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=20
> close 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
>