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

Re[2]: [Dynapi-Dev] API3,alpha

[Robert R. <rra...@ya...>]

I've actually got some php code we can use at dynapi.sourceforge.net that allows
you to make comments on php pages.  So if people have drafts we can
post them on the dynapi site and allow people to comment.  I'm not a
big fan of added another message board since we already have these
lists, but I do see the need for some other time of communication
system.  By the way we could use the demo site we have up to post
ideas and allow people to comment as well.

-- 
// Robert Rainwater

On 2/20/2001, 4:57:05 PM EST, Doug wrote about "[Dynapi-Dev] API3,alpha":

> If anyone want's to help me finish my messagelist widget, or if this can wait a week,
> I will make a discussion board available at www.allthewhile.com.

> Messages are posted in real-time, and we would have real threads, which makes it easiers to fallow any particular topic
>   ----- Original Message ----- 
>   From: Raymond Smith 
>   To: dyn...@li... 
>   Sent: Tuesday, February 20, 2001 1:13 AM
>   Subject: [Dynapi-Dev] API3,alpha


>   I've been filtering thru and printing all non-duplicate threads so I can break down the input from all effectively.  I will probably produce a rough dicussion-brief divided into two key areas
> with subsections:

>   1) DynAPI issues still requiring focus.
>   2) DynAPI3alpha discussion brief which will include everyones inputs on "anything" topically related to the next-gen of this API.

>   I will most likely distill the first draft as a PDF file that I hope stays under the 40K limit, but eventually we are gonna need a more colaborative environment probably located at the DynAPI
> homepage.  Thoughts on web-based colaboration tool options would be appreciated.  Might actually be something right here at Source Forge.  

>   This tool should allow for draft inputs and notations to a more text based document with supplemental drawings and diagrams (knew I had a special purpose here), I don't think the standard CVS
> will serve in that roll.

>   Additionally, I think all thoses who would like to actively "be involved" in this "Planning Stage" should raise their hands now and express an interest, or throw a rock.  I recommend we develop a
> "start-team" of those interested to at least get us through the planning stages and to a presentable draft that can then be shared with everyone in a open forum.

>   All of the above is of course subject to administrative change, I am just trying to create a better environment for an open-source team effort and I truely think having a "plan" is the best first
> step here.


>   ---
>   Outgoing mail is certified Virus Free by AVG Free Edition
>   Download at: http://www.grisoft.com/html/us_index.cfm
>   Checked by AVG anti-virus system (http://www.grisoft.com).
>   Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01


----------------------
DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
DynAPI Homepage: http://dynapi.sourceforge.net/

Re: [Dynapi-Dev] API3,alpha

[Jordi - I. - M. <jmi...@or...>]

We do have discussion forums at Sourceforge, and didn't prove to be any
lively in the past.

Doug Melvin wrote:

> If anyone want's to help me finish my messagelist widget, or if this
> can wait a week,I will make a discussion board available at
> www.allthewhile.com. Messages are posted in real-time, and we would
> have real threads, which makes it easiers to fallow any particular
> topic
>
>      ----- Original Message -----
>      From: Raymond Smith
>      To: dyn...@li...
>      Sent: Tuesday, February 20, 2001 1:13 AM
>      Subject: [Dynapi-Dev] API3,alpha
>       I've been filtering thru and printing all non-duplicate
>      threads so I can break down the input from all effectively.
>      I will probably produce a rough dicussion-brief divided into
>      two key areas with subsections: 1) DynAPI issues still
>      requiring focus.2) DynAPI3alpha discussion brief which will
>      include everyones inputs on "anything" topically related to
>      the next-gen of this API. I will most likely distill the
>      first draft as a PDF file that I hope stays under the 40K
>      limit, but eventually we are gonna need a more colaborative
>      environment probably located at the DynAPI homepage.
>      Thoughts on web-based colaboration tool options would be
>      appreciated.  Might actually be something right here at
>      Source Forge. This tool should allow for draft inputs and
>      notations to a more text based document with supplemental
>      drawings and diagrams (knew I had a special purpose here), I
>      don't think the standard CVS will serve in that
>      roll. Additionally, I think all thoses who would like to
>      actively "be involved" in this "Planning Stage" should raise
>      their hands now and express an interest, or throw a rock.  I
>      recommend we develop a "start-team" of those interested to
>      at least get us through the planning stages and to a
>      presentable draft that can then be shared with everyone in a
>      open forum. All of the above is of course subject to
>      administrative change, I am just trying to create a better
>      environment for an open-source team effort and I truely
>      think having a "plan" is the best first step here.
>      ---
>      Outgoing mail is certified Virus Free by AVG Free Edition
>      Download at: http://www.grisoft.com/html/us_index.cfm
>      Checked by AVG anti-virus system (http://www.grisoft.com).
>      Version: 6.0.231 / Virus Database: 112 - Release Date:
>      2/12/01
>

Re: [Dynapi-Dev] getParent()

[Jordi - I. - M. <jmi...@or...>]

Absolutely. When I talk 'rewriting things' I'm not saying we should rebuild the
code but rewrite what we already have. Now we know all the "ifs" that are goiung
to be there, so we can organize the internal code in a better way.

Pascal Bestebroer wrote:

> duh!  (sorry, just being annoying again :)
> not all optimisation is for speed!
> adding stuff to the DynLayer object will make larger memory foot prints, and
> in most cases it's unneeded.
>
> Adding these convenience methods was a nice idea at first.. but they are all
> adding up to the memory footprint of a single DynLayer.
> Something "we" should also take under consideration, not just your speed
> issues.
>
> But getting back on that subject again, I've been doing some optimising to
> the DynLayer, and got it down from 42 secs to 34secs with 500 layers (on a
> 600mhz machine).. for now only did this on Dynacore, but most stuff can be
> done on the official as well.
>
> I'm still no fan of your canvas ideas, it would require all users to change
> there code that is using DynAPI now! In my opinion once you have all
> dynlayer functionality in, your canvas will be slower then it is now
> (regardless of your addchild ideas) and might actually get as slow as
> dynlayer (Seeing that most code is still the same).
>
> Also, you keep mentioning that the  object  passing between methods is
> what's slowing down stuff.. then how are you going to add a child to the
> parent? aren't you passing the parent object then?
>
> If you would compare the speed of this current DynLayer with the one we had
> a year ago, you would also see big speed differences.. but eventually you
> need extra functionality and this is the fault with the current dynapi: it
> needs a big clean-up, not a complete change in code and usage. Everything
> got pasted onto it, without doing any optimising.. in the createelement
> there are a few if (is.xx) statements, that can be combined into one, and
> more of these optimisations.
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens Eytan Heidingsfeld
> > Verzonden: dinsdag 20 februari 2001 16:54
> > Aan: dyn...@li...
> > Onderwerp: RE: [Dynapi-Dev] getParent()
> >
> >
> > That is not what slows down the creation of layers.
> > It's the problem with the addChild chain that I told you. I can make the
> > Canvas have all these methods if you like and the time will be about the
> > same.
> > 8an
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

RE: [Dynapi-Dev] Freeing Memory

[Pascal B. <pa...@dy...>]

so on a url change everything is freed?

couldn't we then check for a on window close or window blur event? (not sure
if these are available).. in that case we could do a fast url change or
something (again, not sure if that's possible)

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Eytan Heidingsfeld
> Verzonden: dinsdag 20 februari 2001 20:18
> Aan: Dynapi-Dev
> Onderwerp: [Dynapi-Dev] Freeing Memory
>
>
> Since IE is way more popular I started with it. I was wrong with my
> assumption that nullifying objects (not even talking about html
> elements(layers)) does the whole thing. Let me tell you what I discovered:
> if you create 10000 small object and then nullify them nothing happens but
> when you recreate them still the memory stays stable. I want to
> test replace
> "= null" with "= [];" maybe that will help.
> Identified positive freeing of memory when changing url. Now you all may
> say: "so what this sux we can't force them to change url!!" it might be ok
> if we design such a system(this design fits well with the talks
> about a new
> API"
> We create a framed page
> one called RAM and one regular one where you place your project.
> In the RAM page there is a method called createObject which does the
> following:
> * takes the type of object expected
> * adds a new object of that type to an array called mem
> * returns the index
> then on the regular page we say
> i = createObject(DynLayer);
> myDynLayer = parent.frames[0].mem[i];
> (there will be a shortcut to parent.frames[0]).
>
> Then when we want to free mem we pass the mem array to the main
> frame change
> the url to an empty page and reassign the mem array.
>
> Not even sure if this system works. Gonna try it now anyone else
> got ideas?
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

[Dynapi-Dev] dynapi latest release - BIGGER speed issues

[Pascal B. <pa...@dy...>]

It seems the latest release of dynapi is ALOT slower then previous onces.

Not sure what causes this, but my guess would be the static methods.. not
sure if they we're also in the previous releases.. but it seems to me that
since these methods won't be part of the DynLAyer objects them selves,
calling an extra function is slower then using the this.method() way of
reaching it.



Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

[Dynapi-Dev] Freeing Memory

[Eytan H. <ey...@tr...>]

Since IE is way more popular I started with it. I was wrong with my
assumption that nullifying objects (not even talking about html
elements(layers)) does the whole thing. Let me tell you what I discovered:
if you create 10000 small object and then nullify them nothing happens but
when you recreate them still the memory stays stable. I want to test replace
"= null" with "= [];" maybe that will help.
Identified positive freeing of memory when changing url. Now you all may
say: "so what this sux we can't force them to change url!!" it might be ok
if we design such a system(this design fits well with the talks about a new
API"
We create a framed page
one called RAM and one regular one where you place your project.
In the RAM page there is a method called createObject which does the
following:
* takes the type of object expected
* adds a new object of that type to an array called mem
* returns the index
then on the regular page we say
i = createObject(DynLayer);
myDynLayer = parent.frames[0].mem[i];
(there will be a shortcut to parent.frames[0]).

Then when we want to free mem we pass the mem array to the main frame change
the url to an empty page and reassign the mem array.

Not even sure if this system works. Gonna try it now anyone else got ideas?

8an

RE: [Dynapi-Dev] API3,alpha

[Pascal B. <pa...@dy...>]

uhm.. sourceforge has excellent forums.. but we closed them in favour of
this mailing list.

just butting in again
Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

  -----Oorspronkelijk bericht-----
  Van: dyn...@li...
[mailto:dyn...@li...]Namens Doug Melvin
  Verzonden: dinsdag 20 februari 2001 22:57
  Aan: dyn...@li...
  Onderwerp: Re: [Dynapi-Dev] API3,alpha


  If anyone want's to help me finish my messagelist widget, or if this can
wait a week,
  I will make a discussion board available at www.allthewhile.com.

  Messages are posted in real-time, and we would have real threads, which
makes it easiers to fallow any particular topic
    ----- Original Message -----
    From: Raymond Smith
    To: dyn...@li...
    Sent: Tuesday, February 20, 2001 1:13 AM
    Subject: [Dynapi-Dev] API3,alpha


    I've been filtering thru and printing all non-duplicate threads so I can
break down the input from all effectively.  I will probably produce a rough
dicussion-brief divided into two key areas with subsections:

    1) DynAPI issues still requiring focus.
    2) DynAPI3alpha discussion brief which will include everyones inputs on
"anything" topically related to the next-gen of this API.

    I will most likely distill the first draft as a PDF file that I hope
stays under the 40K limit, but eventually we are gonna need a more
colaborative environment probably located at the DynAPI homepage.  Thoughts
on web-based colaboration tool options would be appreciated.  Might actually
be something right here at Source Forge.

    This tool should allow for draft inputs and notations to a more text
based document with supplemental drawings and diagrams (knew I had a special
purpose here), I don't think the standard CVS will serve in that roll.

    Additionally, I think all thoses who would like to actively "be
involved" in this "Planning Stage" should raise their hands now and express
an interest, or throw a rock.  I recommend we develop a "start-team" of
those interested to at least get us through the planning stages and to a
presentable draft that can then be shared with everyone in a open forum.

    All of the above is of course subject to administrative change, I am
just trying to create a better environment for an open-source team effort
and I truely think having a "plan" is the best first step here.


    ---
    Outgoing mail is certified Virus Free by AVG Free Edition
    Download at: http://www.grisoft.com/html/us_index.cfm
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

RE: [Dynapi-Dev] getParent()(Should be throwing rocks at 8an)

[Pascal B. <pa...@dy...>]

(First: sorry people for this long post.. but this is fun isn't it :)

Here's the new createElement of my Dynacore code, I removed all
functionality not available in your code, and then used the timing test you
posted a few days ago..

I personally don't believe in these tests  (running it a few times will give
different numbers.. so browsers are not very stable on handling stuff) but
please run the test your self (not sure if the code below works in current
dynapi). I used a test with 500 layers.. your code 2100ms, my code 1980ms..
so I'd say we break even.

As you can see I had to take out ALOT of functionality not available in your
code (recycle array, setting up the images for event triggering, invoking
events on all child layers, setting bgimage + fixing the IE5.5 event bug,
the getContentWidth/height checks and calls)

Also I took another look at your nested test.. that's not valid. When people
use the code (or widgets) usually the child layers are added to the parent
layer, BEFORE the parent layer is added to the document (created). This is
the beauty and power of the precreation.. all those child layers will then
not be created but written into the parent (skipping ALOT of overhead by not
having to call the createelement and having to be inserted into the
document, or have every CSS style be set seperatly)


I think your code could also do with a little optimisation (seeing that your
using the dynapi code for a large part) but I don't think the differences in
speed (between dynlayer and canvase) would be that big.. once I get this
optimising round done and checked, I'll try to work these things into the
official DynAPI.

I AM very interested in any documents to back up your ideas about how the
objects are passed..but for now you still don't have me convinced there's a
noticeable difference to be gained ;-)


If you want I can post the current Dynacore "snapshot", but here's my
current createElement code (people this is NOT a patch)

DynLayer.prototype.createElement=function() {
//	if (this.created||!this.parent||this.elm!=null) return
	if (this.parent.isDocument) this.dyndoc=this.parent
    	else this.dyndoc=this.parent.dyndoc

	if (is.ns4) {
//		var recycled=this.parent.doc.recycled
//		if (recycled && recycled.length>0) {
//	        	this.elm=recycled[0]
//			DynAPI.removeFromArray(recycled,recycled[0])
//		} else {
			this.elm=new Layer(this.w,this.parent.elm)
			this.elm.captureEvents(Event.LOAD)
			this.elm.onload=function() {}
//		}
		this.css=elm
		this.doc=elm.document
		this.doc.lyrobj=this
//		for (i in this.doc.images) this.doc.images[i].lyrobj=this
	} else var
parentElement=(this.parent.isLayer)?this.parent.elm:this.parent.doc.body
	if (is.ie4) {
		var code='<DIV id="'+this.id+'" style="position:absolute; left:0px;
top:0px; width:'+this.w+'px;"></DIV>'
		parentElement.insertAdjacentHTML("beforeEnd", code)
		this.elm=parentElement.children[parentElement.children.length-1]
		this.css=this.elm.style
		this.doc=this.parent.doc
//		for (i in this.elm.all.tags("img"))
this.elm.all.tags("img")[i].lyrobj=this
	} else if (is.ie5 || is.ns5) {
		parentElement.appendChild(this.elm=this.dyndoc.doc.createElement("DIV"))
		this.elm.style.position="absolute"
		this.elm.id=this.id
		this.css=this.elm.style
		this.doc=this.parent.doc
//		if (is.ns5) for (i in this.doc.images)
this.doc.images[i].lyrobj=this.elm
//		if (is.ie5) for (i in this.elm.all.tags("img"))
this.elm.all.tags("img")[i].lyrobj=this
	}
	this.elm.lyrobj=this

//	for (var i=0; i<this.children.length; i++)
this.children[i].invokeEvent('precreate')
//	this.invokeEvent('precreate')

	this.setSize(this.w,this.h,false)
	if (is.ns4) {
		this.elm.moveTo(this.x,this.y)
		this.doc.write(this.getInnerHTML())
		this.doc.close()
	} else {
		this.css.left=this.x
		this.css.top=this.y
		this.setHTML(this.html) //this.getInnerHTML())
	}
	if (this.bgColor!=null) this.setBgColor(this.bgColor)
//	if (this.bgImage!=null) this.setBgImage(this.bgImage)
//	else if (is.ie55 && this.html==null) this.setBgImage('javascript:null')
//	if (this.clip!=null) this.setClip(this.clip)

//	this.css.zIndex=this.z
	this.css.visibility=this.visible? "inherit" : (is.ns4?"hide":"hidden")

//	this.assignChildren()

//	if (this.html!=null) {
//		if (this.w==null && this.getContentWidth()>0)
this.setWidth(this.getContentWidth(), false)
//		if (this.h==null && this.getContentHeight()>0)
this.setHeight(this.getContentHeight(), false)
//	}

//	if (this.hasEventListeners) {
		this.captureMouseEvents()
//		var elm=this.elm
//		if (is.ns4) elm.captureEvents(Event.MOUSEDOWN | Event.MOUSEUP |
Event.CLICK | Event.DBLCLICK)
//
elm.onmousemove=elm.onmousedown=elm.onmouseup=elm.onmouseover=elm.onmouseout
=elm.onclick=elm.ondblclick=DynObject.prototype.EventMethod
//		if (is.ie5) elm.oncontextmenu=function(){return false}
//	}

//	this.created=true
//	this.invokeEvent("resize")
//	this.invokeEvent('create')
}


Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

RE: [Dynapi-Dev] Dynamic Loading.

[Darin K. <dka...@ef...>]

say fellas, how do i unsubscribe from the list?

-----Original Message-----
From: Doug Melvin [mailto:do...@cr...]
Sent: Tuesday, February 20, 2001 2:01 PM
To: dyn...@li...
Subject: Re: [Dynapi-Dev] Dynamic Loading.


and what site would that be?
----- Original Message -----
From: "francesco AGATI" <fa...@we...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 4:55 AM
Subject: Re: [Dynapi-Dev] Dynamic Loading.


> HI,
>
> see this site for alterative loading dynamic data
>
> work only for IE5+,NS6,Mozzilla, not IE mac, not NS4
>
> ----- Original Message -----
> From: "Nuno Ferreira" <nun...@wi...>
> To: <dyn...@li...>
> Sent: Tuesday, February 20, 2001 12:20 PM
> Subject: RE: [Dynapi-Dev] Dynamic Loading.
>
>
> >
> > >I loath the limited realm that FLASH delivers along with its
> > >pathetic CPU chewing rendering engine.  I like the fact that the DynAPI
> > >leaves options 100% open for me to pick and choose front-to-back
delivery
> > >platforms.
> >
> > I agree, though as it stands, DynAPI chews more CPU time than the
average
> > flash
> > movie, let alone IE memory leaks.
> >
> > >Currently loadpanel is probably the weakest link supporting the DynAPI
> > >platform.  But it is the "only" link we currently have to bridge
between
> > two
> > >very different worlds.  Fix and optimize it....,
> >
> > Hmmm, I think that setHTML is the way to go, not loadpanel.
> > Using PHP, for instance, you can load a PHP file in a hidden frame, that
> > accesses
> > a database and builds a script on that hidden page that alters the layer
> > content
> > on the main page via setHTML. In practice, if you organize things
> > thouroughly, you
> > won't have to reload the main page ever.
> >
> > best,
> >
> > NunoF
> >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Re: [Dynapi-Dev] DynAPI Licensing Agreement (& request)

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

And a good thought at that.
----- Original Message -----
From: "Ken Ono" <ko...@an...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 5:34 AM
Subject: Re: [Dynapi-Dev] DynAPI Licensing Agreement (& request)


> My take on it is that you can certainly use it in that situation.  If you
> change dynapi, you must make those changes available.  You must also give
> credit to it and provide the license agreement.
>
> Request: perhaps someone can build a "powered by dynapi" page that web
site
> developers can simply load into a web site that uses dyn api.   This would
> make it easy for dynapi users as they could just include the page in order
> to be compliant.  It is also a good way to "market" dyn api.
>
> Just a thought...
>
> Ken
>
>
> ------------------------>
>
>
> Chris Lemon Wrote:
>
> Hi,
>
> I am developing a web app using DynAPI for use on a customers web site.
> Having read the license agreement I am very confused.  Can someone clarify
> the situation?  Does the agreement cover my situation.
>
> Thanks.
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Dynamic Loading.

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

and what site would that be?
----- Original Message -----
From: "francesco AGATI" <fa...@we...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 4:55 AM
Subject: Re: [Dynapi-Dev] Dynamic Loading.


> HI,
>
> see this site for alterative loading dynamic data
>
> work only for IE5+,NS6,Mozzilla, not IE mac, not NS4
>
> ----- Original Message -----
> From: "Nuno Ferreira" <nun...@wi...>
> To: <dyn...@li...>
> Sent: Tuesday, February 20, 2001 12:20 PM
> Subject: RE: [Dynapi-Dev] Dynamic Loading.
>
>
> >
> > >I loath the limited realm that FLASH delivers along with its
> > >pathetic CPU chewing rendering engine.  I like the fact that the DynAPI
> > >leaves options 100% open for me to pick and choose front-to-back
delivery
> > >platforms.
> >
> > I agree, though as it stands, DynAPI chews more CPU time than the
average
> > flash
> > movie, let alone IE memory leaks.
> >
> > >Currently loadpanel is probably the weakest link supporting the DynAPI
> > >platform.  But it is the "only" link we currently have to bridge
between
> > two
> > >very different worlds.  Fix and optimize it....,
> >
> > Hmmm, I think that setHTML is the way to go, not loadpanel.
> > Using PHP, for instance, you can load a PHP file in a hidden frame, that
> > accesses
> > a database and builds a script on that hidden page that alters the layer
> > content
> > on the main page via setHTML. In practice, if you organize things
> > thouroughly, you
> > won't have to reload the main page ever.
> >
> > best,
> >
> > NunoF
> >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] API3,alpha

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

If anyone want's to help me finish my messagelist widget, or if this can =
wait a week,
I will make a discussion board available at www.allthewhile.com.

Messages are posted in real-time, and we would have real threads, which =
makes it easiers to fallow any particular topic
  ----- Original Message -----=20
  From: Raymond Smith=20
  To: dyn...@li...=20
  Sent: Tuesday, February 20, 2001 1:13 AM
  Subject: [Dynapi-Dev] API3,alpha


  I've been filtering thru and printing all non-duplicate threads so I =
can break down the input from all effectively.  I will probably produce =
a rough dicussion-brief divided into two key areas with subsections:

  1) DynAPI issues still requiring focus.
  2) DynAPI3alpha discussion brief which will include everyones inputs =
on "anything" topically related to the next-gen of this API.

  I will most likely distill the first draft as a PDF file that I hope =
stays under the 40K limit, but eventually we are gonna need a more =
colaborative environment probably located at the DynAPI homepage.  =
Thoughts on web-based colaboration tool options would be appreciated.  =
Might actually be something right here at Source Forge. =20

  This tool should allow for draft inputs and notations to a more text =
based document with supplemental drawings and diagrams (knew I had a =
special purpose here), I don't think the standard CVS will serve in that =
roll.

  Additionally, I think all thoses who would like to actively "be =
involved" in this "Planning Stage" should raise their hands now and =
express an interest, or throw a rock.  I recommend we develop a =
"start-team" of those interested to at least get us through the planning =
stages and to a presentable draft that can then be shared with everyone =
in a open forum.

  All of the above is of course subject to administrative change, I am =
just trying to create a better environment for an open-source team =
effort and I truely think having a "plan" is the best first step here.


  ---
  Outgoing mail is certified Virus Free by AVG Free Edition
  Download at: http://www.grisoft.com/html/us_index.cfm
  Checked by AVG anti-virus system (http://www.grisoft.com).
  Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] DynAPI 2 Scroll - update # 6

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

will do.
  ----- Original Message -----=20
  From: Pascal=20
  To: dyn...@li...=20
  Sent: Monday, February 19, 2001 11:51 PM
  Subject: RE: [Dynapi-Dev] DynAPI 2 Scroll - update # 6


  complain mode:   please use the widgetlist for this.. scroll is still =
a widget :)

  Pascal Bestebroer (pb...@oi...)
  Software ontwikkelaar
  Oberon Informatiesystemen b.v.
  http://www.oibv.com=20

    -----Oorspronkelijk bericht-----
    Van: dyn...@li... =
[mailto:dyn...@li...]Namens Doug Melvin
    Verzonden: dinsdag 20 februari 2001 9:28
    Aan: dyn...@li...
    Onderwerp: [Dynapi-Dev] DynAPI 2 Scroll - update # 6


    Nothing major.
    Just fixed it so that, if auto knob sizing is enabled,
    and there is NO scrol move ment (layer is same size as scroll bar)
    then the scroll bars will appear disabled, much like in IE.

    See it to understand..
    I'm very tired right now and probably not making too much sense.

    :-)

    http://206.75.45.190/myscroll.htm



    ---
    Outgoing mail is certified Virus Free by AVG Free Edition
    Download at: http://www.grisoft.com/html/us_index.cfm
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01


    ---
    Outgoing mail is certified Virus Free by AVG Free Edition
    Download at: http://www.grisoft.com/html/us_index.cfm
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

RE: [Dynapi-Dev] getParent()(Should be throwing rocks at 8an)

[Eytan H. <ey...@tr...>]

Pascal,
A few issues:
1. Memory footprints of the actual objects (DynLayer) and not the elements
should be able to be released (gotta check that out).
2. Backwards compatibility is the word (or phrase). We add a method (listed
as deprecated) called addChild which sets the child's parent to self and
creates it something like this:
DynLayer.prototype.addChild = function(chld){
   chld.owner = this;
   chld.create();
}
That's all you need!!
3. First of all about if statements they take no time (basically) they are
not what is slowing you down. I will explain the difference between my
passing of objects and yours. Since JS has no pointers JS automatically
manages them. That means that an object is created once and then can be
passed but is passed as a pointer (anyone have tech stuff about this??).
What I do is as such
new Canvas(owner)
this.owner = owner;

JS interprets this as such:
1. Take pointer of owner
2. Replace the pointer of this.owner to the pointer of owner
3. Only once the object is passed and it is passed as a pointer. JS doesn't
need to call anything currently from this object just set up a pointer to
it.

DynLayer way:
new DynLayer()
addChild
Create element.
Pass DynLayer and Element to static function
Static function must take both objects and take the DynLayer as an object
and set up this.elm to point to Element

As you can see (here and in the tests) my way is more effective. It is also
logically more effective because each layer has his own responsibility to
create himself and doesn't have to delegate this responsibility to his
parent.

8an

RE: [Dynapi-Dev] getParent()

[Pascal B. <pa...@dy...>]

duh!  (sorry, just being annoying again :)
not all optimisation is for speed!
adding stuff to the DynLayer object will make larger memory foot prints, and
in most cases it's unneeded.

Adding these convenience methods was a nice idea at first.. but they are all
adding up to the memory footprint of a single DynLayer.
Something "we" should also take under consideration, not just your speed
issues.

But getting back on that subject again, I've been doing some optimising to
the DynLayer, and got it down from 42 secs to 34secs with 500 layers (on a
600mhz machine).. for now only did this on Dynacore, but most stuff can be
done on the official as well.

I'm still no fan of your canvas ideas, it would require all users to change
there code that is using DynAPI now! In my opinion once you have all
dynlayer functionality in, your canvas will be slower then it is now
(regardless of your addchild ideas) and might actually get as slow as
dynlayer (Seeing that most code is still the same).

Also, you keep mentioning that the  object  passing between methods is
what's slowing down stuff.. then how are you going to add a child to the
parent? aren't you passing the parent object then?

If you would compare the speed of this current DynLayer with the one we had
a year ago, you would also see big speed differences.. but eventually you
need extra functionality and this is the fault with the current dynapi: it
needs a big clean-up, not a complete change in code and usage. Everything
got pasted onto it, without doing any optimising.. in the createelement
there are a few if (is.xx) statements, that can be combined into one, and
more of these optimisations.



Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Eytan Heidingsfeld
> Verzonden: dinsdag 20 februari 2001 16:54
> Aan: dyn...@li...
> Onderwerp: RE: [Dynapi-Dev] getParent()
>
>
> That is not what slows down the creation of layers.
> It's the problem with the addChild chain that I told you. I can make the
> Canvas have all these methods if you like and the time will be about the
> same.
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

[Dynapi-Dev] Netscape 4 question

[Richard E. <emb...@co...>]

This question regards only netscape 4 and the included html attachments are
only
meant for Netscape 4 browser viewing. The question is: why does using the
"new Layer()" constructor work (l1.html) while using the LAYER tag not
work (l2.html).
Using the LAYER tag creates a second window while using the Layer
constructor simply puts the layer in the existing window.

I'm trying to understand why in dylayer.js the Layer constructor is used
and not the LAYER tag.

Thanks.

Richard Emberson

RE: [Dynapi-Dev] getParent()

[Eytan H. <ey...@tr...>]

That is not what slows down the creation of layers.
It's the problem with the addChild chain that I told you. I can make the
Canvas have all these methods if you like and the time will be about the
same.
8an

RE: [Dynapi-Dev] getParent()

[Pascal <pb...@oi...>]

as far as I know those two methods are removed (they were hardly never used)

and seeing as the DynLayer is so "bloated" already I don't think adding
methods like this will aid in the optimisation of the DynLayer, and the
parent property also refers to the parent. (there are a few other methods
that should be possible to be removed, or atleast simplified).


Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Richard Bennett
> Verzonden: dinsdag 20 februari 2001 15:33
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] getParent()
>
>
> Isn't this
> myDynLayer.getParentComponent() ?
> myDynLayer.setParentComponent(blah) ?
>
> Cheers,
> Richard Bennett
>
> ma...@ri...
> www.richardinfo.com
> (Everything running on, and ported to the 19/12/2000 snapshot
> of DynAPI2)
> Find the DynAPI faq here:
> http://sourceforge.net/docman/display_doc.php?docid=656&group_id=5757
> Browse the mailinglist here:
> http://www.mail-archive.com/index.php3?hunt=dynapi
>
>
> ----- Original Message -----
> From: "Alex Chong" <c....@mu...>
> To: <dyn...@li...>
> Sent: Tuesday, February 27, 2001 9:55 AM
> Subject: [Dynapi-Dev] getParent()
>
>
> > Hi,
> >
> > Currently, the parent of a DynLayer is accessed using
> > myDynLayer.parent.  I suggest in future Dynapi release, instead of
> > accessing the parent directly, we use a getter function: i.e.
> > myDynLayer.getParent().
> >
> > This brings alot of convenience to the widget development.
> Sometimes, a
> > widget may want other to 'believe' that its parent is some
> other layer
> > instead of its real parent.
> >
> > Alex Chong
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > ____________________________________________________________
> > Get your free domain name and domain-based e-mail from
> > Namezero.com. New!  Namezero Plus domains now available.
> > Find out more at: http://www.namezero.com
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] Dynamic Loading.

[Nuno F. <nun...@wi...>]

How does it run?
Do you call it from Javascript? Or it's a normal Java Applet?


-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Michael
Pemberton
Sent: terca-feira, 20 de Fevereiro de 2001 12:52
To: dyn...@li...
Subject: Re: [Dynapi-Dev] Dynamic Loading.


this is basically what I have done with my url applet.  it loads the raw
source and
then evaluates what needs to be done.  I think it is better than writing a
lot of
repetative JS in a separate frame.

Nuno Ferreira wrote:

>         >I loath the limited realm that FLASH delivers along with its
>         >pathetic CPU chewing rendering engine.  I like the fact that the
DynAPI
>         >leaves options 100% open for me to pick and choose front-to-back
delivery
>         >platforms.
>
> I agree, though as it stands, DynAPI chews more CPU time than the average
> flash
> movie, let alone IE memory leaks.
>
>         >Currently loadpanel is probably the weakest link supporting the
DynAPI
>         >platform.  But it is the "only" link we currently have to bridge
between
> two
>         >very different worlds.  Fix and optimize it....,
>
> Hmmm, I think that setHTML is the way to go, not loadpanel.
> Using PHP, for instance, you can load a PHP file in a hidden frame, that
> accesses
> a database and builds a script on that hidden page that alters the layer
> content
> on the main page via setHTML. In practice, if you organize things
> thouroughly, you
> won't have to reload the main page ever.
>
> best,
>
> NunoF
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

--
Michael Pemberton
mp...@ph...
ICQ: 12107010

RE: [Dynapi-Dev] Solution for NS6 getContentHeight/Width

[Simon D. M. <di...@bi...>]

> I tried this widget and noticed your border settings were ordered top,
> bottom, left, right.
> It seems every other dynapi widget used top, right, bottom, left. I
> personally find it helpful to have most widgets work the same way,

the setPadding and setBorder methods work in the standard way [t,r,b,l],
it's only the test harness' interface that orders them differently

> otherwise liked the interface and documentation, along with the widget.

Thanks, any comment on the method of getting content size?

Dicon

> Simon Dicon Montford wrote:
> > 
> > Here's a solution for NS6 getContentHeight/Width:
> > get the dimensions of the inner child.
> > 
> > Well, it works for DynLayers with only one child which is all
> > that's needed for widgets such as Label.
> > 
> > I also found it better on IE5.
> > 
> > Maybe you could use it as a stop-gap (even call it
> > DynLayer.prototype.getOnlyChildHeight/Width).
> > 
> > Here's what I did with a version of Label I was working on:
> > 
> > Label.prototype.getContentWidth=function(){
> >         if(is.ie)return this.elm.children[0].clientWidth
> >         else if(is.ns4)return this.doc.width
> >         else if(is.ns5)return
> > 
> parseInt(getComputedStyle(this.elm.firstChild,0).getPropertyValue(
> "width"))
> > }
> > Label.prototype.getContentHeight=function(){
> >         if(is.ie)return this.elm.children[0].clientHeight
> >         else if(is.ns4)return this.doc.height
> >         else if(is.ns5)return
> > 
> parseInt(getComputedStyle(this.elm.firstChild,0).getPropertyValue(
"height"))
> > }
> > 
> > You can see it working with pre-precreate version of DynAPI on 
> the demos at:
> > 
> > http://www.montford.f2s.com/dynatrix_docs/tutorial/label.html
> > 
> > Tested on ns4.7, ie5 and ns6 for Windows.
> > 
> > I played briefly on ie4.5 for Mac and it seemed to size OK (although I
> > noticed that the text selection
> > didn't turn on and off).
> > 
> > Dicon
> > 
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Re: [Dynapi-Dev] XML and Us

[Richard E. <emb...@co...>]

look at Ecma-290 for how to document js components in XML.

Richard Emberson


Eytan Heidingsfeld wrote:

> Hi,While getting into webos I think I noticed that all of their
> objects are either defined in html or are described by the IDE in xml.
> I think it is the first option. Thinking about I realized how cool
> that was.What they do is describe the object in XML (each event has a
> proc like I like and not eventlisteners each property having methods
> for it and more) and then they parse these objects to create working
> js objects. How cool is that?I think we should discuss if this is the
> way to go? Can Dan tell us if this is what they do or did I get
> confused? This would be a great way to take care of all future
> versions. another thing I noticed is that they did what was proposed
> here be someone(forgot who it was) to split up the files per
> browser. 8an

Re: [Dynapi-Dev] getParent()

[Richard B. <ma...@ri...>]

Isn't this 
myDynLayer.getParentComponent() ?
myDynLayer.setParentComponent(blah) ?

Cheers,
Richard Bennett

ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)
Find the DynAPI faq here:
http://sourceforge.net/docman/display_doc.php?docid=656&group_id=5757
Browse the mailinglist here:
http://www.mail-archive.com/index.php3?hunt=dynapi


----- Original Message ----- 
From: "Alex Chong" <c....@mu...>
To: <dyn...@li...>
Sent: Tuesday, February 27, 2001 9:55 AM
Subject: [Dynapi-Dev] getParent()


> Hi,
> 
> Currently, the parent of a DynLayer is accessed using
> myDynLayer.parent.  I suggest in future Dynapi release, instead of
> accessing the parent directly, we use a getter function: i.e.
> myDynLayer.getParent().
> 
> This brings alot of convenience to the widget development.  Sometimes, a
> widget may want other to 'believe' that its parent is some other layer
> instead of its real parent.
> 
> Alex Chong
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> ____________________________________________________________
> Get your free domain name and domain-based e-mail from      
> Namezero.com. New!  Namezero Plus domains now available.    
> Find out more at: http://www.namezero.com                   
> 

[Dynapi-Dev] [Bug #133209] PathAnimation.slideTo() doesn't work properly within ns6

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

Bug #133209, was updated on 2001-Feb-20 02:10
Here is a current snapshot of the bug.

Project: DynAPI 2
Category: Browser-Specific Issue
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: paloucha
Assigned to : nobody
Summary: PathAnimation.slideTo() doesn't work properly within ns6

Details: After a first, completed, slide, getSource(e) isn't able to
retrieve the new obtained coordinatesin ns6.

Follow-Ups:

Date: 2001-Feb-20 06:27
By: nobody

Comment:
This information is correct, it is not however a bug in pathanim.js
itself.
See this example of the bug (NS6)

http://www.dynapi.f2s.com/dynapi/NS6_Tests/Sequential_Slides.html

The getX() and getY() values should appear on the status bar, they return
undefined.

use this ftp to test changes:
ftp.dynapi.f2s.com
username: dynapi
password: dynapi

In the 19/12/2000 snapshot of DynAPI2 this works correctly, see example
here:

http://www.resass.f2s.com/dynapi/Richard_Examples/Sequential_Slides.html

So it seems something someone changed broke the getX and getY functions for
NS6.

Richard
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133209&group_id=5757

Re: [Dynapi-Dev] DynAPI Licensing Agreement (& request)

[Ken O. <ko...@an...>]

My take on it is that you can certainly use it in that situation.  If you
change dynapi, you must make those changes available.  You must also give
credit to it and provide the license agreement.

Request: perhaps someone can build a "powered by dynapi" page that web site
developers can simply load into a web site that uses dyn api.   This would
make it easy for dynapi users as they could just include the page in order
to be compliant.  It is also a good way to "market" dyn api.

Just a thought...

Ken


------------------------>


Chris Lemon Wrote:

Hi,

I am developing a web app using DynAPI for use on a customers web site.
Having read the license agreement I am very confused.  Can someone clarify
the situation?  Does the agreement cover my situation.

Thanks.

Re: [Dynapi-Dev] Dynamic Loading.

[francesco A. <fa...@we...>]

see this site for alterative loading dynamic data
 work only for IE5+,NS6,Mozzilla, not IE mac, not NS4

http://www.xs4all.nl/~ppk/js/importxml.html



----- Original Message ----- 
From: "Michael Pemberton" <mp...@ph...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 2:05 PM
Subject: Re: [Dynapi-Dev] Dynamic Loading.


> url?
> 
> francesco AGATI wrote:
> 
> > see this site for alterative loading dynamic data
> > work only for IE5+,NS6,Mozzilla, not IE mac, not NS4
> 
> --
> Michael Pemberton
> mp...@ph...
> ICQ: 12107010
> 
> 
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev