On Tuesday, March 25, 2003, at 10:31 PM, Doug Melvin wrote:
Note in the below conversation the use of the statement What?I think that's exactly the same thing, you're right ! The drag boundary already define the rectangle within which the scroll knob can move.
I did not quite understand the use and implementation of the rectangle.
I ask only for clarification.
For continuous scrolling.
We get mousout? Is that in all browsers? Kool, I'll add it. As well as autoscrolling.
For the mac osX scroller.. I think if we implement a skinning standard that can define location of floating objects
this need can be most easily met. Or you can simply sub-class the light scrollbar to be you aqua one.
I will need to know more about this scrolling rectangle.
Could the dragboundry be read for the purpose of determining scroll position (scroll ratio)?
I will NOT add 20 arguments to the 'light' scrollbar to allow you to define where each and every component
is, what shapes they will be, what colour they will be on tuesday and weather you can see them on wednesday. :-)
It is ment as a very simple, very light scrollbar. If _you_ wish to subclass it to have parameters or functions
allowing you to redifine the layout of the objects: be my guest.
The intention was, and I say again, to create a very simple, very light-weight scrollbar.
I am still willing to discuss adding some modifications to make subclassing easier.
I am even willing to discuss modifying it to meet some GUI component standard: when we have such a standard.
(which we do not)
So..
1) Tell me about this scrolling rectangle. Can I use the dragboundry? I will implement my own interpretation
tonight and we can go from there.
2) I will add continuous scrolling tonight.Great !
3) Let's discuss a skinning standard.Should 3&4 be talked in the same time ?
4) Let's explore the 'skin defined floating objects' concept? Good concept? Insane? Just plain stupid?
Benoit
5) should we discuss a GUI component standard? If so, let's do it.
6) But hey.. if we will have discussions on standards.. let's have one at a time, okay?
I vote to start off with a GUI component standard.
This conversation would not discuss skinning directly, but could cover topics allowing
easier sub-classing of a non-skinned component into a skinnable one.
----- Original Message -----
From: Benoit Marchant
To: Doug Melvin
Cc: [EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 5:28 PM
Subject: Re: [Dynapi-Dev] Here it is.. the first DynAPI 3x widget port: scrollbar_light
On Tuesday, March 25, 2003, at 05:27 PM, Doug Melvin wrote:
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
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.
>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.
Sure, that could lead to absurd positioning ... but that's not how I meant to use it :-)
On of the things that is most important witht he DynAPI is ensuring that new user can _USE_ it.
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.
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. :-)
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.
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.
