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