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

Re[2]: [Dynapi-Dev] Interesting slideTo bug in veiwport (both NS and IE)

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

The slideBy method from slide.js will need to be added before slide.js
is removed.

-- 
// Robert Rainwater

On 12/7/2000, 12:14:32 PM EST, Alexey wrote about "[Dynapi-Dev] Interesting slideTo bug in veiwport (both NS and IE)":

>> Also, I would recommend that the slide.js be deleted or deprecated with an

> insert "alert('Deprecated')" iside it ;)


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

Re: [Dynapi-Dev] DynAPI Releases

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

Sure, I think we are about ready to make a new release.  There's only
a few things that need to be cleaned up.  Like dynimage.js and
images.js redundancy and the pathanim and slide redundancy.

When the new version is released, it will contain a list of the
changes that have been made from the last release.

-- 
// Robert Rainwater

On 12/6/2000, 9:49:30 AM EST, Peter wrote about "[Dynapi-Dev] DynAPI Releases":



> With all this CVS stuff, are there still going to be releases DynAPI? I 
> just want to get some periodic releases of reasonable stable versions of 
> the package, not every minor change that happens. I don't want to have to 
> pick up new stuff every day, with a "random" set of changes. And most 
> important - I really need to know what has changed from one version to the 
> next (not every minor bug fix - new features, changed features, etc.) Is 
> anything like this being done now?

> I am reading the mailing lists, but I can't possibly keep up with all the 
> traffic, or understand all the comments about areas that I'm not working 
> with at the moment, etc.

> --
> Peter Curran     Software Developer    Casebank Technologies Inc.

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

Re: AW: [Dynapi-Dev] DynAPI build, Splitting files

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

There is one major problem with splitting the files and having
different people working on them. The separate versions for each
browser will become inconsistent with each other when people make
changes to one and not the other. People will add "features" to some
versions and not to others. Then, you don't have a cross-browser
library, but a useless waste of files.

By the way has anybody looked at the compresses files that are now
apart of the DynAPI?
-- 
// Robert Rainwater

On 12/7/2000, 12:13:07 PM EST, SReindl wrote about "AW: [Dynapi-Dev] DynAPI build, Splitting files":

> Can someone pls explain me the mneaning of this whole discussion?
> An API is a set of uniquely defined functions to perform a given task, isn't
> it?
> What do the widgets have to do with the API?
> Why should it be so difficult to develop the API in separate files?
> The discussion would be which function of the API should be added / removed
> / corrected / ...
> The rest will be done by the respective browser gurus.
> The charme of the split file version is that a nn specialist doesn't have to
> analyze a bulk of ie code in order to do his task.
> The increase in speed an code transparency should overweigh the difficulties
> of a split version by far.
> If a solution fullfills the defined function, who cares about the details?
> I mean, I want to develop mainly for IE and am not interested in the nn
> specifics at all. I am satisfied when it works.

> Stephan



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

Re: [Dynapi-Dev] Interesting slideTo bug in veiwport (both NS and IE)

[Alexey M. <ma...@ca...>]

> Also, I would recommend that the slide.js be deleted or deprecated with an

insert "alert('Deprecated')" iside it ;)

AW: [Dynapi-Dev] DynAPI build, Splitting files

[SReindl <SR...@la...>]

Can someone pls explain me the mneaning of this whole discussion?
An API is a set of uniquely defined functions to perform a given task, isn't
it?
What do the widgets have to do with the API?
Why should it be so difficult to develop the API in separate files?
The discussion would be which function of the API should be added / removed
/ corrected / ...
The rest will be done by the respective browser gurus.
The charme of the split file version is that a nn specialist doesn't have to
analyze a bulk of ie code in order to do his task.
The increase in speed an code transparency should overweigh the difficulties
of a split version by far.
If a solution fullfills the defined function, who cares about the details?
I mean, I want to develop mainly for IE and am not interested in the nn
specifics at all. I am satisfied when it works.

Stephan

Re: [Dynapi-Dev] getImage

[Raymond S. <dst...@or...>]

Agreed.  And from what I have read about IE6 it's moving MS style to
integrate streamed media functionality into the browser itself (some of this
is in MSN Explorer already).  This of course will deliver blows to Real
Media, WinAmp, etc... as their functionality doesn't initialize by a simple
browser launch.

Unfortunately, NS6 is such a 'rendering' nightmare it will only HELP MS
capture more marketshare.

DS


----- Original Message -----
From: "Nuno Ferreira" <nun...@wi...>
To: <dyn...@li...>
Sent: Thursday, December 07, 2000 8:33 AM
Subject: RE: [Dynapi-Dev] getImage


> Hi Scott,
>
> Went to your site, while I was pausing my work and surfing the web.
> On the day that I fully realize what IE6 will mean to the Web and
> getting a cold shiver up my back understanding MS's master plan
> for controlling the web through the Win32 platform, reading your
> articles was like seeing a glimmer at the end of the tunnel.
>
> The best praise that I can think of is:
>
> "you write what I feel".
>
> Congratulations are in order.
>
> Best,
> NunoF
>
> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Scott Andrew
> LePera
> Sent: quinta-feira, 7 de Dezembro de 2000 2:33
> To: dynapi
> Subject: [Dynapi-Dev] getImage
>
>
> May I humbly suggest restoring the optional width and height arguments
> to the DynImage.getImage method.  It's a real pain when I have to wait
> for the image to be fully loaded before I can access the height and
> width.  I'd rather pass these values in advance when I can.
>
> --
> scott andrew lepera
> -----------------------------------
> web stuff:     www.scottandrew.com
> music stuff:   www.walkingbirds.com
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Interesting slideTo bug in veiwport (both NS and IE)

[Raymond S. <dst...@or...>]

Well, the bug is in pathanim.js.  The slideTo methods were overrighting the
old slideTo methods and it appears to 'skip' the final pathmove on select
horizaontal and vertical moves.

Also, I would recommend that the slide.js be deleted or deprecated with an
explanation inside it.  I entirely missed the new slideTo methods because I
did'nt study the new animation code completely.

I'll piddle with the pathanim.js later.  Probably just needs a final
'movecomplete' check to assure that the animation end == the destination
x,y.  Simular to what was in the old slideTo.

Later

DS


----- Original Message -----
From: "Richard :o" <ma...@ri...>
To: <dyn...@li...>
Sent: Wednesday, December 06, 2000 7:07 AM
Subject: Re: [Dynapi-Dev] Interesting slideTo bug in veiwport (both NS and
IE)


> I'm surprised, on 6/12/2000 you post that the fault is in the Math.round
> in pathanim.js, so you know slide.js is not being used, so the events
can't
> be triggered of course.
>
> did you read my post on the bug in pathanim.js line 133 should read y2==y1
> NOT y2==y2 so:
> var dy = y2==y1? 0 : (y2-y1)/N;
>
> don't include slide.js in your document anymore.(it might conflict)
>
> use onpathstart not onslide
> use onpathrun not onslide
> use onpathstop not onslideend
>
> That's all I can think of on that subject.
>
> Richard:o)
>
>
> ----- Original Message -----
> From: "Raymond Smith" <dst...@or...>
> To: <dyn...@li...>
> Sent: Thursday, December 07, 2000 2:17 PM
> Subject: [Dynapi-Dev] Interesting slideTo bug in veiwport (both NS and IE)
>
>
> > I've been using a viewport as a window to view one of nine content
> options.
> > It's a 3X3 array of images with 9 slideTo that center each of the nine
> > windows.  This all worked fine til the new animation system, now it has
> some
> > odd (but definable behavioral bugs that show up in both IE and NS.
> >
> > 1) It works fine on any diagonal slide.
> > 2) horizontal or vertical slides either are:
> >     a) always wrong in one direction, or
> >     b) wrong every other iteration, in one direction.
> >
> > The following method (line 45, slide extension), which should clean up
> final
> > moves to destination points (x,y) never seems to fire.
> >
> > else {
> >   this.moveTo(this.slideEndX,this.slideEndY)
> >   this.invokeEvent("slide")
> >   this.slideActive = false
> >   clearInterval(this.slideInterval)
> >   this.invokeEvent("slideend")
> >  }
> > }
> >
> > I'll continue to peruse this tomorrow.  Wanted to put it up for Dan to
> look
> > at since he wrote all the math and event handlers that go into the new
> > system and 'might' be obvious to him.
> >
> > Later,
> >
> > DS
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > ____________________________________________________________
> > Get your FREE personal .com domain name and
> > NAMEzero Personal Portal at: http://www.namezero.com.
> > For customer service, mailto:cus...@na....
> >
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] getImage

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

Hi Scott,

Went to your site, while I was pausing my work and surfing the web.
On the day that I fully realize what IE6 will mean to the Web and
getting a cold shiver up my back understanding MS's master plan
for controlling the web through the Win32 platform, reading your 
articles was like seeing a glimmer at the end of the tunnel.

The best praise that I can think of is: 
	
	"you write what I feel".

Congratulations are in order.

Best,
NunoF

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Scott Andrew
LePera
Sent: quinta-feira, 7 de Dezembro de 2000 2:33
To: dynapi
Subject: [Dynapi-Dev] getImage


May I humbly suggest restoring the optional width and height arguments
to the DynImage.getImage method.  It's a real pain when I have to wait
for the image to be fully loaded before I can access the height and
width.  I'd rather pass these values in advance when I can.

-- 
scott andrew lepera
-----------------------------------
web stuff:     www.scottandrew.com
music stuff:   www.walkingbirds.com

Re: [Dynapi-Dev] Interesting slideTo bug in veiwport (both NS and IE)

[Richard :o <ma...@ri...>]

I'm surprised, on 6/12/2000 you post that the fault is in the Math.round
in pathanim.js, so you know slide.js is not being used, so the events can't
be triggered of course.

did you read my post on the bug in pathanim.js line 133 should read y2==y1
NOT y2==y2 so:
var dy = y2==y1? 0 : (y2-y1)/N;

don't include slide.js in your document anymore.(it might conflict)

use onpathstart not onslide
use onpathrun not onslide
use onpathstop not onslideend

That's all I can think of on that subject.

Richard:o)


----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Thursday, December 07, 2000 2:17 PM
Subject: [Dynapi-Dev] Interesting slideTo bug in veiwport (both NS and IE)


> I've been using a viewport as a window to view one of nine content
options.
> It's a 3X3 array of images with 9 slideTo that center each of the nine
> windows.  This all worked fine til the new animation system, now it has
some
> odd (but definable behavioral bugs that show up in both IE and NS.
>
> 1) It works fine on any diagonal slide.
> 2) horizontal or vertical slides either are:
>     a) always wrong in one direction, or
>     b) wrong every other iteration, in one direction.
>
> The following method (line 45, slide extension), which should clean up
final
> moves to destination points (x,y) never seems to fire.
>
> else {
>   this.moveTo(this.slideEndX,this.slideEndY)
>   this.invokeEvent("slide")
>   this.slideActive = false
>   clearInterval(this.slideInterval)
>   this.invokeEvent("slideend")
>  }
> }
>
> I'll continue to peruse this tomorrow.  Wanted to put it up for Dan to
look
> at since he wrote all the math and event handlers that go into the new
> system and 'might' be obvious to him.
>
> Later,
>
> DS
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> ____________________________________________________________
> Get your FREE personal .com domain name and
> NAMEzero Personal Portal at: http://www.namezero.com.
> For customer service, mailto:cus...@na....
>
>

Re: [Dynapi-Dev] getImage

[Dan S. <dy...@fu...>]

DynImage.getImage() isn't the same code as DynAPI.getImage()

I wasn't really sure what to do with the getImage.  There's not much point in having both an /ext/images.js files and a /gui/dynimage.js.  I think maybe the /ext/images.js code should be moved into dynimage.  The DynImage widget is very small and much more handy than I would have expected.

A future addition to DynImage would allow it automatically resize itself based on the image's true w/h - this is not possible until someone code's in that ability.

Dan 

On Wed, Dec 06, 2000 at 06:33:22PM -0800, Scott Andrew LePera wrote:
> May I humbly suggest restoring the optional width and height arguments
> to the DynImage.getImage method.  It's a real pain when I have to wait
> for the image to be fully loaded before I can access the height and
> width.  I'd rather pass these values in advance when I can.
> 
> -- 
> scott andrew lepera
> -----------------------------------
> web stuff:     www.scottandrew.com
> music stuff:   www.walkingbirds.com
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] Interesting slideTo bug in veiwport (both NS and IE)

[Raymond S. <dst...@or...>]

I've been using a viewport as a window to view one of nine content options.
It's a 3X3 array of images with 9 slideTo that center each of the nine
windows.  This all worked fine til the new animation system, now it has some
odd (but definable behavioral bugs that show up in both IE and NS.

1) It works fine on any diagonal slide.
2) horizontal or vertical slides either are:
    a) always wrong in one direction, or
    b) wrong every other iteration, in one direction.

The following method (line 45, slide extension), which should clean up final
moves to destination points (x,y) never seems to fire.

else {
  this.moveTo(this.slideEndX,this.slideEndY)
  this.invokeEvent("slide")
  this.slideActive = false
  clearInterval(this.slideInterval)
  this.invokeEvent("slideend")
 }
}

I'll continue to peruse this tomorrow.  Wanted to put it up for Dan to look
at since he wrote all the math and event handlers that go into the new
system and 'might' be obvious to him.

Later,

DS

[Dynapi-Dev] Help! stability in NN4

[Alexey M. <ma...@ca...>]

  Could you help me, how to make DHTML page more stable in Netscape4 ?

  I already know that too much of CSS styles creation (especially with
  fonts sizes) are crashing NN.

  Also I have read about "</style>\n" , which Dan have found.

  I saw myself strange replication of <div style> statements , when
  you try to make them with document.write().

  Is there anything else ?   
	(I'm using old version of Dan's library and know about the need
   to switch to new one :) But have no time. Also I need it for Netscape4
  just now - to shorten time of development.


				Malx
-- 
All our life is digging in memories. Some of them 0.01 sec old.

RE: Re[4]: [Dynapi-Dev] Label Cover Bug

[Guangyi Wu <gua...@al...>]

> Somehow I missed your post before.  Anyway, I got your fixes for IE to
> work, but a do have one question.  What is this for:
> if (is.ie) {
>    if (evt.browserReturn==false) e.returnValue=false
> }
> 
> I did not apply this, and your patch still works.

You are right. It still works without these lines. I added these lines
because I found the example below in the MSDN. I noticed the
event.returnValue is set to false instead of directly returns false. I agree
with you not to apply this as long as it works.

> 
> Also, the cursor for IE needs to be set oncreate as well, because if
> you do setSelectable before the create it will never be set.

The current oncreate handler looks like this:
	listener.oncreate	= function(e)	{
		var o = e.target
		if (!o.selectable) {
			if (is.ie||is.dom) {
				o.css.cursor="default"
			}
		}
	}
I did not set the css.cursor to "text" if the label is setSelectable before
the create, because the "text" cursor is the default one for creating. In
the function setSelectable, css.cursor has to be set to "text" for
overwritten the non-selectable cursor.

br
George

============================
Cancelling the Default Action
I've given you an example that demonstrates how you can cancel bubbling. Now
let's look at an example that demonstrates how to cancel the default action.

<HTML>
<HEAD><SCRIPT LANGUAGE="JavaScript"><!--
  function confirmDefault()
  {
    sMsg = "Do you want to go to " +
window.event.srcElement.innerText + "?   ";
      if (!window.confirm(sMsg)) {
         window.event.returnValue = false;
      }
   }
//--></SCRIPT>

<TITLE></TITLE>
</HEAD>

<BODY>
<A HREF="http://www.microsoft.com/sitebuilder/"
ONCLICK="confirmDefault()">
<P>MSDN Online Home Page</A> </P>
</BODY>
</HTML>

In the script above, you can see that the OnClick handler is created to
confirm whether the user will go to the site listed. If the user clicks the
Cancel button, the default action (navigating to the link) is cancelled.
============================

> 
> Also, the cursor for IE needs to be set oncreate as well, because if
> you do setSelectable before the create it will never be set.
> 
> I updated it in CVS.  I did not include the fixes for NS yet, as I
> have not tested it.
> 
> -- 
> // Robert Rainwater
> 
> On 12/6/2000, 4:24:08 AM EST, Guangyi wrote about 
> "[Dynapi-Dev] Label Cover Bug":
> 
> >> 
> >> It looks like in IE (I haven't tested NS), that these 
> events are not
> >> fired:
> >> 
> >> this.selectListener.onmousemove, etc.
> >> 
> >> These should be fired when you say setSelectable(false).
> >> 
> >> This could be one of the problems with IE not working.
> >> 
> > The onmousemove event is not fired because it is not 
> registered for DynLayer
> > in the event.js.
> 
> > I posted a patch for the label, containing event.js and 
> label.js based on
> > 12.01 beta in a zip file, a few days ago. It should be 
> fixed in the patch.
> 
> > br
> > George
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 

RE: [Dynapi-Dev] DynAPI build, Splitting files

[Guangyi Wu <gua...@al...>]

The life would be simpler if widgets should not be split. However, when
performance is an considerable issue, we might find later it is also an
admired feature if we can get widgets with an uniformed interface and
browser depended implementation. If we decide to split the API, why don't we
split it in a graceful and general way, so that other modules can also be
benifit?

I would sugest to open a new package to implement this feature after the
current version becomes stable. Only when a class applies this feature, the
correct files/objects would be included. In this way, we do not have to
break the worked version, and get a more generally useful package.

br
George

> 
> Right... widgets should not be split.
> I agree that that's the entire purpose of a core API. The 
> extensions, by
> definition, should be split due to their inherent purpose... 
> extending a
> core object, or a sub class of a core.
> The number of core objects may increase in the future, and 
> that could cause
> the API to grow to a level that is too much for a user to 
> handle.. waiting
> for a download that is...
> 
> ----- Original Message -----
> From: "Scott Andrew LePera" <sc...@sc...>
> To: <dyn...@li...>
> Sent: Wednesday, December 06, 2000 6:20 PM
> Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files
> 
> 
> > If there's going to be any splitting, I think it should 
> only be done in
> > the core files and maybe some of the heavier extensions.  
> I'd rather not
> > have to create split versions of a widget; at that point, 
> it stops being
> > cross-browser, so why bother having an API? It would be 
> difficult enough
> > just to maintain the core files for all browsers.
> >
> > --
> > scott andrew lepera
> > -----------------------------------
> > web stuff:     www.scottandrew.com
> > music stuff:   www.walkingbirds.com
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 

RE: [Dynapi-Dev] DynAPI build, Splitting files

[Cameron H. <ca...@bi...>]

> If there's going to be any splitting, I think it should only be done in
> the core files and maybe some of the heavier extensions.  I'd rather not
> have to create split versions of a widget; at that point, it stops being
> cross-browser, so why bother having an API? It would be difficult enough
> just to maintain the core files for all browsers.

I agree, if the whole thing gets split into lots of different browser
specific files, it will potentially stop being a cross-browser API. Being
cross-browser and abstracting site developers from the underlying
cross-browser muck to me is one of the best reasons for using the API. I
don't know if my Makefile idea is workable, it would be a pain to add a
compile stage into the code/test development process. But then again, the
API does mimick Java in many ways already ;-)

On another note, does IE on Solaris and Mac even support VB?

Re[3]: [Dynapi-Dev] Scrollpane Problems

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

Just an update.  I fixed the cancelScroll problem w/:
ViewPort.prototype.cancelScroll = function() {
        this.contentPane.pathanim.stopAnimation();
        this.invokeEvent("scrollend");
};

-- 
// Robert Rainwater

On 12/6/2000, 10:13:31 PM EST, Robert wrote about "[Dynapi-Dev] Scrollpane Problems":


> There's a conflict with pathanim creating a slideTo.  I believe you
> confused that slideTo with the one in slide.js (they would override
> each other if used in the same page!!!).  Anyway, I fixed the
> scrollpane by editing cancelScroll in viewport.js:

> ViewPort.prototype.cancelScroll = function() {
>         this.contentPane.pathanim.stop();
>         this.contentPane.pathanim = null;
>         this.invokeEvent("scrollend");
> };

> I suggest we rename the pathanim slide method to remove any conflict.
> Good idea?

> Also why does pathanim have to be set to null for the next slide to
> work?  If you remove it, after you stop scrolling, then the
> contentPane will not scroll anymore unless you set its pathanim to
> null.

[Dynapi-Dev] dynlayer.js patch

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

The following changes to the DynLayer are needed to fix problems with
removing a dynlayer and adding a dynlayer back to a document/dynlayer.

Line:192 in DynLayer.prototype.deleteElement
    this.elm={}; // was this.elm = null
    this.doc={}; // was this.elm = null
    this.css={}; // was this.elm = null

This will fix problems with the widgets.  For example in IE in
dynapi.gui.scrollpane.html - try Adding Label #2 and then re-adding
Label #1 to the contents.  Without the above patch, it will throw an
error.


-- 
// Robert Rainwater

Re: [Dynapi-Dev] Splitting the API?

[Brandon M. <bnd...@ho...>]

ACK! That would make development a nightmare..
Change the original code... run it through the code splitter, run the
test...

I like just changing the code, hit refresh on browser page... much
quicker... one less window.

----- Original Message -----
From: "Cameron Hart" <ca...@bi...>
To: <dyn...@li...>
Sent: Tuesday, December 05, 2000 5:51 AM
Subject: RE: [Dynapi-Dev] Splitting the API?


> I posted a suggestion to Dan's message about using a Makefile system for
> building a final version of the code, I thought it would be worth
suggesting
> it to this thread of the discussion.
>
> I think it would be a good idea to have a C style #define in the src
> javascript to allow building final versions for different browsers. I
think
> the advantage of doing this is the cross-browser API remains in one set of
> source, and users people can then build either seperate versions for each
> browser, or build them all into one library. From a development point of
> view, to me it makes more sense to keep all the code in a canonical form,
> rather than split for every major browser/platform that comes into
> existence.
>
> Cam.
>
> > -----Original Message-----
> > From: dyn...@li...
> > [mailto:dyn...@li...]On Behalf Of Eytan
> > Heidingsfeld
> > Sent: 05 December 2000 09:24
> > To: dyn...@li...
> > Subject: Re: [Dynapi-Dev] Splitting the API?
> >
> >
> > Although I am not so sure why thing would run so much better with the
API
> > split I also have 2c. Basically everything that is browser based are the
> > actual low-level components (DynLayer, events....) why don't we
> > split those
> > components in to one for each version. Then when a higher level
> > component (a
> > decendent) is created in the constructor you add the following code
> > if (browser == IE){inherit from IEDynLayer;}
> > if (browser == NS){inherit from NSDynLayer;}
> > ..
> > ..
> > ..
> > You get the picture. Then although it might be a hassle to orginize the
> > low-level comps the higher level one will be relitivly easy.
> >
> > 8an
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re[4]: [Dynapi-Dev] CVS in WIndows

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

Make sure that ssh is in your path.  Try typing ssh from Start|Run and
see if a dos box will open.  If not, ssh.exe is not in your path.

Also, make sure you have checked "Check for alternate rsh name" under
Admin|Preferences|Ports.  The value for that textbox should be "ssh".

-- 
// Robert Rainwater

On 12/6/2000, 5:50:27 PM EST, Darin wrote about "[Dynapi-Dev] CVS in WIndows":

> guys, this is starting to drive me nuts.
> i'm pretty sure i've set wincvs up correctly.
> I have an environment var named "HOME" set to "c:\home". I'm using nt4 sp5.

> when i just load the app, right-click on the project and select "checkout
> module"  (and then typing in "dynapi"), my message window looks like this:

> CVSROOT: :ext:to...@cv...:/cvsroot/dynapi (ssh
> authentication)
> TCL is *not* available, shell is disabled
> cvs -d :ext:to...@cv...:/cvsroot/dynapi checkout -P -d
> dynapi dynapi (in directory C:\home)
> cvs [checkout aborted]: cannot start server via rsh: No such file or
> directory

> *****CVS exited normally with code 1*****


> am i the only one who can't get this to work? 

> -----Original Message-----
> From: Robert Rainwater [mailto:rra...@ya...]
> Sent: Monday, December 04, 2000 4:39 PM
> To: DynAPI Development List
> Subject: Re[2]: [Dynapi-Dev] CVS in WIndows



> I believe that is correct. With the method I showed, you can not use
> the login options. It will prompt for a login when you do a
> checkout/checkin. However, there is not a module to check out yet.
> Hopefully, they will reset CVS today. I will post when the module has
> been imported. Then you can just checkout the module.

Re: Re[2]: [Dynapi-Dev] CVS in WIndows

[Brandon M. <bnd...@ho...>]

Try:
CVSROOT: :ssh:to...@cv...:/cvsroot/dynapi
(notice the change from :ext: to :ssh: )

TCL is *not* available, shell is disabled
 (This is normal.. don't wory)

Set an environment variable: CVS_RSH=c:\path\to\ssh.exe

Test your connection to sourceforge:
ssh -l username dynapi.sourceforge.net

type password at prompt.... tada!.. it should work.

Then.. before you can checkout anything, you should authenticate (login) to
the CVS server..
WinCVS: Admin menu/Login

----- Original Message -----
From: "Darin Kadrioski" <dka...@ef...>
To: <dyn...@li...>
Sent: Wednesday, December 06, 2000 5:50 PM
Subject: RE: Re[2]: [Dynapi-Dev] CVS in WIndows


> guys, this is starting to drive me nuts.
> i'm pretty sure i've set wincvs up correctly.
> I have an environment var named "HOME" set to "c:\home". I'm using nt4
sp5.
>
> when i just load the app, right-click on the project and select "checkout
> module"  (and then typing in "dynapi"), my message window looks like this:
>
> CVSROOT: :ext:to...@cv...:/cvsroot/dynapi (ssh
> authentication)
> TCL is *not* available, shell is disabled
> cvs -d :ext:to...@cv...:/cvsroot/dynapi
checkout -P -d
> dynapi dynapi (in directory C:\home)
> cvs [checkout aborted]: cannot start server via rsh: No such file or
> directory
>
> *****CVS exited normally with code 1*****
>
>
> am i the only one who can't get this to work?
>
> -----Original Message-----
> From: Robert Rainwater [mailto:rra...@ya...]
> Sent: Monday, December 04, 2000 4:39 PM
> To: DynAPI Development List
> Subject: Re[2]: [Dynapi-Dev] CVS in WIndows
>
>
>
> I believe that is correct. With the method I showed, you can not use
> the login options. It will prompt for a login when you do a
> checkout/checkin. However, there is not a module to check out yet.
> Hopefully, they will reset CVS today. I will post when the module has
> been imported. Then you can just checkout the module.
>
> --
> // Robert Rainwater
>
> On 12/4/2000, 1:55:33 PM EST, Darin wrote about "[Dynapi-Dev] CVS in
> WIndows":
>
>
> > after installing and using the settings outlined below (on NT4), i get a
> > message saying :
>
> > CVSROOT: :ext:to...@cv...:/cvsroot/dynapi (ssh
> > authentication)
> > TCL is *not* available, shell is disabled
>
>
> > i can't seem to get any further.
> > "torgo" is my username on sourceforge.
>
> > any idea what i am doing wrong?
>
>
>
> > -----Original Message-----
> > From: Robert Rainwater [mailto:rra...@ya...]
> > Sent: Sunday, December 03, 2000 3:02 PM
> > To: DynAPI Development List
> > Subject: [Dynapi-Dev] CVS in WIndows
>
>
>
> > Here are some quick and dirty instructions for setting up CVS on
> > windows.
>
> > Files
> > -----
>
> > WinCVS:
> > ftp://sunsite.cnlab-switch.ch/mirror/cvsgui/WinCvs11b17.zip
>
> > SSH:
> > ftp://ftp.dei.uc.pt/.disk2/Crypto/SSH/contrib/ssh-1.2.14-win32bin.zip
>
> > Installation
> > ------------
> > Install WinCVS as per the instructions provided.
>
> > - Unzip ssh-1.2.14-win32bin.zip to a directory (ex. c:\ssh).
> > - Add c:\ssh to the PATH variable.
> > - Create a HOME directory (ex. c:\home).
> > - Create environment variable HOME with value c:\home
> > - Restart
>
> > - Start WinCVS.
> > - It should prompt to enter your CVS Root.  (if not, choose
> > Admin|Preferences).  Enter the cvs root as:
> > ":ext:<username>@cvs.dynapi.sourceforge.net:/cvsroot/dynapi"
> > Below CVSRoot, choose SSH Server for authentication.  Then click the
> > Ports tab and click "Check for alternate rsh name" to enable it.  Then
> > choose OK and your set.
>
> > Also, you can choose View|Browse Location|Change to change to a
> > working directory, so you will not see your whole hard drive in the
> > view.  Choose c:\home for example.
>
> > Now your set.
>
> > To checkout a module, Right click Home and choose checkout and then
> > you would enter the name of the module.  A DOS box will pop up that
> > will require your sourceforge password.
>
> > Currently, there is no module yet to checkout, but you would normally
> > checkout "dynapi" to get the latest version.
>
> > For more info checkout:
> > https://sourceforge.net/docman/display_doc.php?docid=766&group_id=1
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

Re[2]: [Dynapi-Dev] Scrollpane Problems

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

There's a conflict with pathanim creating a slideTo.  I believe you
confused that slideTo with the one in slide.js (they would override
each other if used in the same page!!!).  Anyway, I fixed the
scrollpane by editing cancelScroll in viewport.js:

ViewPort.prototype.cancelScroll = function() {
        this.contentPane.pathanim.stop();
        this.contentPane.pathanim = null;
        this.invokeEvent("scrollend");
};

I suggest we rename the pathanim slide method to remove any conflict.
Good idea?

Also why does pathanim have to be set to null for the next slide to
work?  If you remove it, after you stop scrolling, then the
contentPane will not scroll anymore unless you set its pathanim to
null.

-- 
// Robert Rainwater

On 12/6/2000, 10:37:03 PM EST, Dan wrote about "[Dynapi-Dev] Scrollpane Problems":

> The event names during slide's have changed, they are "pathstart", "pathrun", and "pathstop".  So this would be the first thing to look at.  If no one else finds the problem I will get around to it.

> Dan 

> On Wed, Dec 06, 2000 at 03:31:33PM -0500, Robert Rainwater wrote:
>> 
>> Using the latest from CVS, the scroll buttons do not work as they
>> should.  By clicking the down arrow and releasing, the object will
>> continue to scroll until it reaches the bottom, even if you release
>> the button.
>> 
>> It appears scrollpane does not catch the onscrollend.  I don't know if
>> it needs to, but the cancelScroll() is obviously not working right in
>> the scrollpane.
>> 
>> Also, the pushpanel, is having a similar problem, when the buttons do
>> not disappear until you click then again after scrolling all the way
>> to the top or bottom.
>> 
>> -- 
>> // Robert Rainwater
>> 
>> 
>> _______________________________________________
>> Dynapi-Dev mailing list
>> Dyn...@li...
>> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] DynAPI build, Splitting files

[Brandon M. <bnd...@ho...>]

Right... widgets should not be split.
I agree that that's the entire purpose of a core API. The extensions, by
definition, should be split due to their inherent purpose... extending a
core object, or a sub class of a core.
The number of core objects may increase in the future, and that could cause
the API to grow to a level that is too much for a user to handle.. waiting
for a download that is...

----- Original Message -----
From: "Scott Andrew LePera" <sc...@sc...>
To: <dyn...@li...>
Sent: Wednesday, December 06, 2000 6:20 PM
Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files


> If there's going to be any splitting, I think it should only be done in
> the core files and maybe some of the heavier extensions.  I'd rather not
> have to create split versions of a widget; at that point, it stops being
> cross-browser, so why bother having an API? It would be difficult enough
> just to maintain the core files for all browsers.
>
> --
> scott andrew lepera
> -----------------------------------
> web stuff:     www.scottandrew.com
> music stuff:   www.walkingbirds.com
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] getImage

[Scott A. L. <sc...@sc...>]

May I humbly suggest restoring the optional width and height arguments
to the DynImage.getImage method.  It's a real pain when I have to wait
for the image to be fully loaded before I can access the height and
width.  I'd rather pass these values in advance when I can.

-- 
scott andrew lepera
-----------------------------------
web stuff:     www.scottandrew.com
music stuff:   www.walkingbirds.com

Re[2]: [Dynapi-Dev] Splitting the API?

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

I think right now there a bigger issues.  Such as bugs in the
pushpanel, scrollpanel, and loadpanel.  If we can make this version
stable, then creating a parser to separate the code would be nice.
But, it really is not the most important problem right now.  We need
to release a new version soon, but we can't until it becomes stable.

-- 
// Robert Rainwater

On 12/5/2000, 5:51:29 AM EST, Cameron wrote about "[Dynapi-Dev] Splitting the API?":

> I posted a suggestion to Dan's message about using a Makefile system for
> building a final version of the code, I thought it would be worth suggesting
> it to this thread of the discussion.

> I think it would be a good idea to have a C style #define in the src
> javascript to allow building final versions for different browsers. I think
> the advantage of doing this is the cross-browser API remains in one set of
> source, and users people can then build either seperate versions for each
> browser, or build them all into one library. From a development point of
> view, to me it makes more sense to keep all the code in a canonical form,
> rather than split for every major browser/platform that comes into
> existence.

> Cam.

>> -----Original Message-----
>> From: dyn...@li...
>> [mailto:dyn...@li...]On Behalf Of Eytan
>> Heidingsfeld
>> Sent: 05 December 2000 09:24
>> To: dyn...@li...
>> Subject: Re: [Dynapi-Dev] Splitting the API?
>>
>>
>> Although I am not so sure why thing would run so much better with the API
>> split I also have 2c. Basically everything that is browser based are the
>> actual low-level components (DynLayer, events....) why don't we
>> split those
>> components in to one for each version. Then when a higher level
>> component (a
>> decendent) is created in the constructor you add the following code
>> if (browser == IE){inherit from IEDynLayer;}
>> if (browser == NS){inherit from NSDynLayer;}
>> ..
>> ..
>> ..
>> You get the picture. Then although it might be a hassle to orginize the
>> low-level comps the higher level one will be relitivly easy.
>>
>> 8an
>>
>> _______________________________________________
>> Dynapi-Dev mailing list
>> Dyn...@li...
>> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

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

RE: [Dynapi-Dev] DynAPI build, Splitting files

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

That would mean that Flash is a failure, because
I don't seem to remember a single flash page that takes less
than 7 seconds to load, on a normal 56k connection.

usually people tend to forget about load-times when they're
expecting flash pages, especially with "cool" pre-loading screens.

It's just a question that when you(generally speaking)
know that a page is in HTML you raise your standards in terms of
load times, and when you're expecting a Flash Page, suddenly 2min
of waiting don't seem a long time....

NunoF


-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Doug Melvin
Sent: quarta-feira, 6 de Dezembro de 2000 21:33
To: dyn...@li...
Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files


I don't know what you consider crucial.. but, a recent study suggests that
if your page takes more than 7 seconds to load (that's right, 7 seconds)
then more than half of your viewer will get board and leave before they get
to see all of the 'cool' and 'clever' stuff you have put on or done to your
site

Doug Melvin

> The only files in the DynAPI that are browser related are DynLayer,
DynDocument, and Loadpanel.  So if everyone feels we should have nn4,ie, and
dom.js separations we can certainly do this.  For the rest of the files it's
completely unnecessary.  For the time being I'd not worry about it too much.
Everythings working fine, I'd prefer on concentrating on building more
widgets.  After we have a larger codebase we can better decide what changes
are really necessary (at this point I don't think such a change is crutial
for continued developement).
>
> Dan
>
> On Wed, Dec 06, 2000 at 07:58:53AM -0600, Dougal Campbell wrote:
> > On 5 Dec 2000, Bill Wheaton wrote:
> >
> > > What I meant (can't say about Cameron), was that it would be nice to
have all
> > > of the functionality of the API without even worrying if it is cross
browser
> > > compatible.
> > > Quite often, I have to write intranet apps where my customer can and
> > > absolutely does control which ua their users use. (via SMS or
whatever).  It
> > > doesn't matter as much over a lan, but for their remote sales people
dialing
> > > up from his customer's pots line to check product allocation during
the lunch
> > > break, it can be slow.  If I could _only_ include IE code when I knew
it was
> > > the standard, then I could speed things up some.... maybe even a lot.
> > > maybe I'm dreaming
> > > -bw
> >
> > Those of you interested in browser-targeted code might want to take a
> > look at <URL:http://www.dx0.org/>. This is a cross-browser library with
> > a difference: it uses server-side technology to detect which browser is
> > making the connection, then it delivers JavaScript targeted to that
> > particular browser.
> >
> > In other words, if you view the site with Netscape 4.x, you only receive
> > JavaScript for NS4 (there's no "if is.ie" conditionals). If you browse
> > in with IE5, you get Javascript specifically for IE5 (no "if
> > is.ns4"). Or Mozilla, or NS6, or whatever (they might be supporting
> > Opera, if the new release has decent DOM).
> >
> > The project is still in heavy development, but there are already a few
> > skinnable widgets built and working (a menu, a floating toolbar, and a
> > viewBox (a scrollbar/window).
> >
> > You build your DHTML code in PHP, Perl, or Python. The server then
> > delivers appropriate JS to the browser.
> >
> > Also check out <URL:http://deathstar.eng.utah.edu/~kroford/930/dx0/>
> >
> > Keep in mind that the library and the site are still under development,
> > and there are sections of the web site that aren't complete yet. But
> > from what I've seen on the mailing list, it looks like a few people are
> > using it in production already.
> >
> > --
> > Ernest MacDougal Campbell III, MCP <do...@gu...>
> > http://www.gunters.org/~dougal/
> > Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/
> > "The medium is not the message. The *message* is the message."
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>