dynapi-dev — List related to the current DynAPI Core development

[Dynapi-Dev] skining standard

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

Okay about the comments on moving the buttons around on the scrollbar.
Maybe the skinning standard can include to ability to define the =
location and even the sizes
of 'floating' objects in a widget.=20

Each floating object would have an ID like .floating=3D0, and =
.floating=3D1
or something like that, this would allow you to define where you skin =
will but some object of the widget.

I don't really know how I would go about defining it. I don't have to =
time right htis minute to consider it.
But I'm sure between us we can come up with something.

That way certain widgets can have not just imaegs and color skinned, but =
layout.
IE: the scrollbar, your skin can define where the up and down buttons =
should be as well as where the knob's
'dragging rectange' should be.

Or in the case of a skin window, where your maximize, minimize, and =
restore buttons would be.

Also the skin could define some dimentions. Such as defining the =
'squarness' of a button (make it a rectangle or whatever) or definng the =
width of the border on a skinnable window.

[Dynapi-Dev] Light widgets. (or "remember the user!")

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

Okay. Maybe this is why the lightest widgets should be called =
widget_light.js

What I want everyone to understand is that not every user of the dynapi =
will be an advanced Javascript programmer. Nor are we desiging this =
soley for our use.

We are, after all, trying to define the next generation =
all-browser-all-platform javascript library here.

But in order to get any level of acceptance at all, we have to remember =
the users.

A _USER_ is not us.=20
A user has no intemate knowledge of the internal workings of the dynapi.
Nor do they want to.
A user can have any level of compentance.
Or none at all.
A user has the statistcal attention span of _7 seconds_=20
when looking at something new and shiney.

And where not just talking about people who find us through google =
either.
On more than one occasion I have landed a contract simply on the =
apperent strength of the DynAPI 2.
Not just that it's pretty and works, but that I could train any of their =
code monkeys to maintain the code I
would write for them.

Now comes DynAPI 3 and those contracts I did not get due to the api =
seeming 'slow' or 'heavy' now promise
to be a thing of the past. With tighter integration of inline creation, =
a smoother events structure, and ligher=20
acetecture this version actually has the portential to take off, to =
allow us to do greater thing, to let the _user_
do greater things, but none of this will matter if we forget to =
"remember the user"

:-)

Post Script: I am not saying more coplex widgets and components are bad, =
only that we need to maintain a base of simple widgets to allow for =
siple tasks to be completed by simple users.

Thus ends the official Doug Melvin Rant on Usability for DynAPI 3.. Had =
to come sooner or later right?=20
I just figured sooner would be better.

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

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

See comments inline:

----- Original Message -----=20
From: Benoit Marchant=20
To: Doug Melvin=20
Cc: dyn...@li...=20
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=20
>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=20
>down/reach an end.
=20
That would be nice.. I can implement it, but as desocvered before, it =
can be unreliable.=20
I.E. if you happen to move away from the button before letting the mouse =
button up, there will be no mouseup
=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=20
>always be equal to the scroller width, but the buttons aren't always =
square, and the height might be different. Even more=20
>complicated is the emulation of the aqua scrollers. The buttons have to =
contains the rounded edges, so they aren't squares.=20
>But their size for the calculations is different, it goes from the =
external side to the tangent of the rounded part. And=20
>the knob will go overlapping the button layers. So in order to =
implement that, I would need the scroller to be able to deal=20
>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=20
>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.

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.
Leave the light scrollbar as a light scrollbar please.
If you want an advanced scrollbar then code one. :-)

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

Re: [Dynapi-Dev] Discussion on treenode

[Kevin <ke...@ke...>]

Sounds good to me. I don't have much graphics experience so
I can't really comment on making widgets look nice. As I guess
that is putting a skin on them is chrome the same as skin or
much more. Please bear with me on the terminology.

Kevin
  ----- Original Message -----=20
  From: Doug Melvin=20
  To: dyn...@li...=20
  Sent: Tuesday, March 25, 2003 8:01 AM
  Subject: [Dynapi-Dev] Discussion on treenode


  The following is always up for debate.
  I only post it so as to get any feedback..
  I would love to see more than two people take an interest=20
  in such a complext and major component of the DynAPI.

  That said.

  I don't like the name treenode. I honestly don't think htere is ever a =
case where you will use only one node of a tree.

  I move to name the new widget DynTree.
  The DynTree will actually consist of two objects. Both will be =
declared in one file for simplicity.
  The two objects are:
  DynTree
  and
  DynNode

  The DynTree will hold all of the the tree manipulation functionality:
  -opening and closing branches
  -adding and removing nodes, ect.

  The DynNode will be very simple. It will have content.
  This allows the actuall size of a rendered tree to be reduced as a lot =
of code will only be instanciated once per tree. This should allow a =
N-numbered tree to be somewhat slimmer and faster than in the previous =
version.

  Once I have built an outline of what I intend to code I will post said =
outline for further discussion.

  Unless you want to simply give a dinasour like me free-reign? :-)

  The first version will be a 'light' version using only + and - signs =
with no images.
  As always, there will be a future 'skinable' version.

  WE can start a discussion about skinning methedology and standards any =
time now. :-)

  With so few active developers, we may get a standard hammered out in =
short-order, no?

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

[Raymond I. <xw...@ya...>]

Please see below:

--- Benoit Marchant <mar...@ma...> wrote:
> 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.
> 
> 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 !!
> 
> 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.
> 
> 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.

First off the Aqua Skins look cool! Some time ago I
had started a library that allowed me to change the
look, feel and behaviour of an object. It uses a
setStyle(name,clear) function (based on a StyleManager
class). This StyleManager would allow me to set
properties and functions as follows:

var style={
   backcolor : 'yellow',
   preRender : function(o,style){
       // some precreate code here
   },
   render : function(o,style,guiType){
        if(guiType=='base') {
           o.setBgColor(style.backcolor);
        }
   }   
}
StyleManager.addStyle('buttoncolor');

lyr.setStyle('buttoncolor');
// I can also add multiple style object
lyr.setStyle('togglebutton');


--
Raymond Irving

> 
> 
> 

> ATTACHMENT part 2 application/pdf
x-mac-hide-extension=yes; x-mac-creator=3F3F3F3F;
x-unix-mode=0644; x-mac-type=50444620; name=Picture
2.pdf


> ATTACHMENT part 3 application/pdf
x-mac-hide-extension=yes; x-mac-creator=3F3F3F3F;
x-unix-mode=0644; x-mac-type=50444620; name=Picture
3.pdf
> 
> I agree it's a very good idea to have a light
> version and a skinnable 
> one.
> 
> Benoit
> 
> On Sunday, March 23, 2003, at 01:28  AM, Doug Melvin
> wrote:
> 
> > introducing scrollbar_light
> > by light i mean no images.
> > I do intend to now produce one with images for
> skinablity.
> >  
> > the arguments for the scrollabr light are
> explained int he source of 
> > the HTML example file (attached)
> >  
> > The attached HTML file goes in the /examples/
> directory.
> > The attached JS file goes into the src/gui/
> directory
> >  
> > I hope rar format is okay for everyone.. if not
> let me know and I'll 
> > start using zip
> >  
> > Goddamn but this is very frusterating..
> > It has been a very long time since I have done any
> serious JS coding.
> > Not to mention that the new DynAPI is VERY
> different.
> > Here is some stuff that should be added to the
> docs.
> > Make any corrections nessesary.
> >  
> > -----------------start here---------------------
> > Dragevents:
> > To test if a layer (myLayer) is being dragged:
> > Each layer no longer has it's own 'dragging'
> property.
> > To test is a layer is being dragged you check the
> isDragging property 
> > of the
> > Dragevent engine (Dragevent.isDragging).
> > To test if a specific layer is being dragged you
> check if the layer 
> > being dragged (DragEvent.dragevent.src)
> > is the layer in question
> >  
> > 2.x code:
> > if(myLayer.dragging){ your code here}
> >  
> > 3x code:
> >
>
if(DragEvent.dragevent.isDragging&&DragEvent.dragevent.src===myLayer){
> 
> > your code here}
> >  
> > --------------------
> >
> > Responde to precreate/create event where the
> layer's variable name is 
> > myLayer:
> > You no longer assign an event listener for these
> two events.
> > Instead you pass a function to be execute at the
> precreate or create 
> > event.
> > The passed function is executed as if it where a
> method of the layer 
> > in question.
> > So, instead of getting the source of the event you
> simple use 'this' 
> > to refer to the layer
> > upon which the function is being executed
> >  
> >
> > (onCreate/onPrecreate)
> > 2.x code:
> > var el = new EventListener(myLayer);
> > el.onprecreate=function(e){
> >  e.getSource().doSomething();
> > }
> > el.oncreate=function(e){
> >  e.getSource().doSomething();
> > }
> > myLayer.addEventListener(el);
> >  
> > 3x code:
> > var createCode = function(){
> >  this.doSomething(); // note the use of 'this' to
> indicate the source 
> > of the create event
> > }
> > this.onCreate(createCode);
> >  
> > var preCreateCode = function(){
> >  this.doSomething(); // note the use of 'this' to
> indicate the source 
> > of the precreate event
> > }
> > this.onPrecreate(preCreateCode);
> > --------------end here---------------
> >  
> > <scrollbar_light.rar>


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [Dynapi-Dev] Discussion on treenode

[Raymond I. <xw...@ya...>]

Please see my comments below:

--- Doug Melvin <do...@cr...> wrote:
> The following is always up for debate.
> I only post it so as to get any feedback..
> I would love to see more than two people take an
> interest 
> in such a complext and major component of the
> DynAPI.
> 
> That said.
> 
> I don't like the name treenode. I honestly don't
> think htere is ever a case where you will use only
> one node of a tree.
> 
> I move to name the new widget DynTree.
> The DynTree will actually consist of two objects.
> Both will be declared in one file for simplicity.
> The two objects are:
> DynTree
> and
> DynNode
> 
> The DynTree will hold all of the the tree
> manipulation functionality:
> -opening and closing branches
> -adding and removing nodes, ect.
> 
> The DynNode will be very simple. It will have
> content.
> This allows the actuall size of a rendered tree to
> be reduced as a lot of code will only be
> instanciated once per tree. This should allow a
> N-numbered tree to be somewhat slimmer and faster
> than in the previous version.
> 
> Once I have built an outline of what I intend to
> code I will post said outline for further
> discussion.
> 
> Unless you want to simply give a dinasour like me
> free-reign? :-)
> 
> The first version will be a 'light' version using
> only + and - signs with no images.
> As always, there will be a future 'skinable'
> version.
> 
> WE can start a discussion about skinning methedology
> and standards any time now. :-)
> 
> With so few active developers, we may get a standard
> hammered out in short-order, no?

I'm in agreement with having a standard for skinnable
widgets. Something like a SkinManager that can be used
to add skinning functions to widgets/dynlayers. I
don't know much about skinning, but I'll go do some
research on it.

--
Raymond Irving

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [Dynapi-Dev] New (or renamed) Events

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

kool.. I'll have to re-write the scrollbar once the new code is in.
Currently the scrollbar actually overwrites the setSize method of the bound
layer
to allow detection of the layer's resizing..

This overloading is only done it you have specified that the scroll bar
should automatically resize it's knob.
----- Original Message -----
From: "Raymond Irving" <xw...@ya...>
To: "DynAPI-Dev" <dyn...@li...>
Sent: Monday, March 24, 2003 8:56 PM
Subject: Re: [Dynapi-Dev] New (or renamed) Events


>
> --- Doug Melvin <do...@cr...> wrote:
> > in cvs yet?
>
> Not as yet. I'm finishing up the FocusManager, so
> maybe tomorrow.
>
> --
> Raymond Irving
>
> > ----- Original Message -----
> > From: "Raymond Irving" <xw...@ya...>
> > To: "DynAPI-Dev" <dyn...@li...>
> > Sent: Monday, March 24, 2003 8:41 PM
> > Subject: Re: [Dynapi-Dev] New (or renamed) Events
> >
> >
> > >
> > > Please see below:
> > >
> > > --- Benoit Marchant <mar...@ma...> wrote:
> > > > See below
> > > > On Monday, March 24, 2003, at 03:01  PM, Raymond
> > > > Irving wrote:
> > > >
> > > > > Hello everyone,
> > > > >
> > > > > If you can recall, last week we had a
> > discussion
> > > > on
> > > > > the following events:
> > > > >
> > > > > onload - triggered by setHTML() - in dynapi
> > 2.x
> > > > > onmove - triggered by moveTo() - in dynapi 2.x
> > > > > onresize - triggered by setSize() - in dynapi
> > 2.x
> > > > >
> > > > > Well, I've added these with minor impact on
> > > > > performance:
> > > > What's the impact, just out of curiosity ?
> > >
> > > Well, if the parent layer has a onresize event nut
> > > it's children does not, the invokeEvent() will
> > still
> > > have to cycle through the children and invoke the
> > > event. IMO I think onresize and onlocationchange
> > > should hardly be used.
> > >
> > > > >
> > > > > oncontentchange - triggered by setHTML() - in
> > 3.0
> > > > > onlocationchange - triggered by setHTML() - in
> > 3.0
> > > > What have onlocationchange to do with setHTML ?
> > Typo
> > > > ?
> > >
> > > Yes, that's a typo. It's triggered by setLocation
> > >
> > > >
> > > > > onresize - triggered by setHTML() - in 3.0
> > > > What have onresize to do with setHTML ? Typo ?
> > >
> > > Same as above. This is triggered by setSize()
> > >
> > > > > 1) I've renamed onmove to onlocationchange to
> > keep
> > > > up
> > > > > with setLocation() naming convention.
> > > > >
> > > > > 2) Renamed onload to oncontentchange - IMO
> > onload
> > > > > should be reserved for loadpanels, loadlayers,
> > etc
> > > > >
> > > > > Any comments on the above?
> > > > >
> > > > > In addition to the above I've added the
> > fllowing:
> > > > >
> > > > > 1) setMaximumSize(), setMinimumSize() and
> > > > > setBorder(w,c) to dynlayer_base.js.
> > > > >
> > > > > 2) DynLayer.prototype.setDragMode(b,boundry)
> > to
> > > > > DragEvents
> > > > >
> > > > > 3) FocusManager - setFocus(b,bubble,type).
> > > > Example:
> > > > >
> > > > > - sets lyr as topmost layer and forces it's
> > > > parents
> > > > > and grandparants to become topmost layer
> > inside
> > > > their
> > > > > parent:
> > > > >
> > > > > lyr.setFocus(true);
> > > > >
> > > > > - set's lyr as topmost layer when it's
> > clicked:
> > > > >
> > > > > lyr.setFocus('auto',true)
> > > > > Or
> > > > > lyr.setFocus('auto',true,'click')
> > > > >
> > > > >
> > > > > - set's lyr as topmost layer when mouse is
> > passed
> > > > over
> > > > > it:
> > > > >
> > > > > lyr.setFocus('auto',true,'hover')
> > > > >
> > > > > Any comments?
> > > > >
> > > > > PS. These should be in cvs by now and
> > tomorrow.
> > > >
> > > > So once that is in, I'll modify the new api in
> > > > dragevent to be on
> > > > dynlayers rather than on DragEvent.
> > >
> > > Ok, that sounds great.
> > >
> > > --
> > > Raymond Irving
> > >
> > > > Benoit
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Platinum - Watch CBS' NCAA March Madness,
> > live on your desktop!
> > > http://platinum.yahoo.com
> > >
> > >
> > >
> >
> -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > >
> >
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > >
> >
> http://www.mail-archive.com/dyn...@li.../
> > >
> >
> >
> >
> -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> >
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> >
> http://www.mail-archive.com/dyn...@li.../
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>

[Dynapi-Dev] Discussion on treenode

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

The following is always up for debate.
I only post it so as to get any feedback..
I would love to see more than two people take an interest=20
in such a complext and major component of the DynAPI.

That said.

I don't like the name treenode. I honestly don't think htere is ever a =
case where you will use only one node of a tree.

I move to name the new widget DynTree.
The DynTree will actually consist of two objects. Both will be declared =
in one file for simplicity.
The two objects are:
DynTree
and
DynNode

The DynTree will hold all of the the tree manipulation functionality:
-opening and closing branches
-adding and removing nodes, ect.

The DynNode will be very simple. It will have content.
This allows the actuall size of a rendered tree to be reduced as a lot =
of code will only be instanciated once per tree. This should allow a =
N-numbered tree to be somewhat slimmer and faster than in the previous =
version.

Once I have built an outline of what I intend to code I will post said =
outline for further discussion.

Unless you want to simply give a dinasour like me free-reign? :-)

The first version will be a 'light' version using only + and - signs =
with no images.
As always, there will be a future 'skinable' version.

WE can start a discussion about skinning methedology and standards any =
time now. :-)

With so few active developers, we may get a standard hammered out in =
short-order, no?

Re: [Dynapi-Dev] New (or renamed) Events

[Raymond I. <xw...@ya...>]

--- Doug Melvin <do...@cr...> wrote:
> in cvs yet?

Not as yet. I'm finishing up the FocusManager, so
maybe tomorrow.

--
Raymond Irving
 
> ----- Original Message ----- 
> From: "Raymond Irving" <xw...@ya...>
> To: "DynAPI-Dev" <dyn...@li...>
> Sent: Monday, March 24, 2003 8:41 PM
> Subject: Re: [Dynapi-Dev] New (or renamed) Events
> 
> 
> > 
> > Please see below:
> > 
> > --- Benoit Marchant <mar...@ma...> wrote:
> > > See below
> > > On Monday, March 24, 2003, at 03:01  PM, Raymond
> > > Irving wrote:
> > > 
> > > > Hello everyone,
> > > >
> > > > If you can recall, last week we had a
> discussion
> > > on
> > > > the following events:
> > > >
> > > > onload - triggered by setHTML() - in dynapi
> 2.x
> > > > onmove - triggered by moveTo() - in dynapi 2.x
> > > > onresize - triggered by setSize() - in dynapi
> 2.x
> > > >
> > > > Well, I've added these with minor impact on
> > > > performance:
> > > What's the impact, just out of curiosity ?
> > 
> > Well, if the parent layer has a onresize event nut
> > it's children does not, the invokeEvent() will
> still
> > have to cycle through the children and invoke the
> > event. IMO I think onresize and onlocationchange
> > should hardly be used.
> > 
> > > >
> > > > oncontentchange - triggered by setHTML() - in
> 3.0
> > > > onlocationchange - triggered by setHTML() - in
> 3.0
> > > What have onlocationchange to do with setHTML ?
> Typo
> > > ?
> > 
> > Yes, that's a typo. It's triggered by setLocation
> > 
> > > 
> > > > onresize - triggered by setHTML() - in 3.0
> > > What have onresize to do with setHTML ? Typo ?
> > 
> > Same as above. This is triggered by setSize()
> > 
> > > > 1) I've renamed onmove to onlocationchange to
> keep
> > > up
> > > > with setLocation() naming convention.
> > > >
> > > > 2) Renamed onload to oncontentchange - IMO
> onload
> > > > should be reserved for loadpanels, loadlayers,
> etc
> > > >
> > > > Any comments on the above?
> > > >
> > > > In addition to the above I've added the
> fllowing:
> > > >
> > > > 1) setMaximumSize(), setMinimumSize() and
> > > > setBorder(w,c) to dynlayer_base.js.
> > > >
> > > > 2) DynLayer.prototype.setDragMode(b,boundry)
> to
> > > > DragEvents
> > > >
> > > > 3) FocusManager - setFocus(b,bubble,type).
> > > Example:
> > > >
> > > > - sets lyr as topmost layer and forces it's
> > > parents
> > > > and grandparants to become topmost layer
> inside
> > > their
> > > > parent:
> > > >
> > > > lyr.setFocus(true);
> > > >
> > > > - set's lyr as topmost layer when it's
> clicked:
> > > >
> > > > lyr.setFocus('auto',true)
> > > > Or
> > > > lyr.setFocus('auto',true,'click')
> > > >
> > > >
> > > > - set's lyr as topmost layer when mouse is
> passed
> > > over
> > > > it:
> > > >
> > > > lyr.setFocus('auto',true,'hover')
> > > >
> > > > Any comments?
> > > >
> > > > PS. These should be in cvs by now and
> tomorrow.
> > > 
> > > So once that is in, I'll modify the new api in
> > > dragevent to be on 
> > > dynlayers rather than on DragEvent.
> > 
> > Ok, that sounds great.
> > 
> > --
> > Raymond Irving
> >  
> > > Benoit
> > > 
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Platinum - Watch CBS' NCAA March Madness,
> live on your desktop!
> > http://platinum.yahoo.com
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> >
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> >
>
http://www.mail-archive.com/dyn...@li.../
> > 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
>
http://www.mail-archive.com/dyn...@li.../


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [Dynapi-Dev] New (or renamed) Events

[Raymond I. <xw...@ya...>]

Please see my comments below:

--- Kevin <ke...@ke...> wrote:
> Please see my comments below:
> -----
> Kevin.
> 
> > Raymond Irving <xw...@ya...> wrote:
> > Hello everyone,
> > 
> > If you can recall, last week we had a discussion
> on
> > the following events:
> > 
> > onload - triggered by setHTML() - in dynapi 2.x
> > onmove - triggered by moveTo() - in dynapi 2.x
> > onresize - triggered by setSize() - in dynapi 2.x
> > 
> > Well, I've added these with minor impact on
> > performance:
> > 
> > oncontentchange - triggered by setHTML() - in 3.0
> > onlocationchange - triggered by setHTML() - in 3.0
> > onresize - triggered by setHTML() - in 3.0
> 
> Could you include an example of usage of these
> events?

Ok, I'll add a few to the examples section

> Also is there a built in fix to the NS4 resize bug
> to force
> a redraw on onresize? 

I think so. Not sure

> Where was onload used before? I remember a change to
> the main dynapi.onLoad( function() {...} ) and
> onUnload.
> Is there an onload and onunload not relating to
> document
> loading events? 

Well, onload was also trigered by setHTML(), but I'm
changing onload to oncontentchange. Hopefully this
will help to clear things up.

 
> I like the border idea. Is it possible to go all the
> way
> and add margin and padding too. CSS syntax? 

Sure! I don't think that should be difficult. But I
would recommend that such additional feature be added
to a BorderManager. The BorderManager I'm working on
will extend the setBorder() function to even support
image as borders.
  
> 
> I am working on the TabManager now. Quite a
> challenge
> seeing as the tab key is so special and hardcoded to
> change
> focus to the address bar, links, sidebars,
> favourites etc. I
> nearly gave up and used the arrow keys. But now I
> have a
> working prototype using the tab key. I've just got
> to make
> it dynapish.

Cool! Very Cool!

> > - sets lyr as topmost layer and forces it's
> parents
> > and grandparants to become topmost layer inside
> their
> > parent:
> > 
> > lyr.setFocus(true);
> > 
> > - set's lyr as topmost layer when it's clicked: 
> > 
> > lyr.setFocus('auto',true) 
> > Or
> > lyr.setFocus('auto',true,'click') 
> > 
> > 
> > - set's lyr as topmost layer when mouse is passed
> over
> > it:
> > 
> > lyr.setFocus('auto',true,'hover')
> > 
> > Any comments?
> 
> A nice demo would be most appreciated.

Yep! As soon as I've added the code to cvs I'll setup
an online demo.


--
Raymond Irving

> 
> > PS. These should be in cvs by now and tomorrow.
> > 
> > --
> > Raymond Irving
> > 
> > Dynapi-Dev mailing list
> > Dyn...@li...
> >
>
http://www.mail-archive.com/dyn...@li.../
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

[Dynapi-Dev] Final Vote count.. <in bad singing voice>"where have all the coders gone? long time standing... "

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

> Doug Melvin: treenode
> Benoit Marchant: button, ViewPort, list
> Leif W: treenode
  Raymond: treeview, button

Total:
Treenode =3D 3
Button =3D 2
Viewport =3D 1
list =3D 1

So "servay say's!!..."
treenode

Re: [Dynapi-Dev] New (or renamed) Events

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

in cvs yet?

----- Original Message ----- 
From: "Raymond Irving" <xw...@ya...>
To: "DynAPI-Dev" <dyn...@li...>
Sent: Monday, March 24, 2003 8:41 PM
Subject: Re: [Dynapi-Dev] New (or renamed) Events


> 
> Please see below:
> 
> --- Benoit Marchant <mar...@ma...> wrote:
> > See below
> > On Monday, March 24, 2003, at 03:01  PM, Raymond
> > Irving wrote:
> > 
> > > Hello everyone,
> > >
> > > If you can recall, last week we had a discussion
> > on
> > > the following events:
> > >
> > > onload - triggered by setHTML() - in dynapi 2.x
> > > onmove - triggered by moveTo() - in dynapi 2.x
> > > onresize - triggered by setSize() - in dynapi 2.x
> > >
> > > Well, I've added these with minor impact on
> > > performance:
> > What's the impact, just out of curiosity ?
> 
> Well, if the parent layer has a onresize event nut
> it's children does not, the invokeEvent() will still
> have to cycle through the children and invoke the
> event. IMO I think onresize and onlocationchange
> should hardly be used.
> 
> > >
> > > oncontentchange - triggered by setHTML() - in 3.0
> > > onlocationchange - triggered by setHTML() - in 3.0
> > What have onlocationchange to do with setHTML ? Typo
> > ?
> 
> Yes, that's a typo. It's triggered by setLocation
> 
> > 
> > > onresize - triggered by setHTML() - in 3.0
> > What have onresize to do with setHTML ? Typo ?
> 
> Same as above. This is triggered by setSize()
> 
> > > 1) I've renamed onmove to onlocationchange to keep
> > up
> > > with setLocation() naming convention.
> > >
> > > 2) Renamed onload to oncontentchange - IMO onload
> > > should be reserved for loadpanels, loadlayers, etc
> > >
> > > Any comments on the above?
> > >
> > > In addition to the above I've added the fllowing:
> > >
> > > 1) setMaximumSize(), setMinimumSize() and
> > > setBorder(w,c) to dynlayer_base.js.
> > >
> > > 2) DynLayer.prototype.setDragMode(b,boundry) to
> > > DragEvents
> > >
> > > 3) FocusManager - setFocus(b,bubble,type).
> > Example:
> > >
> > > - sets lyr as topmost layer and forces it's
> > parents
> > > and grandparants to become topmost layer inside
> > their
> > > parent:
> > >
> > > lyr.setFocus(true);
> > >
> > > - set's lyr as topmost layer when it's clicked:
> > >
> > > lyr.setFocus('auto',true)
> > > Or
> > > lyr.setFocus('auto',true,'click')
> > >
> > >
> > > - set's lyr as topmost layer when mouse is passed
> > over
> > > it:
> > >
> > > lyr.setFocus('auto',true,'hover')
> > >
> > > Any comments?
> > >
> > > PS. These should be in cvs by now and tomorrow.
> > 
> > So once that is in, I'll modify the new api in
> > dragevent to be on 
> > dynlayers rather than on DragEvent.
> 
> Ok, that sounds great.
> 
> --
> Raymond Irving
>  
> > Benoit
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
> 

Re: [Dynapi-Dev] New (or renamed) Events

[Raymond I. <xw...@ya...>]

Please see below:

--- Benoit Marchant <mar...@ma...> wrote:
> See below
> On Monday, March 24, 2003, at 03:01  PM, Raymond
> Irving wrote:
> 
> > Hello everyone,
> >
> > If you can recall, last week we had a discussion
> on
> > the following events:
> >
> > onload - triggered by setHTML() - in dynapi 2.x
> > onmove - triggered by moveTo() - in dynapi 2.x
> > onresize - triggered by setSize() - in dynapi 2.x
> >
> > Well, I've added these with minor impact on
> > performance:
> What's the impact, just out of curiosity ?

Well, if the parent layer has a onresize event nut
it's children does not, the invokeEvent() will still
have to cycle through the children and invoke the
event. IMO I think onresize and onlocationchange
should hardly be used.

> >
> > oncontentchange - triggered by setHTML() - in 3.0
> > onlocationchange - triggered by setHTML() - in 3.0
> What have onlocationchange to do with setHTML ? Typo
> ?

Yes, that's a typo. It's triggered by setLocation

> 
> > onresize - triggered by setHTML() - in 3.0
> What have onresize to do with setHTML ? Typo ?

Same as above. This is triggered by setSize()

> > 1) I've renamed onmove to onlocationchange to keep
> up
> > with setLocation() naming convention.
> >
> > 2) Renamed onload to oncontentchange - IMO onload
> > should be reserved for loadpanels, loadlayers, etc
> >
> > Any comments on the above?
> >
> > In addition to the above I've added the fllowing:
> >
> > 1) setMaximumSize(), setMinimumSize() and
> > setBorder(w,c) to dynlayer_base.js.
> >
> > 2) DynLayer.prototype.setDragMode(b,boundry) to
> > DragEvents
> >
> > 3) FocusManager - setFocus(b,bubble,type).
> Example:
> >
> > - sets lyr as topmost layer and forces it's
> parents
> > and grandparants to become topmost layer inside
> their
> > parent:
> >
> > lyr.setFocus(true);
> >
> > - set's lyr as topmost layer when it's clicked:
> >
> > lyr.setFocus('auto',true)
> > Or
> > lyr.setFocus('auto',true,'click')
> >
> >
> > - set's lyr as topmost layer when mouse is passed
> over
> > it:
> >
> > lyr.setFocus('auto',true,'hover')
> >
> > Any comments?
> >
> > PS. These should be in cvs by now and tomorrow.
> 
> So once that is in, I'll modify the new api in
> dragevent to be on 
> dynlayers rather than on DragEvent.

Ok, that sounds great.

--
Raymond Irving
 
> Benoit
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Fw: [Dynapi-Dev] New (or renamed) Events

[Kevin <ke...@ke...>]

Fwd to Dynapi-Dev.

> Please see my comments below:
> -----
> Kevin.
> 
> > Raymond Irving <xw...@ya...> wrote:
> > Hello everyone,
> > 
> > If you can recall, last week we had a discussion on
> > the following events:
> > 
> > onload - triggered by setHTML() - in dynapi 2.x
> > onmove - triggered by moveTo() - in dynapi 2.x
> > onresize - triggered by setSize() - in dynapi 2.x
> > 
> > Well, I've added these with minor impact on
> > performance:
> > 
> > oncontentchange - triggered by setHTML() - in 3.0
> > onlocationchange - triggered by setHTML() - in 3.0
> > onresize - triggered by setHTML() - in 3.0
> 
> Could you include an example of usage of these events?
> Also is there a built in fix to the NS4 resize bug to force
> a redraw on onresize? 
>  
> > 1) I've renamed onmove to onlocationchange to keep up
> > with setLocation() naming convention. 
> > 
> > 2) Renamed onload to oncontentchange - IMO onload
> > should be reserved for loadpanels, loadlayers, etc
> 
> Where was onload used before? I remember a change to
> the main dynapi.onLoad( function() {...} ) and onUnload.
> Is there an onload and onunload not relating to document
> loading events? 
>  
> > Any comments on the above?
> > 
> > In addition to the above I've added the fllowing:
> > 
> > 1) setMaximumSize(), setMinimumSize() and
> > setBorder(w,c) to dynlayer_base.js. 
> 
> I like the border idea. Is it possible to go all the way
> and add margin and padding too. CSS syntax? 
>  
> > 2) DynLayer.prototype.setDragMode(b,boundry) to
> > DragEvents
> > 
> > 3) FocusManager - setFocus(b,bubble,type). Example:
> 
> 
> I am working on the TabManager now. Quite a challenge
> seeing as the tab key is so special and hardcoded to change
> focus to the address bar, links, sidebars, favourites etc. I
> nearly gave up and used the arrow keys. But now I have a
> working prototype using the tab key. I've just got to make
> it dynapish.
> 
> > - sets lyr as topmost layer and forces it's parents
> > and grandparants to become topmost layer inside their
> > parent:
> > 
> > lyr.setFocus(true);
> > 
> > - set's lyr as topmost layer when it's clicked: 
> > 
> > lyr.setFocus('auto',true) 
> > Or
> > lyr.setFocus('auto',true,'click') 
> > 
> > 
> > - set's lyr as topmost layer when mouse is passed over
> > it:
> > 
> > lyr.setFocus('auto',true,'hover')
> > 
> > Any comments?
> 
> A nice demo would be most appreciated.
> 
> > PS. These should be in cvs by now and tomorrow.
> > 
> > --
> > Raymond Irving
> > 
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://www.mail-archive.com/dyn...@li.../
> 

Re: [Dynapi-Dev] New (or renamed) Events

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

See below
On Monday, March 24, 2003, at 03:01  PM, Raymond Irving wrote:

> Hello everyone,
>
> If you can recall, last week we had a discussion on
> the following events:
>
> onload - triggered by setHTML() - in dynapi 2.x
> onmove - triggered by moveTo() - in dynapi 2.x
> onresize - triggered by setSize() - in dynapi 2.x
>
> Well, I've added these with minor impact on
> performance:
What's the impact, just out of curiosity ?
>
> oncontentchange - triggered by setHTML() - in 3.0
> onlocationchange - triggered by setHTML() - in 3.0
What have onlocationchange to do with setHTML ? Typo ?

> onresize - triggered by setHTML() - in 3.0
What have onresize to do with setHTML ? Typo ?
>
> 1) I've renamed onmove to onlocationchange to keep up
> with setLocation() naming convention.
>
> 2) Renamed onload to oncontentchange - IMO onload
> should be reserved for loadpanels, loadlayers, etc
>
> Any comments on the above?
>
> In addition to the above I've added the fllowing:
>
> 1) setMaximumSize(), setMinimumSize() and
> setBorder(w,c) to dynlayer_base.js.
>
> 2) DynLayer.prototype.setDragMode(b,boundry) to
> DragEvents
>
> 3) FocusManager - setFocus(b,bubble,type). Example:
>
> - sets lyr as topmost layer and forces it's parents
> and grandparants to become topmost layer inside their
> parent:
>
> lyr.setFocus(true);
>
> - set's lyr as topmost layer when it's clicked:
>
> lyr.setFocus('auto',true)
> Or
> lyr.setFocus('auto',true,'click')
>
>
> - set's lyr as topmost layer when mouse is passed over
> it:
>
> lyr.setFocus('auto',true,'hover')
>
> Any comments?
>
> PS. These should be in cvs by now and tomorrow.

So once that is in, I'll modify the new api in dragevent to be on 
dynlayers rather than on DragEvent.

Benoit

>
> --
> Raymond Irving
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>

[Dynapi-Dev] New (or renamed) Events

[Raymond I. <xw...@ya...>]

Hello everyone,

If you can recall, last week we had a discussion on
the following events:

onload - triggered by setHTML() - in dynapi 2.x
onmove - triggered by moveTo() - in dynapi 2.x
onresize - triggered by setSize() - in dynapi 2.x

Well, I've added these with minor impact on
performance:

oncontentchange - triggered by setHTML() - in 3.0
onlocationchange - triggered by setHTML() - in 3.0
onresize - triggered by setHTML() - in 3.0

1) I've renamed onmove to onlocationchange to keep up
with setLocation() naming convention. 

2) Renamed onload to oncontentchange - IMO onload
should be reserved for loadpanels, loadlayers, etc

Any comments on the above?

In addition to the above I've added the fllowing:

1) setMaximumSize(), setMinimumSize() and
setBorder(w,c) to dynlayer_base.js. 

2) DynLayer.prototype.setDragMode(b,boundry) to
DragEvents

3) FocusManager - setFocus(b,bubble,type). Example:

- sets lyr as topmost layer and forces it's parents
and grandparants to become topmost layer inside their
parent:

lyr.setFocus(true);

- set's lyr as topmost layer when it's clicked: 

lyr.setFocus('auto',true) 
Or
lyr.setFocus('auto',true,'click') 


- set's lyr as topmost layer when mouse is passed over
it:

lyr.setFocus('auto',true,'hover')

Any comments?

PS. These should be in cvs by now and tomorrow.

--
Raymond Irving


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [Dynapi-Dev] Vote count to date: open for one more day

[Raymond I. <xw...@ya...>]

--- Doug Melvin <do...@cr...> wrote:
> Vote count for the next widget (scrollpane will be
> done before the votes are in)
> Doug Melvin: treenode
> Benoit Marchant: button, ViewPort, list
> Leif W: treenode
  Raymond: treeview, button
> 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [Dynapi-Dev] No comments? No Votes?

[Raymond I. <xw...@ya...>]

Nice work Doug,

I would suggest option b:

ScrollBar - for light-weight faster loading widgets
with a file name of scrollbar.js
ScrollBarAdvance - for advance features.
scrollbar.advance.js - the advance scrollbar should
contain the skin features if necessary.

--
Raymond Irving

--- Doug Melvin <do...@cr...> wrote:
> Regardless of naming convention, I intend to only
> produce light widgets at first.
> This will allow a larger number of widgets to be
> completed and realeases (and tested)
> in as short a time as possable.
>   ----- Original Message ----- 
>   From: Doug Melvin 
>   To: dyn...@li... 
>   Sent: Sunday, March 23, 2003 6:20 PM
>   Subject: Re: [Dynapi-Dev] No comments? No Votes?
> 
> 
>   Lacking a response I will work on a scroll pane
> light.
>   Features will include:
>   Overloaded setHTML and addChild (too sethtml or
> add children directly to the display area)
>   Overloaded setSize function to automatically scale
> the scroll knobs (if the option is set)
> 
> 
>   I would like feedback on nameing conventions of
> gui components as it is soon enough to change what
> I'm using:
>   Option A) which I am currently using
>   1) Widget_light : a widghet which is a
> light-weight as possable
>   2) WIdget : a widget wich is a little more heavy,
> has images/skinnable
>   3) Widget_advanced: a widget with added features
> not normally required 
>       I.E. -an autoscroll feature (when the mouse is
> simply over the button, invoke the scrolling)
>             -a continuous scroll feature where the
> scroll keeps going while you hold mousebutton down
> on the scrol button
> 
>   Otion b)
>   1) Widget : a widget which is a light-weight as
> possable (default)
>   2) Wiget_skinned : a widget wich is a little more
> heavy, has images/skinnable
>   3) Widget_advanced: a widget with added features
> not normally required 
>       I.E. -an autoscroll feature (when the mouse is
> simply over the button, invoke the scrolling)
>             -a continuous scroll feature where the
> scroll keeps going while you hold mousebutton down
> on the scrol button
> 
>   ----- Original Message ----- 
>     From: Doug Melvin 
>     To: dyn...@li... 
>     Sent: Sunday, March 23, 2003 6:09 PM
>     Subject: [Dynapi-Dev] No comments? No Votes?
> 
> 
>     <tap tap tap> is this thing on?


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [Dynapi-Dev] No comments? No Votes?

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

Regardless of naming convention, I intend to only produce light widgets =
at first.
This will allow a larger number of widgets to be completed and realeases =
(and tested)
in as short a time as possable.
  ----- Original Message -----=20
  From: Doug Melvin=20
  To: dyn...@li...=20
  Sent: Sunday, March 23, 2003 6:20 PM
  Subject: Re: [Dynapi-Dev] No comments? No Votes?


  Lacking a response I will work on a scroll pane light.
  Features will include:
  Overloaded setHTML and addChild (too sethtml or add children directly =
to the display area)
  Overloaded setSize function to automatically scale the scroll knobs =
(if the option is set)


  I would like feedback on nameing conventions of gui components as it =
is soon enough to change what I'm using:
  Option A) which I am currently using
  1) Widget_light : a widghet which is a light-weight as possable
  2) WIdget : a widget wich is a little more heavy, has images/skinnable
  3) Widget_advanced: a widget with added features not normally required =

      I.E. -an autoscroll feature (when the mouse is simply over the =
button, invoke the scrolling)
            -a continuous scroll feature where the scroll keeps going =
while you hold mousebutton down on the scrol button

  Otion b)
  1) Widget : a widget which is a light-weight as possable (default)
  2) Wiget_skinned : a widget wich is a little more heavy, has =
images/skinnable
  3) Widget_advanced: a widget with added features not normally required =

      I.E. -an autoscroll feature (when the mouse is simply over the =
button, invoke the scrolling)
            -a continuous scroll feature where the scroll keeps going =
while you hold mousebutton down on the scrol button

  ----- Original Message -----=20
    From: Doug Melvin=20
    To: dyn...@li...=20
    Sent: Sunday, March 23, 2003 6:09 PM
    Subject: [Dynapi-Dev] No comments? No Votes?


    <tap tap tap> is this thing on?

[Dynapi-Dev] Vote count to date: open for one more day

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

Vote count for the next widget (scrollpane will be done before the votes =
are in)
Doug Melvin: treenode
Benoit Marchant: button, ViewPort, list
Leif W: treenode

Re: [Dynapi-Dev] No comments? No Votes?

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

Yup, it is the same thing.
----- Original Message -----
From: "Leif W" <war...@us...>
To: <dyn...@li...>
Sent: Sunday, March 23, 2003 3:21 PM
Subject: Re: [Dynapi-Dev] No comments? No Votes?


> This is a second for treenode.  Not sure if this is the same thing, but it
> looked cool.
>
> http://www.richardinfo.com/examples/Richard_Examples/ri_fast_tree_view.htm
>
> Leif
>
> ----- Original Message -----
> From: Doug Melvin
> To: dyn...@li...
> Sent: Sunday, March 23, 2003 9:09 PM
> Subject: [Dynapi-Dev] No comments? No Votes?
>
>
> <tap tap tap> is this thing on?
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open!
> Get cracking and register here for some mind boggling fun and
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>

Re: [Dynapi-Dev] No comments? No Votes?

[Leif W <war...@us...>]

This is a second for treenode.  Not sure if this is the same thing, but it
looked cool.

http://www.richardinfo.com/examples/Richard_Examples/ri_fast_tree_view.htm

Leif

----- Original Message -----
From: Doug Melvin
To: dyn...@li...
Sent: Sunday, March 23, 2003 9:09 PM
Subject: [Dynapi-Dev] No comments? No Votes?


<tap tap tap> is this thing on?

[Dynapi-Dev] Vote count to date: open for one more day

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

Vote count for the next widget (scrollpane will be done before the votes =
are in)
Doug Melvin: DynTree
Benoit Marchant: button, ViewPort, list

Re: [Dynapi-Dev] No comments? No Votes?

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

Hi Doug,

It's sunday after all ! I'll test it tomorow !!
What about button ? ViewPort ? lists ?

Benoit

On Sunday, March 23, 2003, at 06:09 PM, Doug Melvin wrote:

> <tap tap tap> is this thing on?

Re: [Dynapi-Dev] No comments? No Votes?

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

Lacking a response I will work on a scroll pane light.
Features will include:
Overloaded setHTML and addChild (too sethtml or add children directly to =
the display area)
Overloaded setSize function to automatically scale the scroll knobs (if =
the option is set)


I would like feedback on nameing conventions of gui components as it is =
soon enough to change what I'm using:
Option A) which I am currently using
1) Widget_light : a widghet which is a light-weight as possable
2) WIdget : a widget wich is a little more heavy, has images/skinnable
3) Widget_advanced: a widget with added features not normally required=20
    I.E. -an autoscroll feature (when the mouse is simply over the =
button, invoke the scrolling)
          -a continuous scroll feature where the scroll keeps going =
while you hold mousebutton down on the scrol button

Otion b)
1) Widget : a widget which is a light-weight as possable (default)
2) Wiget_skinned : a widget wich is a little more heavy, has =
images/skinnable
3) Widget_advanced: a widget with added features not normally required=20
    I.E. -an autoscroll feature (when the mouse is simply over the =
button, invoke the scrolling)
          -a continuous scroll feature where the scroll keeps going =
while you hold mousebutton down on the scrol button

----- Original Message -----=20
  From: Doug Melvin=20
  To: dyn...@li...=20
  Sent: Sunday, March 23, 2003 6:09 PM
  Subject: [Dynapi-Dev] No comments? No Votes?


  <tap tap tap> is this thing on?