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

[Doug M. <do...@cr...>]

Note in the below conversation the use of the statement What?
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.=20

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.=20

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.
3) Let's discuss a skinning standard.
4) Let's explore the 'skin defined floating objects' concept? Good =
concept? Insane? Just plain stupid?
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 -----=20
  From: Benoit Marchant=20
  To: Doug Melvin=20
  Cc: dyn...@li...=20
  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:
    =20
    ----- 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 =
port: scrollbar_light
    =20

    >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.
    =20
    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.


    =20
    =20
    >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 !!
    =20
    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 :-)

    =20
    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


    =20
    >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.
    =20
    What?
    =20
    >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.
    =20

    =20