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

Re: [Dynapi-Dev] 3D borders

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

Very nice! I will be adding that as well..
I think first I will create a dynButton and then use the DynButton
int he scrollbar. Any comments?
----- Original Message ----- 
From: "Raymond Irving" <xw...@ya...>
To: "DynAPI-Dev" <dyn...@li...>
Sent: Wednesday, March 26, 2003 3:46 PM
Subject: [Dynapi-Dev] 3D borders


> Hi Everyone,
> 
> >From Dougs ScrollBar I've learnt an easy way to create
> cool looking 3D borders:
> 
> Up State :
> 
> <table border="0" bgcolor="#EFEBD7" cellpadding=0
> cellspacing=0 ><tr><td>
> <table width=100 height=100 cellpadding=0
> cellspacing=0 border=1><td></td></table>
> </td></tr></table>
> 
> Down/Depressed State:
> 
> <table border="0" bgcolor="#EFEBD7" cellpadding=0
> cellspacing=0 ><tr><td>
> <table width=100 height=100 cellpadding=0
> cellspacing=0 border=1><td>&nbsp;</td></table>
> </td></tr></table>
> 
> It works in all browsers. The trick is not to have
> anything between <td></td> for up state, and for down
> state just add a &nbsp; between inside the
> <td>&nbsp;</td>. A transparent image should work
> better than the &nbsp;
> 
> <img style="display:block" width="1" height="1"
> src="pixel.gif" />
> 
> You can even change the light and dark colors for
> ie/dom browsers. for example:
> 
> bordercolorlight="#FFFF00" bordercolordark="#808000"
> 
> --
> 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:
> 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] 3D borders

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

Hi Everyone,

From Dougs ScrollBar I've learnt an easy way to create
cool looking 3D borders:

Up State :

<table border="0" bgcolor="#EFEBD7" cellpadding=0
cellspacing=0 ><tr><td>
<table width=100 height=100 cellpadding=0
cellspacing=0 border=1><td></td></table>
</td></tr></table>

Down/Depressed State:

<table border="0" bgcolor="#EFEBD7" cellpadding=0
cellspacing=0 ><tr><td>
<table width=100 height=100 cellpadding=0
cellspacing=0 border=1><td>&nbsp;</td></table>
</td></tr></table>

It works in all browsers. The trick is not to have
anything between <td></td> for up state, and for down
state just add a &nbsp; between inside the
<td>&nbsp;</td>. A transparent image should work
better than the &nbsp;

<img style="display:block" width="1" height="1"
src="pixel.gif" />

You can even change the light and dark colors for
ie/dom browsers. for example:

bordercolorlight="#FFFF00" bordercolordark="#808000"

--
Raymond Irving

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

Re: [Dynapi-Dev] New BlackBoard concept for DynAPI 3.0

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

--- Doug Melvin <do...@cr...> wrote:
> See below:
> 
> > I'm also looking at adding a two new features to
> the
> > dynapi.document object. These are as follows:
> > 
> > dynapi.document.writeln(html,key) and
> > dynapi.document.deleteln(key)
> > 
> > These will allow a user to write/append html
> content
> > to the document even after the page has been
> loaded.
> > The deleteln(key) will also the user to delete
> html
> > content from the document once the page is loaded.
> 
> > 
> > These two new functions will enable us to
> dynamically
> > download (inline) portions of a huge app, append
> the
> > content to the document and then create the object
> use
> > blueprint/inline create features.
> > 
> > What do you all thing?
> I thing it's a greate idea!!
> This would have come in very handy when I built
> figure8's site as
> I would have allowed be to load only portions of the
> tree at a time.
> (800+ nodes can take a VERY long time to download,
> never mind rendering)
> 

Well these two functions will require a lot of
testing, but I think it's possible after many
sleepless nights :)

--
Raymond Irving
 
> 
>
-------------------------------------------------------
> 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] FocusManager Online Demo

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

--- Kevin <ke...@ke...> wrote:
> --- Kevin <ke...@ke...> wrote:
> > > Very good. Is the addition of a border onfocus
> > > optional?
> > 
> > Yes, the onfocus/onblur events are optional (user
> > defined)
> 
> Just a quick point as I have coded TabManager with
> the same onfocus/onblur events. In addition an
> onsubmit
> which will execute a callback function. i.e. When
> the
> user hits <return> or <space> on the selected
> dynLayer/
> widget/tab.

Cool. I think it would be nice for TabManager to call
setFocus if  setFocus is available, otherwise it would
invoke the onfocus/onblur events.
 
> Do you think the user should call the function in
> their
> event handler or have the TabManager do it for them?
> I have implemented the first idea at the moment.

The user should call whatever function they want when
the onsubmit is triggered. Don't use a callback
function. Just trigger the onsubmit event and the user
can then deceide what to do from there. This IMO is
more flexible.

PS. The onsubmit feature is very cool. Does it also
work in NS4?

Keep up the good work.

--
Raymond Irving
 
> var el={
>   onblur:function(e) { ... },
>   onfocus:function(e) { ... },
>   onsubmit:function(e) {
>     var o=e.getSource();
>     o.callSubmitFn();
>   }
> }
> lyr.addSubmitFn('ds.func1()');
> lyr.addEventListener(el);
> 
> Perhaps you could have ondblclick as a submit
> event with callback function for FocusManger?
> -----
> Kevin.
> 
> 
> > --
> > Raymond Irving
> > 
> > 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

[Dynapi-Dev] My options on ScrollBar Light

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

Hi Everyone,

(The views expressed below are my own and are not
intented to hurt anyone. I'm just expressing things as
I see them in my option)


1) First off - In keeping with naming conventions I
would add the prefix btn before buttons (e.g btnUp,
btnDown,etc). This is something that I've learned will
coding in vb. The truth is this is of little value but
it's just my option.

2) The this.KnobListener should not be created inside
the constructor. This IMO is a performance hit as the
javascript engine will have to create an object and a
function for each scrollbar. IMO it should be placed
on the prototype of the scrollbar:

function scrollbar_light(){
   // code here...
   this.knob.addEventListener(this.KnobListener);
};
scrollbar_light.prototype.KnobListener={
  // events here
};

The same should go for the other events. In this
approach the functions and objects are created only
once.

3) Instead of reseting the sizes of the buttons by
calling setSize inside the allignObjects() functions I
would recommend that the setAnchor() function be used.
You just set it and forget it:

// inside constructor
if (this.orientation) { //vertical
   var al={left:0,right:0};
   this.upBTN.setAnchor(al);
   this.downBTN.setAnchor(al);
   this.knob.setAnchor(al);
}else { //horizontal
   var al = {top:0,bottom:0};
   this.upBTN.setAnchor(al);
   this.downBTN.setAnchor(al);
   this.knob.setAnchor(al);
}

For a very good example of anchoring/strecthing see
dynapi.api.dynlayer-anchor-stretching.html and
dynapi.api.dynlayer-anchor.html

The same can be down for the knob by using the
stretchV and stretchH attributes. for example:
stretchV:'40%' can be used to stretch the knob '40%'
of it's parent width or stretchV:90 will set the
knob's height to 90 pixels

3) I've found the scrollbar from dynapi 2.x days to be
very difficult to use. I never liked the setRatio()
and getRatio() functions. I think the the simplicity
of the Visual Basic scrollbar is much prefered than
setRatio(). 

I think the scrollbar should have a setRange(min,man)
function that allows me to set a range of values to
scroll. I can then use getValue() and setValue()
functions to set or get the value of the scrollbar.
When I call setValue(v) it will force the scrollbar
knob to move to the section where the value can be
found.

example:

hscBar.setRange(0,1000);
hscBar.setValue(120); // simulates a user scroll
// ^ set knob to value 120 within the range 0-1000
// some code here.....
var v = hscBar.getValue();

That's it!

Well in summary I think the scrollbar looks good, but
I'd like it better if it had arrows :).
Since this is the light version I would suggest that
you use ←, →, ↑, ↓ or + - to
indicate up/down or left/right.

Keep up the good work.

Best regards.

--
Raymond Irving



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

Re: [Dynapi-Dev] FocusManager Online Demo

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

--- Kevin <ke...@ke...> wrote:
> > Very good. Is the addition of a border onfocus
> > optional?
> 
> Yes, the onfocus/onblur events are optional (user
> defined)

Just a quick point as I have coded TabManager with
the same onfocus/onblur events. In addition an onsubmit
which will execute a callback function. i.e. When the
user hits <return> or <space> on the selected dynLayer/
widget/tab.

Do you think the user should call the function in their
event handler or have the TabManager do it for them?
I have implemented the first idea at the moment.

var el={
  onblur:function(e) { ... },
  onfocus:function(e) { ... },
  onsubmit:function(e) {
    var o=e.getSource();
    o.callSubmitFn();
  }
}
lyr.addSubmitFn('ds.func1()');
lyr.addEventListener(el);

Perhaps you could have ondblclick as a submit
event with callback function for FocusManger?
-----
Kevin.


> --
> Raymond Irving
> 
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../

Re: [Dynapi-Dev] New BlackBoard concept for DynAPI 3.0

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

See below:

> I'm also looking at adding a two new features to the
> dynapi.document object. These are as follows:
> 
> dynapi.document.writeln(html,key) and
> dynapi.document.deleteln(key)
> 
> These will allow a user to write/append html content
> to the document even after the page has been loaded.
> The deleteln(key) will also the user to delete html
> content from the document once the page is loaded. 
> 
> These two new functions will enable us to dynamically
> download (inline) portions of a huge app, append the
> content to the document and then create the object use
> blueprint/inline create features.
> 
> What do you all thing?
I thing it's a greate idea!!
This would have come in very handy when I built figure8's site as
I would have allowed be to load only portions of the tree at a time.
(800+ nodes can take a VERY long time to download, never mind rendering)

Re: [Dynapi-Dev] New BlackBoard concept for DynAPI 3.0

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

--- Doug Melvin <do...@cr...> wrote:
> I like very much.
> Should it be an extension?
> I think it would be best as a native functionality
> (imho)

I'm also of the opinion that it should be a native
function.

> Basically, are we looking at a seconf layer to hold
> HTML (or children?)?
> Or would we simply cause the re-rendering of child
> layers from the children
> array?

Yes. A layer (not a DynLayer) will be used to store
the HTML content. In DOM browsers I was looking at
using a <table> object, but I think I might use a
<div>. And for NS4 I'll use a <layer>

I'm also looking at adding a two new features to the
dynapi.document object. These are as follows:

dynapi.document.writeln(html,key) and
dynapi.document.deleteln(key)

These will allow a user to write/append html content
to the document even after the page has been loaded.
The deleteln(key) will also the user to delete html
content from the document once the page is loaded. 

These two new functions will enable us to dynamically
download (inline) portions of a huge app, append the
content to the document and then create the object use
blueprint/inline create features.

What do you all thing?

--
Raymond Irving
> Note: that if we are talking re-rendering the layers
> you will run *SMACK*
> into the netscape 4.x
> memory leak.
> ----- Original Message -----
> From: "Raymond Irving" <xw...@ya...>
> To: "DynAPI-Dev" <dyn...@li...>
> Sent: Wednesday, March 26, 2003 6:23 AM
> Subject: [Dynapi-Dev] New BlackBoard concept for
> DynAPI 3.0
> 
> 
> > Hello everyone,
> >
> > Sometime ago some of our users had a problem with
> > setHTML(). Whenever setHTML() was called after you
> > added a child layer it would erase the child and
> > overwrite the html content.
> >
> > The BlackBoard approach:
> >
> > lyr.setBlackBoard(b,x,y);
> >
> > Once the blackBoard is setup (before the layer is
> > created) you can then call setHTML() and if will
> not
> > erase the child layers but overwrite the html
> content.
> > This will make it easier for us to create things
> like
> > the button widget:
> >
> > lyr.setBlackBoard(true);
> > lyr.addChild(new DynLayer(),'_lyrCover');
> > dynapi.document.addChild(lyr);
> > lyr.setHTML('Click Here');
> >
>
lyr._lyrCover.setAnchor({left:0,top:0,stretchH:'100%',stretchV:'100%'});
> > ....
> > lyr.setHTML('Ok');
> >
> > Any comments?
> >
> > --
> > 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:
> > 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 BlackBoard concept for DynAPI 3.0

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

Please see my comments below:

--- Kevin <ke...@ke...> wrote:
> Please see my comments below:
> 
> > Raymond Irving <xw...@ya...> wrote:
> > Hello everyone,
> > 
> > Sometime ago some of our users had a problem with
> > setHTML(). Whenever setHTML() was called after you
> > added a child layer it would erase the child and
> > overwrite the html content.
> 
> Yes I was thinking of setHTML(html,true) adding true
> would getInnerHTML().
>  
> > The BlackBoard approach:
> > 
> > lyr.setBlackBoard(b,x,y);
> 
> Is the blackboard a cache of all nested HTML so what
> do x,y relate to? 

The x,y arguments will allow the user to change the
location of it's blackboard. By default the blackboard
will be set to location 0,0

--
Raymond Irving 
  
> > Once the blackBoard is setup (before the layer is
> > created) you can then call setHTML() and if will
> not
> > erase the child layers but overwrite the html
> content.
> > This will make it easier for us to create things
> like
> > the button widget:
> > 
> > lyr.setBlackBoard(true);
> > lyr.addChild(new DynLayer(),'_lyrCover');
> > dynapi.document.addChild(lyr);
> > lyr.setHTML('Click Here');
> >
>
lyr._lyrCover.setAnchor({left:0,top:0,stretchH:'100%',stretchV:'100%'});
> > ....
> > lyr.setHTML('Ok');
> > 
> > Any comments?
> 
> I quite like this idea.
> 
> Kevin.
> 
> 
> > --
> > Raymond Irving
> > 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] FocusManager Online Demo

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

--- Kevin <ke...@ke...> wrote:
> Very good. Is the addition of a border onfocus
> optional?

Yes, the onfocus/onblur events are optional (user
defined)

--
Raymond Irving

> I'll grab a copy form CVS later.
> -----
> Kevin.
> 
> > Hello Everyone,
> > 
> > Here's an online demo of the FocusManager:
> > 
> >
>
http://www24.brinkster.com/dyntools/next/examples/dynapi.gui.focusmanager.html
> > 
> > 
> > PS. You can find the files inside cvs
> > 
> > --
> > Raymond Irving
> >
> > 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] FocusManager Online Demo

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

Very good. Is the addition of a border onfocus optional?
I'll grab a copy form CVS later.
-----
Kevin.

> Hello Everyone,
> 
> Here's an online demo of the FocusManager:
> 
> http://www24.brinkster.com/dyntools/next/examples/dynapi.gui.focusmanager.html
> 
> 
> PS. You can find the files inside cvs
> 
> --
> Raymond Irving
>
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../

Re: [Dynapi-Dev] GUI component standard.

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

See below:

> > Here are some things I would like to see addressed
> > as far as a GUI component standard.
> >
> > Defaults: All arguments for all components should
> > have default values. This way a user can pass as
> > many or as few values as they choose and not have
> > the component fail.
>
> How would this be done?

function myObject(arg1,arg2,arg3){
    this.var1 = arg1||null;
    this.var2 = arg2||0;
    this.var3 = arg3||"#999999";
}

You test for null. if the argument waxs not passed you assignt he 'default'
value.
If you look into the scrollbar you will notice that autoknob is on by
default (if you do not pass that value)
You will notice also that the backcolor and forcolor are set by default to
appear "windows-like"
if you do not explicitly pass colors..

>
> > Colors: shuould we define the default color scemes
> > to be used with any GUI component so as to have some
> > sort
> > of comon look and feel?
>
> Yes. Something like: foreColor, backColor, Highlight,
> Shadow, outline, textColor, selectColor, etc.
>
> > Parameters: (and I am guilty of this myself) some
> > parameters, such as the background and foground
> > colors of
> > a component are not always accessable as methods.
> > (for instance, the FG color of the scrollbar)
> > Should we insist (in our standard) that any passed
> > parameter can also be set and read after rendering
> > the component? I.E. myScroll.setButtonColor()
> > myScroll.getButtonColor()
> >
> > Fonts: back to a common look-and-feel. If we want a
> > common look-and-feel to our gui comonents when used
> > in default mode, we should include default font
> > family, font size, font color, ect. (maybe with a
> > css sheet..)
>
> Default font-family and font-size. Font-color should
> go inside the color section.
>
> > What else am I missing? Let's here it.
> >
> > A side note:
> > I know I can be loud obnoxious an agressive, but I
> > do this with the best of intentions.
> > I see here (again) an oportunity to build something
> > great, and sometimes I get a little over-excited
> > about that.
> > I also sometimes take things personally. That's
> > simply my nature.
>
> :)
>
> > You need to understand. I built the light scrollbar
> > as a light scrollbar because of the voiced concerns
> > over the 'heavyness ' of past widgets. I even stated
> > specifically that this is ment as a light component
> > and that I would produce a more classical skinned
> > one as well. Yet when I released it, I get a three
> > page report on why my scrollbar sucks (that is
> > simply how it seemed to me until I had a chance to
> cool-off).
>
> lol - It's always good to get feedback from others.
> This way we can improve on what we have.
>
>
> --
> 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:
> 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 BlackBoard concept for DynAPI 3.0

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

I like very much.
Should it be an extension?
I think it would be best as a native functionality (imho)
Basically, are we looking at a seconf layer to hold HTML (or children?)?
Or would we simply cause the re-rendering of child layers from the children
array?

Note: that if we are talking re-rendering the layers you will run *SMACK*
into the netscape 4.x
memory leak.
----- Original Message -----
From: "Raymond Irving" <xw...@ya...>
To: "DynAPI-Dev" <dyn...@li...>
Sent: Wednesday, March 26, 2003 6:23 AM
Subject: [Dynapi-Dev] New BlackBoard concept for DynAPI 3.0


> Hello everyone,
>
> Sometime ago some of our users had a problem with
> setHTML(). Whenever setHTML() was called after you
> added a child layer it would erase the child and
> overwrite the html content.
>
> The BlackBoard approach:
>
> lyr.setBlackBoard(b,x,y);
>
> Once the blackBoard is setup (before the layer is
> created) you can then call setHTML() and if will not
> erase the child layers but overwrite the html content.
> This will make it easier for us to create things like
> the button widget:
>
> lyr.setBlackBoard(true);
> lyr.addChild(new DynLayer(),'_lyrCover');
> dynapi.document.addChild(lyr);
> lyr.setHTML('Click Here');
> lyr._lyrCover.setAnchor({left:0,top:0,stretchH:'100%',stretchV:'100%'});
> ....
> lyr.setHTML('Ok');
>
> Any comments?
>
> --
> 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:
> 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] GUI component standard.

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

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

> Here are some things I would like to see addressed as far as a GUI=20
> component standard.
> =A0
> Defaults: All arguments for all components should have default values.=20=

> This way a user can pass as many or as few values as they choose and=20=

> not have the component fail.
I agree. The defaults should be so that the component still looks like=20=

what it should, even if that's not how the user want it, but then, a=20
user will right away understand that it needs to be configured a little=20=

more, compare to a first impression where, because an argument is=20
missing, the thing is completly screwed up, which is really=20
discouraging.

> =A0
> Colors: shuould we define the default color scemes to be used with any=20=

> GUI component so as to have some sort
> of comon look and feel?
I guess we should.

> =A0
> Parameters: (and I am guilty of this myself) some parameters, such as=20=

> the background and foground colors of
> a component are not always accessable as methods. (for instance, the=20=

> FG color of the scrollbar)
> Should we insist (in our standard) that any passed parameter can also=20=

> be set and read after rendering the component? I.E.=20
> myScroll.setButtonColor() myScroll.getButtonColor()
I agree we should.

> =A0
> Fonts: back to a common look-and-feel. If we want a common=20
> look-and-feel to our gui comonents when used in default mode, we=20
> should include default font family, font size, font color, ect. (maybe=20=

> with a css sheet..)
This reminds me that Raymond has almost done a DynCSSStyle :-) So, if=20
we had this beats, it would be very handy to use for skinning. After=20
all a style definition defines location, size, colors and fonts ! We=20
would get as well to change the style of multiple layers in one=20
operation !
> =A0
> What else am I missing? Let's here it.
> =A0
> A side note:
> I know I can be loud obnoxious an agressive, but I do this with the=20
> best of intentions.
> I see here (again) an oportunity to build something great, and=20
> sometimes I get a little over-excited about that.
> I also sometimes take things personally. That's simply my nature.
> =A0
> You need to understand. I built the light scrollbar as a light=20
> scrollbar because of the voiced concerns over the 'heavyness ' of past=20=

> widgets. I even stated specifically that this is ment as a light=20
> component and that I would produce a more classical skinned one as=20
> well. Yet when I released it, I get a three page report on why my=20
> scrollbar sucks (that is simply how it seemed to me until I had a=20
> chance to cool-off).
I'm glad you realized it wasn't meant this way. At all. I'm usually=20
pushing the envelope. I was really happy about your scroller, first of=20=

all because it's proportional, the one I'm using right now isn't ! And=20=

my comments were made in a constructive spirit. My writing may not have=20=

conveyed it enough !

Thanks,

Benoit

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
>

Re: [Dynapi-Dev] GUI component standard.

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

--- Doug Melvin <do...@cr...> wrote:
> Here are some things I would like to see addressed
> as far as a GUI component standard.
> 
> Defaults: All arguments for all components should
> have default values. This way a user can pass as
> many or as few values as they choose and not have
> the component fail.

How would this be done?

> Colors: shuould we define the default color scemes
> to be used with any GUI component so as to have some
> sort
> of comon look and feel?

Yes. Something like: foreColor, backColor, Highlight,
Shadow, outline, textColor, selectColor, etc.

> Parameters: (and I am guilty of this myself) some
> parameters, such as the background and foground
> colors of
> a component are not always accessable as methods.
> (for instance, the FG color of the scrollbar)
> Should we insist (in our standard) that any passed
> parameter can also be set and read after rendering
> the component? I.E. myScroll.setButtonColor()
> myScroll.getButtonColor()
> 
> Fonts: back to a common look-and-feel. If we want a
> common look-and-feel to our gui comonents when used
> in default mode, we should include default font
> family, font size, font color, ect. (maybe with a
> css sheet..)

Default font-family and font-size. Font-color should
go inside the color section.
 
> What else am I missing? Let's here it. 
> 
> A side note:
> I know I can be loud obnoxious an agressive, but I
> do this with the best of intentions.
> I see here (again) an oportunity to build something
> great, and sometimes I get a little over-excited
> about that.
> I also sometimes take things personally. That's
> simply my nature.

:)

> You need to understand. I built the light scrollbar
> as a light scrollbar because of the voiced concerns
> over the 'heavyness ' of past widgets. I even stated
> specifically that this is ment as a light component
> and that I would produce a more classical skinned
> one as well. Yet when I released it, I get a three
> page report on why my scrollbar sucks (that is
> simply how it seemed to me until I had a chance to
cool-off).

lol - It's always good to get feedback from others.
This way we can improve on what we have.


--
Raymond Irving

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

[Dynapi-Dev] New BlackBoard concept for DynAPI 3.0

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

Hello everyone,

Sometime ago some of our users had a problem with
setHTML(). Whenever setHTML() was called after you
added a child layer it would erase the child and
overwrite the html content.

The BlackBoard approach:

lyr.setBlackBoard(b,x,y);

Once the blackBoard is setup (before the layer is
created) you can then call setHTML() and if will not
erase the child layers but overwrite the html content.
This will make it easier for us to create things like
the button widget:

lyr.setBlackBoard(true);
lyr.addChild(new DynLayer(),'_lyrCover');
dynapi.document.addChild(lyr);
lyr.setHTML('Click Here');
lyr._lyrCover.setAnchor({left:0,top:0,stretchH:'100%',stretchV:'100%'});
....
lyr.setHTML('Ok');

Any comments?

--
Raymond Irving

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

[Dynapi-Dev] GUI component standard.

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

Here are some things I would like to see addressed as far as a GUI =
component standard.

Defaults: All arguments for all components should have default values. =
This way a user can pass as many or as few values as they choose and not =
have the component fail.

Colors: shuould we define the default color scemes to be used with any =
GUI component so as to have some sort
of comon look and feel?

Parameters: (and I am guilty of this myself) some parameters, such as =
the background and foground colors of
a component are not always accessable as methods. (for instance, the FG =
color of the scrollbar)
Should we insist (in our standard) that any passed parameter can also be =
set and read after rendering the component? I.E. =
myScroll.setButtonColor() myScroll.getButtonColor()

Fonts: back to a common look-and-feel. If we want a common look-and-feel =
to our gui comonents when used in default mode, we should include =
default font family, font size, font color, ect. (maybe with a css =
sheet..)

What else am I missing? Let's here it.=20

A side note:
I know I can be loud obnoxious an agressive, but I do this with the best =
of intentions.
I see here (again) an oportunity to build something great, and sometimes =
I get a little over-excited about that.
I also sometimes take things personally. That's simply my nature.

You need to understand. I built the light scrollbar as a light scrollbar =
because of the voiced concerns over the 'heavyness ' of past widgets. I =
even stated specifically that this is ment as a light component and that =
I would produce a more classical skinned one as well. Yet when I =
released it, I get a three page report on why my scrollbar sucks (that =
is simply how it seemed to me until I had a chance to cool-off).

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

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

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

To get a windows look and feel would require images.
The whole reason I build the light one is that someone complained about the
use of images.


----- Original Message -----
From: "Raymond Irving" <xw...@ya...>
To: <dyn...@li...>
Sent: Tuesday, March 25, 2003 6:31 PM
Subject: Re: [Dynapi-Dev] Light widgets. (or "remember the user!")


>
> I too like the concept of using "very light weight
> widgets" for those web apps that don't need heavy duty
> widgets. But these widgets should still have a
> nice/standard appearance (e.g. windows 3.1 or window
> 95 look and feel). Functionality should also be
> standard.
>
> --
> Raymond Irving
>
> --- Doug Melvin <do...@cr...> wrote:
> > 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.
> > 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_
> > 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
> > 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?
> > I just figured sooner would be better.
> >
>
>
> __________________________________________________
> 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] FocusManager Online Demo

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

Hello Everyone,

Here's an online demo of the FocusManager:

http://www24.brinkster.com/dyntools/next/examples/dynapi.gui.focusmanager.html


PS. You can find the files inside cvs

--
Raymond Irving

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

[Dynapi-Dev] Latest Blueprint Test results

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

Hi,

Just thought you would like to now about my latest
Blueprint test result:

1000 layers loaded in 1032ms (1 sec)
5000 layers loaded in 11500ms (11 sec)

--
Raymond Irving


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

[Dynapi-Dev] [ dynapi-Patches-709834 ] New features/API & FX Improvements

[SourceForge.net <no...@so...>]

Patches item #709834, was opened at 2003-03-26 02:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305757&aid=709834&group_id=5757

Category: DynAPI 3 API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Irving (xwisdom)
Assigned to: Nobody/Anonymous (nobody)
Summary: New features/API & FX Improvements

Initial Comment:
[*] Update Examples
[+] Add FocusManager
[+] Add setDragMode(b,boundry)
[+] Add setMinimumSize(w,h) and setMaximumSize
(w,h), setOverflow(s) - default is hidden
[+] Add oncontentchange event - triggered by setHTML
[+] Add onresize and onlocationchange events
	> In most cases these will only be used by 
widget developers. The useR must use addEventListener 
in order to catch these events. The lyr.onresize=function
(){} will ONLY work if a previous event with onresize was 
added using addEventListener

[+] Add Preserve Data Type (pDType) to Cookie 
constructure - Cookie(name,pDType)
[+] Add Cookie.encode & Cookie.decode functions
	^ useful for storing simple and complex 
objects and datatype. 

[+] Add removeAll() function to cookie object
[*] Modify insertAllChildren(usebp,bpSrc) and insertChild
(c,usebp) to support blueprints.
	>usebp - use blueprint; bpSrc - blueprint 
SRC (.js file)

[+] Add generateBlueprint() to DynLayer Inline
[+] Add swiper animation class
[*] Modify DynEvent Object - DynEvent should not be a 
DynObject.    

PS. Changes are inside CVS

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305757&aid=709834&group_id=5757

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

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

I too like the concept of using "very light weight
widgets" for those web apps that don't need heavy duty
widgets. But these widgets should still have a
nice/standard appearance (e.g. windows 3.1 or window
95 look and feel). Functionality should also be
standard.

--
Raymond Irving 

--- Doug Melvin <do...@cr...> wrote:
> 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. 
> 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_ 
> 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 
> 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? 
> I just figured sooner would be better.
> 


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

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

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

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

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