Menu
▾
▴
dynapi-dev — List related to the current DynAPI Core development
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(75) |
Nov
(252) |
Dec
(418) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(659) |
Feb
(1039) |
Mar
(870) |
Apr
(235) |
May
(329) |
Jun
(251) |
Jul
(123) |
Aug
(119) |
Sep
(67) |
Oct
(194) |
Nov
(535) |
Dec
(133) |
| 2002 |
Jan
(122) |
Feb
(24) |
Mar
(29) |
Apr
(28) |
May
(16) |
Jun
(20) |
Jul
(11) |
Aug
(12) |
Sep
(13) |
Oct
(14) |
Nov
(23) |
Dec
(19) |
| 2003 |
Jan
(28) |
Feb
(170) |
Mar
(288) |
Apr
(211) |
May
(126) |
Jun
(166) |
Jul
(131) |
Aug
(102) |
Sep
(211) |
Oct
(301) |
Nov
(22) |
Dec
(6) |
| 2004 |
Jan
(14) |
Feb
(16) |
Mar
(7) |
Apr
|
May
(8) |
Jun
(25) |
Jul
(21) |
Aug
(2) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(2) |
Mar
(14) |
Apr
(24) |
May
(3) |
Jun
(7) |
Jul
(30) |
Aug
(5) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(1) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
|
From: Dan S. <dy...@fu...> - 2000-12-08 15:05:49
|
Pascal, initially I wasn't so hot to trot with whitespace compression either, but after playing around with it it's really quite cool, and I'm glad I put in the time to create my little jspack util. If you check again, the compression ratio is closer to about 30%, more or less depending on how many comments you put in there. All the /api/ files were "manually" compress. I don't particularly enjoy reading code that is like this:
if(b)c=2
else if(a&&b||c&&d<=4)method()
else {method();return false}
And with the system set up now, we won't have to. You just write your code, putting in all the comments and whitespace you want, and (as long as the ;'s are correct) it will all be squished down for you in a build release.
Also, jspack compresses stuff that gzip/jar's can't do much with, like the following:
if (a) {
}
else if (b || c) {
}
The spaces and line breaks have to be maintained. But in a jspacked version:
if(a){}else if(b||c){}
It's already taken care of. After you jspack, and jar/gzip it, you're up to over 80% compression (85% for dynapi2 currently). Whereas gzip on it's own can only do about 60%. Plus by whitespace compression, each individual file can be compressed, whereas there's no point in having an individual gzip/jar file for each js file because you don't gain much in small files.
Another thing that's kinda cool, imagine when you build a game, or standalone app in JS. When you want to release the app to the public, you can build your own JS pack file with the code you need all in there (GPL license allows u to do this if the program you wrote is also GPL). I'm rewriting my tetris game, so I'd make a jspack for it with:
jspack -o tetris-packed.js tetris.js ../dynapi/dynapi.js ../dynapi/api/ ../dynapi/gui/image.js
That produces a single js file with all the code I need squished together. This is an ideal way to publish js apps or games IMO because you no longer need to include the entire dynapi with your app (or copy select files along .
Dan
On Fri, Dec 08, 2000 at 12:49:06PM +0100, Pascal Bestebroer wrote:
> Not to be raving on anybodys parade, but whitespace compressions isn't
> really worth it is it? You only stripped about 4kb off the complete api/
> folder (dynlayer,dyndocument,etc..) if you remove all comments and
> semi-colons from the un-"compressed" files, you will probably end up with
> even less "compression".
>
> I know that compression on all widgets might give more advantage, but then
> again when will you be actually using all widgets?
>
> I think the jar and gzip are great, but jar won't work in IE, and I don't
> think gzip works in ie4 (and how about IE on Macs?)
>
> Am I missing some advantage in this?
>
>
>
> Pascal Bestebroer
> pb...@oi...
> http://www.oibv.com
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Michael P. <mp...@ph...> - 2000-12-08 12:06:22
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I've tweaked my code beyond recognision but have found the following code:
<br><tt> var alt,ctrl,shft</tt>
<br><tt> if (is.ie){</tt>
<br><tt> alt = (e.altKey || e.altLeft)?true:false</tt>
<br><tt> ctrl = (e.ctrlKey ||
e.ctrlLeft)?true:false</tt>
<br><tt> shft = (e.shiftKey
|| e.shiftLeft)?true:false</tt>
<br><tt> }</tt>
<br><tt> if (is.ns){</tt>
<br><tt> var m = e.modifiers</tt>
<br><tt> alt = (m==1 || m==3
|| m==5 || m==7)?true:false</tt>
<br><tt> ctrl = (m==2 || m==3
|| m==6 || m==7)?true:false</tt>
<br><tt> shft = (m==4 || m==5
|| m==6 || m==7)?true:false</tt>
<br><tt> }</tt>
<br>Can be changed to the following:<tt></tt>
<p><tt> if (is.ie||is.ns5){</tt>
<br><tt> this.altKey
= (e.altKey || e.altLeft)</tt>
<br><tt> this.ctrlKey =
(e.ctrlKey || e.ctrlLeft)</tt>
<br><tt> this.shiftKey = (e.shiftKey
|| e.shiftLeft)</tt>
<br><tt> }</tt>
<br><tt> if (is.ns4){</tt>
<br><tt> var m = e.modifiers</tt>
<br><tt> this.altKey
= (m==1 || m==3 || m==5 || m==7)</tt>
<br><tt> this.ctrlKey =
(m==2 || m==3 || m==6 || m==7)</tt>
<br><tt> this.shiftKey = (m==4
|| m==5 || m==6 || m==7)</tt>
<br><tt> }</tt>
<p>It makes the code simpler and also adds support for NS6. Hope
this helps.
<br>--
<br>Michael Pemberton
<br>mp...@ph...
<br>ICQ: 12107010
<br> </html>
|
|
From: Pascal B. <pb...@oi...> - 2000-12-08 11:49:18
|
Not to be raving on anybodys parade, but whitespace compressions isn't really worth it is it? You only stripped about 4kb off the complete api/ folder (dynlayer,dyndocument,etc..) if you remove all comments and semi-colons from the un-"compressed" files, you will probably end up with even less "compression". I know that compression on all widgets might give more advantage, but then again when will you be actually using all widgets? I think the jar and gzip are great, but jar won't work in IE, and I don't think gzip works in ie4 (and how about IE on Macs?) Am I missing some advantage in this? Pascal Bestebroer pb...@oi... http://www.oibv.com |
|
From: Pascal B. <pb...@oi...> - 2000-12-08 07:41:04
|
maybe using the document.all (real browser document.all array) or getElementById for DOM browsers .. if it returns a null value then the element is really gone, otherwise the browser still things it's there. Pascal Bestebroer pb...@oi... http://www.oibv.com -----Oorspronkelijk bericht----- Van: dyn...@li... [mailto:dyn...@li...]Namens Scott Andrew LePera Verzonden: vrijdag 8 december 2000 8:35 Aan: dyn...@li... Onderwerp: Re: [Dynapi-Dev] core api -- DynLayer Questions The major difference between the two is that remove methods simply remove the DynLayer but do not destroy it. You can remove a DynLayer and then add it back, possibly to a new parent. When a DynLayer is removed, it returns to the "unassigned" state (meaning it has no parent and no DynDocument). The delete methods remove the DynLayer and destroy all internal references to it. When you delete a DynLayer, you cannot add it back. It's gone. You have to create a new one. That said, I wish there was some way to ensure that all references to a DynLayer object were destroyed -- as long as even one reference remains, the DynLayer will still exist, and the resources it uses will not be released. I don't think one exists; there's no way that I know of to automatically detect all references to an object and destroy them. Or is there? -- 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 |
|
From: Robert R. <rra...@ya...> - 2000-12-08 07:20:30
|
> - Robert I had a problem with your change to DynImage, it wouldn't > work because the width and height was defaulting to the image's size > - this should not be manditory because there's many cases where you > do not want to use the true w/h, and also it's not possible to find > that info before onload. So I removed that part from the dynimage in > cvs I added an autoResize(boolean) method to DynImage so that will resize the layer to the image size when set to true. The Button widget sets autoResize to true so that the layer size will be set correctly. -- // Robert Rainwater |
|
From: Dan S. <dy...@fu...> - 2000-12-08 05:14:31
|
All ya do is add /lib/dynapi/ext/inlinecreation.js (after dynlayer) and this will overwrite DynLayer's create() with a new system for writing all the children layers and html content in a single dump. Include the file and try anything you're working on and you WILL see a very noticable improvement for Netscape. I've left in all the hooks necessary to do the same for IE. It's merely a matter of writing the string for a <DIV>. Once that's done we can move this into DynLayer. Notes: - this only works for children layers thus far, the first layer added to the document is created as usual, all it's children are written - Robert I had a problem with your change to DynImage, it wouldn't work because the width and height was defaulting to the image's size - this should not be manditory because there's many cases where you do not want to use the true w/h, and also it's not possible to find that info before onload. So I removed that part from the dynimage in cvs Dan |
|
From: Richard :o <ma...@ri...> - 2000-12-08 03:14:58
|
hi,
Maybe you can slip in this bug fix before going to press:
(IE5.5 WinMe latest snapshot dynapi.zip)
* Viewport.html error on mouseover 'scroll up' etc
solution: pathanim.js line 142 was:
this.contentPane.pathanim.stopAnimation();
should be:
this.contentPane.stopSlide();
Other bugs found:
* Label.html all are selectable; (ns ok)
resizing non wrappable doesn't work
unselectable layer ==selectable (cursor==ok)
* ScrollBar.html slight jumping of scroll
* ScrollPane.html arrow buttons don't work well.(also ns)
they don't move the scrollbar right to the end.
Cheers,
Richard :)
----- Original Message -----
From: "Robert Rainwater" <rra...@ya...>
To: "DynAPI Development List" <dyn...@li...>
Sent: Thursday, December 07, 2000 6:34 PM
Subject: Re: [Dynapi-Dev] DynAPI Releases
>
> 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
>
>
> _______________________________________________
> 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....
>
>
|
|
From: Dan S. <dy...@fu...> - 2000-12-08 02:14:27
|
Just as an update I'm at the moment working on doing inline creation for Netscape (it's an itch I have to scratch). By this I mean instead of creating each layer with "new Layer()", only first layer you draw does this. All the children layers and html content of that one are written in one shot with a document.write(). This will give an enormous boost in drawing speed for Netscape - at least 5 times faster for layers with html content, less so for blank layers. The same can be done for IE, and similar speed increase should be seen as well. Lemme just work out how it should be structured first. Initially this will be mostly an extention to DynLayer. Some code does need to be inserted in DynLayer.create(), it will call functions in the extention file. But I think eventually this should be worked directly into DynLayer. Note: an official release does not necessarily have to wait for this code. Dan |
|
From: Scott A. L. <sc...@sc...> - 2000-12-07 23:32:28
|
Duh, I just answered my own question. In IE, the .doc property always
points the the window document. I just never noticed before, because
until now I was always looking for a specfic element with a unique ID.
Isn't that why "images[0]" is a no-no in DynAPI2? I think I remember
that from awhile back.
In any case, FYI: to get the links and images in loadpanel in IE5, after
the external content is loaded:
links = loadpanel.elm.all.tags("a");
images = loadpanel.elm.all.tags("img");
Scott Andrew LePera wrote:
>
> Okay, maybe not bizarre, but I can't figure it out.
>
> It seems that when using a loadpanel in IE5, the loading does something
> weird to the .doc property of the loadpanel. .doc no longer points to
> the loadpanel element but instead to the top-level document object in
> the browser. Has anyone else noticed this behavior? I'm working on a
> patch that I think will help solve this.
>
> --
> 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
--
scott andrew lepera
-----------------------------------
web stuff: www.scottandrew.com
music stuff: www.walkingbirds.com
|
|
From: <mi...@pr...> - 2000-12-07 23:17:42
|
Sorry for the formatting of that last post, let me try again...
Two questions...
===========
QUESTION 1:
===========
Does anybody know the real reason that we have both the removeChild/removeFromParent -AND- the deleteChild/deletFromParent functions?
I am asking because they are both SO similar... the only differences that I can find are as follows:
1) the remove methods move the object to the 'unassigned' array, while the delete methods do not (well, in ns4 the object gets added to the 'recycled' array)
2) the delete methods also deletes all of the children of the object, while the remove methods do not
At one time, didn't the remove methods add the object (after removing it & if the object's parent was not the dyndoc) to the object.dyndoc?
I could just be confused... :-)
===========
QUESTION 2:
===========
Does anybody know of a way to permanently delete a DynLayer (and all of it's children, properites, eventlisteners, object specific methods, etc...) entirely? No references left to it what-so-ever?
--proteanman
|
|
From: Robert R. <rra...@ya...> - 2000-12-07 23:05:21
|
I think its about time to create an official release that would include Dan's new wigets (since the one a sourceforge doesnt have any). A few things that I know need to be done before then: - make sure that the built version has correct semicolon placement - Fix scrollpane - in NS it wants to stop scrolling when you hold down the mouse on the down arrow. - Some API documentation in the format Pascal posted would be nice - I plan on removing images.js, slide.js, and sprite.js(?) in the next release. Here are some recent fixes I made: - DynImage should now fully replace images.js. The code has been imported into DynImage. DynImage is now a plugin to the DynAPI so that it will call DynImage.loadStart() - The scrollbar now will cancel the slide on mouseup - slide.js is no longer needed. Pathanim should now be a full replacement - Pushpanel should now not require an extra click to remove the bars. - Button now uses a DynImage - All of the examples should now be using DynImage.getImage instead of DynAPI.getImage - Probaly some others that I forgot. Please get the latest from CVS or (http://dynapi.sourceforge.net/snapshot) and test away so that we can make a release soon. -- // Robert Rainwater |
|
From: Scott A. L. <sc...@sc...> - 2000-12-07 23:02:41
|
The major difference between the two is that remove methods simply remove the DynLayer but do not destroy it. You can remove a DynLayer and then add it back, possibly to a new parent. When a DynLayer is removed, it returns to the "unassigned" state (meaning it has no parent and no DynDocument). The delete methods remove the DynLayer and destroy all internal references to it. When you delete a DynLayer, you cannot add it back. It's gone. You have to create a new one. That said, I wish there was some way to ensure that all references to a DynLayer object were destroyed -- as long as even one reference remains, the DynLayer will still exist, and the resources it uses will not be released. I don't think one exists; there's no way that I know of to automatically detect all references to an object and destroy them. Or is there? -- scott andrew lepera ----------------------------------- web stuff: www.scottandrew.com music stuff: www.walkingbirds.com |
|
From: Scott A. L. <sc...@sc...> - 2000-12-07 22:56:11
|
Okay, maybe not bizarre, but I can't figure it out. It seems that when using a loadpanel in IE5, the loading does something weird to the .doc property of the loadpanel. .doc no longer points to the loadpanel element but instead to the top-level document object in the browser. Has anyone else noticed this behavior? I'm working on a patch that I think will help solve this. -- scott andrew lepera ----------------------------------- web stuff: www.scottandrew.com music stuff: www.walkingbirds.com |
|
From: Michael L. <pro...@ms...> - 2000-12-07 22:36:24
|
Two questions...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
QUESTION 1:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Does anybody know the real reason that we have both the removeChild/remov=
eFromParent -AND- the deleteChild/deletFromParent functions?
I am asking because they are both SO similar... the only differences that=
I can find are as follows:
1) the remove methods move the object to the 'unassigned' array, whil=
e the delete methods do not (well, in ns4 the object gets added to the 'r=
ecycled' array)
2) the delete methods also deletes all of the children of the object,=
while the remove methods do not
At one time, didn't the remove methods add the object (after removing it =
& if the object's parent was not the dyndoc) to the object.dyndoc? =20
I could just be confused... :-)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
QUESTION 2:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Does anybody know of a way to permanently delete a DynLayer (and all of i=
t's children, properites, eventlisteners, object specific methods, etc...=
) entirely? No references left to it what-so-ever?
--proteanman<br clear=3Dall><hr>Get more from the Web. FREE MSN Explorer=
download : <a href=3D"http://explorer.msn.com">http://explorer.msn.com</=
a><br></p>
|
|
From: Dan S. <dy...@fu...> - 2000-12-07 22:16:14
|
Yeah I had a partially rewritten List, but it would also need to be slightly updated for the DynAPI2. In all likelyhood yours probably works the same if it was based of the older dynapi2 list before sourceforge. How bout putting it in CVS and if there's any changes needed I can look at my older one. Dan On Thu, Dec 07, 2000 at 01:22:44PM -0800, Scott Andrew LePera wrote: > Is anyone working on a list widget? I have a nice one lying around that > works great with DynAPI2 (although I'd have to retrofit it to use the > current Label widget instead of my own), but if Dan or someone else is > working on one I won't bother submitting it. > > -- > 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 |
|
From: Scott A. L. <sc...@sc...> - 2000-12-07 21:22:14
|
Is anyone working on a list widget? I have a nice one lying around that works great with DynAPI2 (although I'd have to retrofit it to use the current Label widget instead of my own), but if Dan or someone else is working on one I won't bother submitting it. -- scott andrew lepera ----------------------------------- web stuff: www.scottandrew.com music stuff: www.walkingbirds.com |
|
From: Scott A. L. <sc...@sc...> - 2000-12-07 19:56:47
|
I'm really enjoying the discussion this thread is producing, but it seems to me that, at this point, splitting the API up by browser shouldn't be a priority. I agree that the benefits of splitting are minimal at this point and would require lots of careful maintenance that a lot of people won't bother to do. I don't think imposing tight restrictions on development is really true to the spirit of this API. Once we decide to have official requirements -- whether it be splitting, an "official" widget model or inheritance scheme -- then we'll also have to have to impose rules so that people won't doing things that will break our precious standard. The only thing that should be standard for now is the core. Everything else can be done however you want to. If you wanted, you can do as Pascal did and use the DynAPI2 source to build in whatever modifications you desired. That doesn't mean that we won't do it in the future, though. -- scott andrew lepera ----------------------------------- web stuff: www.scottandrew.com music stuff: www.walkingbirds.com |
|
From: Robert R. <rra...@ya...> - 2000-12-07 19:44:27
|
Yes, thats great, but who is going to oversee all of this? Why can't we spend more time on testing and debugging the code that is there now. All of the stuff you are talking about can be done by creating a parser, but I don't feel it needs to be done to the official distro. -- // Robert Rainwater On 12/7/2000, 1:38:00 PM EST, Alexey wrote about "AW: [Dynapi-Dev] DynAPI build, Splitting files": >> browser will become inconsistent with each other when people make > This one could be solved: > 2) you need tests for all specific API calls and screenshots of > what must be (see Pascal page). > 1) you need definite group of people , who will run this > tests on all possible architectures Arch/OS/brows. > And they must notify all if they do not like to make tests > any more. >> changes to one and not the other. People will add "features" to some > This must be mirrored as "change to API" > in some TXT file with list of all object/methods. > CVS will make all work to keep who change what. > Idea of API chage must be approved by developers here in list. > Malx |
|
From: Robert R. <rra...@ya...> - 2000-12-07 19:40:05
|
If its OK, I can move the DynAPI images methods into DynImage. I've already done this with my local copy, and every thing is working fine. If we do this and remove images.js, then the scrollpane will also need to be changed so that is uses DynImage.getImage(). This can easily be done, and if there are no objections, I can make the changes. -- // Robert Rainwater On 12/7/2000, 3:01:22 PM EST, Dan wrote about "[Dynapi-Dev] getImage": > 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 mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
|
From: Alexey M. <ma...@ca...> - 2000-12-07 18:52:38
|
> Netscape and Microsoft to stick to the W3C standard.. (and then making sure
> that the W3C doesn't change everything every year :-)
Have you heard about "emulation" of brouser DOM library?
if(ie) {document.layers=new Array()
document.layers[0]=document.all[xxx]
etc....
}
So you really could make library,
which makes browser W3C compatible
You need to make "document.getElementById = My_nn_func()"
and others....
But is it worth to do so?
(also could in IE be done catching of Event , when user makes a.a="b" ?)
> Also I don't see where you could make the speed advantages? the slowness of
"if" statemant always use much CPU.
and here it is in cycles.
> in IE it looks like it's rerendering everything on screen and I believe
> that's the main problem,
:)
Netscape4 will not rerender - it also called a problem of NN :)))
(you could do it manually if you know function name - I do not :-/
Malx
|
|
From: Alexey M. <ma...@ca...> - 2000-12-07 18:39:53
|
> browser will become inconsistent with each other when people make This one could be solved: 2) you need tests for all specific API calls and screenshots of what must be (see Pascal page). 1) you need definite group of people , who will run this tests on all possible architectures Arch/OS/brows. And they must notify all if they do not like to make tests any more. > changes to one and not the other. People will add "features" to some This must be mirrored as "change to API" in some TXT file with list of all object/methods. CVS will make all work to keep who change what. Idea of API chage must be approved by developers here in list. Malx -- There is no thing in the world, which is more powerfull, than default |
|
From: Dan S. <dy...@fu...> - 2000-12-07 18:37:25
|
I would much sooner do Pascals earlier suggestion of creating different methods and adding them based on the browser:
if (is.ns4) DynLayer.prototype.moveTo = DynLayer_moveToNS4;
if (is.ie4) ...
function DynLayer_moveToNS4() {}
But keep all the code in the same file. After compressing the DynAPI the difference in file size is almost a non-issue (like 1 or 2Kb difference). It's not out of the question to have a script that splits the files for build releases though, but it by no means has to be done right away.
Dan
On Thu, Dec 07, 2000 at 07:09:10PM +0100, Pascal Bestebroer wrote:
> An API is a middle-layer between the code and the "environment" seeing as
> you want to have cross-browser code it sounds better to see one single api
> file that takes care of all browsers.. not having seperate files for every
> browser (that would create a DHTML library, not an API.. simple solution
> change the name to DynLib :)
>
> Developing in seperate files for seperate browsers WILL create seperate
> things, even though there is talk about setting "rules" for the development,
> we have to face it that streaming this whole project is not something any of
> us is good at.. so sticking to the development rules (even when you could do
> cool things like using behaviours in IE5 for filter effects and stuff) will
> be, in my opinion, impossible to maintain. Almost the same as asking
> Netscape and Microsoft to stick to the W3C standard.. (and then making sure
> that the W3C doesn't change everything every year :-)
>
> Someone debugging NN code should just skip the part that says if (is.ie) ..
> that's not a hard thing to do.
>
> Also I don't see where you could make the speed advantages? the slowness of
> it all is within the browsers.. try changing a single stylesheet property,
> in IE it looks like it's rerendering everything on screen and I believe
> that's the main problem, so how can you increase speed when splitting things
> up?
>
> "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."
>
> Then why use a cross-browser API (or library for that matter)?
>
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens SReindl
> > Verzonden: donderdag 7 december 2000 18:13
> > Aan: dyn...@li...
> > Onderwerp: 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
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Dan S. <dy...@fu...> - 2000-12-07 18:20:52
|
This crossed my mind, however I don't remember actually ever using slideBy(). It's not needed cause you can just do the addition yourself if needed:
obj.slideTo(obj.x+50,obj.y+50);
Dan
On Thu, Dec 07, 2000 at 12:36:18PM -0500, Robert Rainwater wrote:
>
> 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
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Pascal B. <pa...@dy...> - 2000-12-07 18:05:34
|
An API is a middle-layer between the code and the "environment" seeing as you want to have cross-browser code it sounds better to see one single api file that takes care of all browsers.. not having seperate files for every browser (that would create a DHTML library, not an API.. simple solution change the name to DynLib :) Developing in seperate files for seperate browsers WILL create seperate things, even though there is talk about setting "rules" for the development, we have to face it that streaming this whole project is not something any of us is good at.. so sticking to the development rules (even when you could do cool things like using behaviours in IE5 for filter effects and stuff) will be, in my opinion, impossible to maintain. Almost the same as asking Netscape and Microsoft to stick to the W3C standard.. (and then making sure that the W3C doesn't change everything every year :-) Someone debugging NN code should just skip the part that says if (is.ie) .. that's not a hard thing to do. Also I don't see where you could make the speed advantages? the slowness of it all is within the browsers.. try changing a single stylesheet property, in IE it looks like it's rerendering everything on screen and I believe that's the main problem, so how can you increase speed when splitting things up? "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." Then why use a cross-browser API (or library for that matter)? Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens SReindl > Verzonden: donderdag 7 december 2000 18:13 > Aan: dyn...@li... > Onderwerp: 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 > |
|
From: Scott A. L. <sc...@sc...> - 2000-12-07 17:47:34
|
Okay, that's my fault because I totally forgot that DynAPI.getImage was moved to the images.js extension ::smacks forehead:: Dan Steinman wrote: > > 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 > -- scott andrew lepera ----------------------------------- web stuff: www.scottandrew.com music stuff: www.walkingbirds.com |
175 messages has been excluded from this view by a project administrator.
