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: Richard :o <ma...@ri...> - 2000-12-12 04:15:49
|
<html> <head> <title>CoreLib example</title> </head> <script language="Javascript" src="../src/dynapi.js"></script> <script language="Javascript"> DynAPI.setLibraryPath('../src/lib/') DynAPI.include('dynapi.api.*') //DynAPI.include('dynapi.ext.slide.js') //original dynacore include DynAPI.include('dynapi.util.thread.js'); //dynapi include DynAPI.include('dynapi.util.pathanim.js'); //dynapi include DynAPI.onLoad=function() { myLayer = new DynLayer() myLayer.setSize(100,100) myLayer.setBgColor('#c0c0c0') myLayer.moveTo(100,100) myLayer.setSize(250,250) myLayer.do_slide=function() { myLayer.slideTo(0,null,10,20) } myLayer.events=new EventListener(myLayer) myLayer.events.onpathstop=function(e) { me=e.getTarget() if (me.x==0) me.slideTo(DynAPI.document.w-me.w,null,10,20) else me.slideTo(0,null,10,20) } myLayer.addEventListener(myLayer.events) DynAPI.document.addChild(myLayer) myLayer.do_slide() } </script> <body> </body> </html> |
From: Scott A. L. <sc...@sc...> - 2000-12-12 03:11:38
|
On the face of it I don't think it's entirely necessary unless your goal is to create a large hierarchy of objects, in which case you could just use the SuperClass object as your base object and subclass everything from there. The WidgetX model will create an extra instance of the DynLayer class in the DynLayer unassigned[] collection, for every constructor that uses "WidgetName.prototype = new DynLayer();" to fake inheritance. But that shouldn't break anything, just as long as unassigned[] remains private and you don't loop through it for anything. ------ scott andrew lepera sc...@sc... web stuff: www.scottandrew.com music stuff: www.walkingbirds.com -----Original Message----- From: Brandon Myers <bnd...@ho...> To: dyn...@li... <dyn...@li...> Date: Monday, December 11, 2000 6:14 PM Subject: RE: [Dynapi-Dev] Inheritance >>> Wouldn't it be better to say: >>> MyObject.prototype = DynObject.prototype > >>I guess this would only create a pointer, so that changes to >>MyObject.prototype would affect DynObject.prototype > >Very good point.. so should we then loop through the prototypes?.. >Assigning the individual functions, but not the entire prototype? >Do this to avoid setting variables or objects which would then be shared by >all instances of the subclass. > >function Label() { > this.theLayer=new DynLayer(); >} > >Label.prototype=new DynObject(); > >Then..... > >function Button() { > this.theLayer.addEventListner(Button.mouseEvents); >// More stuff here too. >} >Button.mouseEvents=...blah blah blah.... >Button.prototype=new Label(); // Cause a button is just a label with events. > >Now.. guess what? All instances of Button will share the same DynLayer >reference. >Is this what is intended? I don't think so. > >Now.. don't get on my case that I used Dan's original widget model.. it's >just a practical example. Any object in place of the "theLayer" object would >have the same problems. > >-----Original Message----- >From: dyn...@li... >[mailto:dyn...@li...]On Behalf Of Simon Dicon >Montford >Sent: Monday, December 11, 2000 6:12 PM >To: dyn...@li... >Subject: RE: [Dynapi-Dev] Inheritance > > >> I was wondering the point of this line when inheriting objects: >> >> MyObject.prototype = new DynObject(); > >It's so that any changes to DynObject.prototype at runtime will >be reflected in MyObject.prototype > >> Wouldn't it be better to say: >> MyObject.prototype = DynObject.prototype > >I guess this would only create a pointer, so that changes to >MyObject.prototype would affect DynObject.prototype > >SD >_______________________________________________ >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: Joachim L. <lu...@ho...> - 2000-12-12 01:03:05
|
At 2000-12-12 00:03 , you wrote: >I think it's always better not to say MyObject.prototype=new DynObject (That makes me understand SuperClass better...) >Reasoning: We shouldn't want instance variables to be prototype variables. >All variables initialized within the DynObject constructor will become part >of the prototype. >Why do we want this? Variables should be initialized at the time the >instance is created, no sooner. >I remember having a problem when I was trying to use the prototype to make >sure a variable was available at the time the instance was created. I found >that the variable space was shared. Especially if a varaible is an object. >This could cause undefined behavior of other widgets downline. Well, that's the problem with the prototype-based way. Because the prototype is an object that is used when looking up a property/method that the "class" doesn't implement itself, setting unique properties should be done in the creator function instead, with a call to the creator function for the immediate superclass. For example the ListItem class: function ListItem(text,value) { this.superClass = Label; this.superClass(text); this.value = value; ... } ListItem.prototype = new Label(); Perfect, except for the fact that one object is wasted to set the prototype. But the prototype chain is right! >I like the idea of setting the prototypes equal.. it seems more direct, and >doesn't set instances of objects as prototypes of another. But that's the way inheritance in JavaScript works... And how would it work if you want to make a subclass of a subclass? And call a superclass' method? /Lunna |
From: Brandon M. <bnd...@ho...> - 2000-12-12 00:34:37
|
>> Wouldn't it be better to say: >> MyObject.prototype = DynObject.prototype >I guess this would only create a pointer, so that changes to >MyObject.prototype would affect DynObject.prototype Very good point.. so should we then loop through the prototypes?.. Assigning the individual functions, but not the entire prototype? Do this to avoid setting variables or objects which would then be shared by all instances of the subclass. function Label() { this.theLayer=new DynLayer(); } Label.prototype=new DynObject(); Then..... function Button() { this.theLayer.addEventListner(Button.mouseEvents); // More stuff here too. } Button.mouseEvents=...blah blah blah.... Button.prototype=new Label(); // Cause a button is just a label with events. Now.. guess what? All instances of Button will share the same DynLayer reference. Is this what is intended? I don't think so. Now.. don't get on my case that I used Dan's original widget model.. it's just a practical example. Any object in place of the "theLayer" object would have the same problems. -----Original Message----- From: dyn...@li... [mailto:dyn...@li...]On Behalf Of Simon Dicon Montford Sent: Monday, December 11, 2000 6:12 PM To: dyn...@li... Subject: RE: [Dynapi-Dev] Inheritance > I was wondering the point of this line when inheriting objects: > > MyObject.prototype = new DynObject(); It's so that any changes to DynObject.prototype at runtime will be reflected in MyObject.prototype > Wouldn't it be better to say: > MyObject.prototype = DynObject.prototype I guess this would only create a pointer, so that changes to MyObject.prototype would affect DynObject.prototype SD _______________________________________________ Dynapi-Dev mailing list Dyn...@li... http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Simon D. M. <di...@bi...> - 2000-12-11 23:20:28
|
> I was wondering the point of this line when inheriting objects: > > MyObject.prototype = new DynObject(); It's so that any changes to DynObject.prototype at runtime will be reflected in MyObject.prototype > Wouldn't it be better to say: > MyObject.prototype = DynObject.prototype I guess this would only create a pointer, so that changes to MyObject.prototype would affect DynObject.prototype SD |
From: Brandon M. <bnd...@ho...> - 2000-12-11 23:01:42
|
I think it's always better not to say MyObject.prototype=new DynObject Reasoning: We shouldn't want instance variables to be prototype variables. All variables initialized within the DynObject constructor will become part of the prototype. Why do we want this? Variables should be initialized at the time the instance is created, no sooner. I remember having a problem when I was trying to use the prototype to make sure a variable was available at the time the instance was created. I found that the variable space was shared. Especially if a varaible is an object. This could cause undefined behavior of other widgets downline. I like the idea of setting the prototypes equal.. it seems more direct, and doesn't set instances of objects as prototypes of another. ----- Original Message ----- From: "Robert Rainwater" <rra...@ya...> To: "DynAPI Development List" <dyn...@li...> Sent: Monday, December 11, 2000 3:57 PM Subject: [Dynapi-Dev] Inheritance > > I was wondering the point of this line when inheriting objects: > > MyObject.prototype = new DynObject(); > > Wouldn't it be better to say: > MyObject.prototype = DynObject.prototype > > Because in your MyObject constructor you will be saying: > this.DynObject = DynObject; > this.DynObject(); > > so all of the properties in the DynObject constructor will be > initialized, and the MyObject.prototype = DynObject.prototype line > will set all of the methods equal to the MyObject. Using the first > method you are always calling the constructor an extra time that is > not needed (or is it?). > > -- > // Robert Rainwater > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Scott A. L. <sc...@sc...> - 2000-12-11 23:01:39
|
> Wouldn't it be better to say: > MyObject.prototype = DynObject.prototype I think this would cause problems when more than one object inherits from the DynObject. Using "new" ensures that the widget prototype is unique and won't be shared with other widgets that also use DynObject as their parent class. For example: let's say you have two widgets that inherit from DynObject, Widget A and Widget B: WidgetA.prototype = DynObject.protoype WidgetB.prototype = DynObject.protoype If Widget A overwrites a method of DynObject, it will also overwrite it for Widget B, because they share the prototype of DynObject: WidgetA.prototype.setSize = function(){ /*whatever*/} <-- this will overwrite the method for WidgetB, too. So I would think that using "new DynObject" instead would keep these unique and seperate. However, you brought up a very good point earlier in that using "new DynLayer" to create the prototypes for widgets creates an instance of DynLayer that ends up in the unassigned array: WidgetA.prototype = new DynLayer(); <-- this is a new instance, and ends up in unassigned[] This is probably not fatal, though, as it never gets assigned to a document. But it happens for every widget that uses this method. -- scott andrew lepera ----------------------------------- web stuff: www.scottandrew.com music stuff: www.walkingbirds.com |
From: Dan S. <dy...@fu...> - 2000-12-11 22:18:25
|
Already done and working. I've actually got quite a large amount of fixes/changes coming due to a lot of problems with widgets using the new inline creation system. Currently there's only 1 very perplexing problem when using Button in another widget (pushpanel/scrollpane in particular) that is holding it back. I will be sure it's all working in IE4 before releasing anything to CVS. Did anyone figure out exactly what to do to get IE4/5 to stop selecting text for Label? Dan On Mon, Dec 11, 2000 at 03:28:27PM -0500, Robert Rainwater wrote: > > The main issue with DynImage is getting the images width and height > when it is done loading. Then the dynimage has to update itself and > invoke some kind of event saying its ready. So ideally, you don't > need to specify the w/h if you want to use the actual width/height. > Because in the Button widget, it has to be able to resize itself, but > it can't do so until it knows the image's width and height, unless you > specify it. > > I beleive in IE if you say x = new Image(w||0,h||0), it will > initialize the w/h to 0 even after the load (if w or h is 0), so thats > one of the problems with the DynImage as it is now. > > -- > // Robert Rainwater > > On 12/10/2000, 4:38:27 AM EST, Eytan wrote about "[Dynapi-Dev] Button/DynImage - I am fixing this": > > > I have looked at how the images work. I have made somthing similair but I > > find more simple. I created a TImage which in its constructor creates a > > "real" image (as in an IMG tag) then I can play with it using function I > > have created. Resizing would simply mean call ImgName.width and changing it. > > > 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 |
From: Robert R. <rra...@ya...> - 2000-12-11 20:55:08
|
I was wondering the point of this line when inheriting objects: MyObject.prototype = new DynObject(); Wouldn't it be better to say: MyObject.prototype = DynObject.prototype Because in your MyObject constructor you will be saying: this.DynObject = DynObject; this.DynObject(); so all of the properties in the DynObject constructor will be initialized, and the MyObject.prototype = DynObject.prototype line will set all of the methods equal to the MyObject. Using the first method you are always calling the constructor an extra time that is not needed (or is it?). -- // Robert Rainwater |
From: Robert R. <rra...@ya...> - 2000-12-11 20:26:03
|
The main issue with DynImage is getting the images width and height when it is done loading. Then the dynimage has to update itself and invoke some kind of event saying its ready. So ideally, you don't need to specify the w/h if you want to use the actual width/height. Because in the Button widget, it has to be able to resize itself, but it can't do so until it knows the image's width and height, unless you specify it. I beleive in IE if you say x = new Image(w||0,h||0), it will initialize the w/h to 0 even after the load (if w or h is 0), so thats one of the problems with the DynImage as it is now. -- // Robert Rainwater On 12/10/2000, 4:38:27 AM EST, Eytan wrote about "[Dynapi-Dev] Button/DynImage - I am fixing this": > I have looked at how the images work. I have made somthing similair but I > find more simple. I created a TImage which in its constructor creates a > "real" image (as in an IMG tag) then I can play with it using function I > have created. Resizing would simply mean call ImgName.width and changing it. > 8an > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Robert R. <rra...@ya...> - 2000-12-11 19:32:19
|
How about an updateText() function added to the label widget that would call setText(). -- // Robert Rainwater On 12/10/2000, 5:18:11 PM EST, Scott wrote about "[Dynapi-Dev] Label text selection": > Yeah, that's something I overlooked. setText needs to be called in order to > see an immediate change, but there's no reason to call setText every time > you change a label property. Doesn't setHTML also fire a load event, too? > An addition boolean passed to each of the setter method could determine if > the text is to be re-rendered. or optionally, we could just require that > setText should be invoked manually, rather than automatically from within > another setter method. > ------ > scott andrew lepera > sc...@sc... > web stuff: www.scottandrew.com > music stuff: www.walkingbirds.com > -----Original Message----- > From: Robert Rainwater <rra...@ya...> > To: DynAPI Development List <dyn...@li...> > Date: Friday, December 08, 2000 9:05 PM > Subject: Re: [Dynapi-Dev] Label text selection >> >>Another problem witht the list/label widgets is the many calls to >>setText. In ListItem, the onmouseout and mousemouse over makes to >>different calls to change the font (forecolor, textcolor). Each one >>of these calls, calls setText which sets the html. >> >>Maybe we should pass a boolean to the font change functions, that >>decides whether or not to call setText. >> >>-- >>// Robert Rainwater >> >>On 12/8/2000, 6:37:49 PM EST, Scott wrote about "[Dynapi-Dev] Label text > selection": >> >>> There's a small snag in Label. In IE, when you use setSelectable to >>> prevent text from being selected with the mouse, you're also cancelling >>> the browser event. This can also cancel events on the label itself. >>> For example, if you build a list item out of a label with rollover color >>> change events, sometimes the label text will cancel the onmouseout >>> event. If you mouseover the list fast enough you may end up with >>> several items stuck in the rollover position. This could cause problems >>> with other widgets that use Label. >> >>> In light of this, I'm wondering if we should restore the optional >>> addCover() method that uses a physical layer to cover text. If you >>> don't need it, just use setSelectable. >> >> >>_______________________________________________ >>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: <hen...@ri...> - 2000-12-11 18:46:47
|
Thanks, I still have a few things i want to implement in the keyevents, = but as a preliminary release I think it works. Now all I need is some = feedback and compability reports. And by all means, go right ahead and = include the keyboard events - the more possability I get the feedback I = need to compability prove it as much as possible (I really want to make = it proof for at least most browsers, if for nothing else for my own = projects sake). Henrik ----- Original Message -----=20 From: Pascal Bestebroer=20 To: dyn...@li...=20 Sent: Sunday, December 10, 2000 9:28 PM Subject: RE: [Dynapi-Dev] DynAPI2 Ke(board) events Damn, didn't know about this line being possible: =20 String.fromCharCode(this.which).toLowerCase() =20 Great work! Mind if I include it into Dynacore aswell :-) =20 cheers, Pascal Bestebroer pa...@dy... http://www.dynamic-core.net=20 -----Oorspronkelijk bericht----- Van: dyn...@li... = [mailto:dyn...@li...]Namens Henrik V=E5glin Verzonden: zondag 10 december 2000 19:59 Aan: dyn...@li... Onderwerp: [Dynapi-Dev] DynAPI2 Ke(board) events Hello developers I have put together a keyevents extension for DynAPI2 - as of = release 2000.11.07, which is the latest official to my knowledge. I've = made it for a project called ComicCreation, which is the project I'm = working on implementing the DynAPI2 into. The keyevents are meant to be the same type of alternative UI = functionality to mouseevents as keyboard shortcuts is to mousemanouveres = in regular applications (windowbased interfaces). They should be = essential for the serious webapp developer, who takes care of the fact = that sometimes users rather uses the keyboard or simply don't have a = mouse but still need a way to reach the feature (without hazzle). If no = other, most developers are more often to use the keyboard than the mouse = - so probably for most in here. Now, I set the ALT key to be working as controller key, since using = single keys are already assigned for text input. I chose to limit one = key as the only valid modifier, since I'm aware that too many key-combos = are already assigned to application functionality. I'm far from sure = this is a wise choice though, since I've got a hunch that ALT-combos = won't work in every enviroment either. If somebody have any experience = or would care to try out what modifier key works crossbrowser on = different systems I'd most apprieate to be notified so that I can set = the correct controller key or combo for char keys to work as function = keys. thanks all for your time and efforts with dynAPI Henrik V=E5glin=20 |
From: Josep M. i T. <jm...@ne...> - 2000-12-11 18:26:21
|
Hi! I think I've found a bug in dynimage.js that shows up in NS4.7 but not in IE4 (NS6 hangs on my Win NT 4.0 :-( ). File: gui/dynapi.js File date: 20:27, 8 Dec 2000; taken from the beta .zip in SourceForge yesterday. Line: 100 was: DynImage.timerId=setTimeout(DynImage+'.loadercheck()',25); should be: DynImage.timerId=setTimeout('DynImage.loadercheck()',25); Best regards, Josep |
From: Pascal B. <pb...@oi...> - 2000-12-11 16:00:45
|
The problem with this (dynapi) situation and your example is that in the DynAPI not ALL code is browser independend, in your example all text would be different for every language. "..but it's important to see all the versions together in order to be sure that any change is done simultaneoulsy" yes. "split the files and let the german version be done by a native german speaking (if available)" I think when you'r doing cross-browser dhtml you should already be aware of what browsers can do, so I don't think this applies. If you don't know the capabilities of both browsers you will get the differences in the implementation, something we don't want because we're creating a cross-browser api that should work on all browser in the same way with the same functionality. Pascal Bestebroer pb...@oi... http://www.oibv.com -----Oorspronkelijk bericht----- Van: dyn...@li... [mailto:dyn...@li...]Namens Stephan Reindl Verzonden: maandag 11 december 2000 15:53 Aan: dyn...@li... Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files Oh come on. If you're supposed to write an international site for visitors in 5 languages, would you really consider writing (and editing) all the different texts, labels, figure captions, etc in ONE file only and separating the languages by deeply nested if`s ? Would you say, ok, I don't know german so well, but it's important to see all the versions together in order to be sure that any change is done simultaneoulsy. I try to learn german (and french and kisuaheli, etc.) Or would you prefer to define the "look & feel" of the site, split the files and let the german version be done by a native german speaking (if available)? Stephan > > What advantage would you gain by splitting up your example? Speed > wise, that is not the reason for loading taking a long time. The > speed problems are due to DynLayer creation. If you haven't seen yet, > Dan is creating a new inline dynlayer creation system that will speed > up this process. While splitting up the core files may seem nice, it > offers no real advantage. Especially with the new jspack files, the > file sizes are going to be small anyways. > > -- _______________________________________________ Dynapi-Dev mailing list Dyn...@li... http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Brandon M. <bnd...@ho...> - 2000-12-11 15:48:23
|
I'm afraid you missed the point of this thread, but at the same time, you've stumbled upon another feature that would be nice to have. Especially since the purpose of this API is to provide functions for a user interface. So, why not build in Internationalization functions? A single file can contain the text for a language... multiple files, multiple languages. The functions simply get the text for any particular language. Oops... this would also require some sort of widget standard so that the same internationalization method would work across all widgets. The widgets should pull it's text from the same object. A simple standard of: WText.OK="Ok"; WText.CANCEL="Cancel"; WText.NO="No"; Why have a different object, or different properties of the same opbject point to the same text? It's just a waste of memory. I would release this code, but as Dan should know... I'm in a tough spot with releasing what I have at the moment. ----- Original Message ----- From: "Stephan Reindl" <SR...@la...> To: <dyn...@li...> Sent: Monday, December 11, 2000 9:20 AM Subject: AW: [Dynapi-Dev] DynAPI build, Splitting files > Oh come on. If you're supposed to write an international site for visitors > in 5 languages, would you really consider writing (and editing) all the > different texts, labels, figure captions, etc in ONE file only and > separating the languages by deeply nested if`s ? > Would you say, ok, I don't know german so well, but it's important to see > all the versions together in order to be sure that any change is done > simultaneoulsy. I try to learn german (and french and kisuaheli, etc.) > Or would you prefer to define the "look & feel" of the site, split the files > and let the german version be done by a native german speaking (if > available)? > > Stephan > > > > > > What advantage would you gain by splitting up your example? Speed > > wise, that is not the reason for loading taking a long time. The > > speed problems are due to DynLayer creation. If you haven't seen yet, > > Dan is creating a new inline dynlayer creation system that will speed > > up this process. While splitting up the core files may seem nice, it > > offers no real advantage. Especially with the new jspack files, the > > file sizes are going to be small anyways. > > > > -- > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev > |
From: Jordi 'I. M. <jmi...@or...> - 2000-12-11 15:33:54
|
As long as you are sure the german writer, the english writer and the french writer are writing exactly the same, and there is one person telling them what do they have to write and what do they have to tell. Otherwise, you'll end up with a site that depending on the language you choose, the information presented and the tone of the speech is totally different. The issue here are not the benefits of splitting-up the files ( we all know them ) but the danger of desynchronization between browsers that comes together with the fact that ( regardless of our good intentions and constant discussion ) we do not have a solid guideline, a plot and a leading man who picks up all the people's work and decides what goes in and what is discarted due to not being cross-browser, a leading man that you would have in the multi-language situation you exposed. If I was sure that having split files would only result in having split files and not split functionalities, I'd join the "split" cause, but seeing the APIs evolution in the last year, I don't think we'd make it. If I write 'would' one more time, I'll go nuts. Stephan Reindl wrote: > Oh come on. If you're supposed to write an international site for visitors > in 5 languages, would you really consider writing (and editing) all the > different texts, labels, figure captions, etc in ONE file only and > separating the languages by deeply nested if`s ? > Would you say, ok, I don't know german so well, but it's important to see > all the versions together in order to be sure that any change is done > simultaneoulsy. I try to learn german (and french and kisuaheli, etc.) > Or would you prefer to define the "look & feel" of the site, split the files > and let the german version be done by a native german speaking (if > available)? > > Stephan > > > > > What advantage would you gain by splitting up your example? Speed > > wise, that is not the reason for loading taking a long time. The > > speed problems are due to DynLayer creation. If you haven't seen yet, > > Dan is creating a new inline dynlayer creation system that will speed > > up this process. While splitting up the core files may seem nice, it > > offers no real advantage. Especially with the new jspack files, the > > file sizes are going to be small anyways. > > > > -- > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Jared N. <ja...@aa...> - 2000-12-11 15:04:44
|
per page memory management was abandoned, as far as I know, in Netscape version 2.0. IE3+ and NS4+ use a variation of the mark and sweep garbage collection algorithm. |
From: Stephan R. <SR...@la...> - 2000-12-11 14:24:09
|
Oh come on. If you're supposed to write an international site for visitors in 5 languages, would you really consider writing (and editing) all the different texts, labels, figure captions, etc in ONE file only and separating the languages by deeply nested if`s ? Would you say, ok, I don't know german so well, but it's important to see all the versions together in order to be sure that any change is done simultaneoulsy. I try to learn german (and french and kisuaheli, etc.) Or would you prefer to define the "look & feel" of the site, split the files and let the german version be done by a native german speaking (if available)? Stephan > > What advantage would you gain by splitting up your example? Speed > wise, that is not the reason for loading taking a long time. The > speed problems are due to DynLayer creation. If you haven't seen yet, > Dan is creating a new inline dynlayer creation system that will speed > up this process. While splitting up the core files may seem nice, it > offers no real advantage. Especially with the new jspack files, the > file sizes are going to be small anyways. > > -- |
From: Pascal B. <pb...@oi...> - 2000-12-11 13:06:32
|
something I have done in my Dynacore distribution (see post from yesterday). Pascal Bestebroer pb...@oi... http://www.oibv.com -----Oorspronkelijk bericht----- Van: dyn...@li... [mailto:dyn...@li...]Namens Robert Rainwater Verzonden: maandag 11 december 2000 14:05 Aan: DynAPI Development List Onderwerp: Re[2]: [Dynapi-Dev] DynAPI build, Splitting files If you mean doing something like this: if (is.ns) DynLayer.prototype.setHTML = function() {} } Then, it looks like you would only use it in the setX/Y, setBgImage, and setHTML functions. However, this would also require moving the BrowserDetection function into the dynapi.js or dynlayer.js, because it will not be loaded when the dynlayer is loading. -- // Robert Rainwater On 12/10/2000, 10:54:06 PM EST, Doug wrote about "[Dynapi-Dev] DynAPI build, Splitting files": > Alreigth then, how about a suggestion made earlier (don't recall by whom).. > Put some code into dynapi.js which will > 'complie' the code for the specific browser in use? > we can use place-holder vars (constants) and have dynapi.js set them > according to > what browser/platform is in use.. > Doug Melvin > ----- Original Message ----- > From: "Pascal Bestebroer" <pa...@dy...> > To: <dyn...@li...> > Sent: Sunday, December 10, 2000 2:51 AM > Subject: RE: [Dynapi-Dev] DynAPI build, Splitting files >> >> Once you split up parts of the API for every browser (that could > eventually >> include Opera, and other flavours) it means that people will start > focusing >> on a single browser because that's the browser they'll be using. Ofcourse >> this is already being done on a smaller scale (Dan's main focus seems to > be >> Netscape, and my focus is more IE5+) but at this point because of the code >> being one , we know that what ever we do should also work Netscape.. once >> you split things up I think this "awareness" will disappear and people > will >> just enhance the code for that single browser and let someone else worry >> about the other browsers files. >> >> "All this is done only to define two basic paisr of vars. Terrible. And >> impossible just to skip the nn stuff, becoause it's not clear, what refers >> to nn but only what is not for ie. I have to go through it and to >> learn the" >> >> that's correct, just two basic pairs of vars, so you want to split all > code >> up for simple things like these? And the fact that you have to go thru it >> and learn the differences is exactly my point, if you have the chance to >> only do your coding for IE, you will forget about NS and this might cause >> you to implement things in IE that are not possible in NS. Ofcourse this >> means we're holding back one browser because of the incompatibilities with >> the other, but that's the problem with cross-browser coding, and if you > need >> that extra functionality you should added it in your own code, not in the >> general API. >> >> The problem with speed that everybody talks about is not such a big issue, >> we're not developing for 386 or 486 machines anymore, Pentium machines > don't >> take 2 or 3 clock-cycles to do a simple IF statement. Besides the IF >> statements are only called at initialisation and when changing styles, the >> main bottle-neck is not the IF statement but the time it takes browsers to >> redo the style sheet (and rerender things). This is just a browser > problem, >> not a code problem. >> >> And ofcourse size isn't such a big issue neither, seeing that most of the >> differences (I know, not all) are done on single lines as you pointed out: >> >> is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset >> >> this will only be a few bytes difference once you split it up: >> >> e.x+document.body.scrollLeft >> >> so maybe you save some bytes with the split but you have to include all >> files multiple times and maintain all files multiple times for your site > to >> look good on all browsers. >> >> >> apologies for the long post :) >> >> cya, >> >> Pascal Bestebroer >> pa...@dy... >> http://www.dynamic-core.net >> >> > -----Oorspronkelijk bericht----- >> > Van: dyn...@li... >> > [mailto:dyn...@li...]Namens SReindl >> > Verzonden: zaterdag 9 december 2000 9:14 >> > Aan: dyn...@li... >> > Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files >> > >> > >> > Well, call it as you like: Lib ode API, ... An API has the task to > supply >> > you with a unique set of functions in order to perform some development >> > tasks. In this case this is cross browser compatible programming of web >> > sites (btw, an API can be stored in a lib ;-)) >> > I agree, that the API is not meant to be a play ground for fancy >> > stuff which >> > may be possible only for one particular browser. >> > But I don't see why the "streaming of the project" should be more work > for >> > separate files than for monolithic ones. >> > It's the definition of the basis of functions which is important, and > this >> > task has already been done, since the DynAPI is up and running. >> > >> > Look at this piece (from events.js): >> > >> > this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset >> > >> > this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset >> > this.x=is.ie?e.offsetX:e.layerX >> > this.y=is.ie?e.offsetY:e.layerY >> > var b = is.ie?e.button:e.which >> > if (is.ie){ >> > if (b==2) b = 3 >> > else if (b==4) b = 2 >> > } else { } >> > All this is done only to define two basic paisr of vars. Terrible. And >> > impossible just to skip the nn stuff, becoause it's not clear, what > refers >> > to nn but only what is not for ie. I have to go through it and to >> > learn the >> > syntax of several browsers (document.body.scrollLeft vs >> > window.pageXOffset, >> > etc., and do not forget the sign). >> > >> > My >> > > "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." >> > if of course *an example* only and not the goal of my programs. >> > >> > last not least, in addition to decrease in loading and rendering >> > time there >> > is one more feature which speaks for a split: control over >> > completeness. If >> > you have to assure that your implementation is complete you will have to >> > code all the functions. The chance just to forget an if branch is > smaller. >> > >> > I do not say that cross browser compatibility should be given up, >> > I think of >> > how this task can be done in a more transparent way. >> > 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 _______________________________________________ Dynapi-Dev mailing list Dyn...@li... http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Robert R. <rra...@ya...> - 2000-12-11 12:31:13
|
If you mean doing something like this: if (is.ns) DynLayer.prototype.setHTML = function() {} } Then, it looks like you would only use it in the setX/Y, setBgImage, and setHTML functions. However, this would also require moving the BrowserDetection function into the dynapi.js or dynlayer.js, because it will not be loaded when the dynlayer is loading. -- // Robert Rainwater On 12/10/2000, 10:54:06 PM EST, Doug wrote about "[Dynapi-Dev] DynAPI build, Splitting files": > Alreigth then, how about a suggestion made earlier (don't recall by whom).. > Put some code into dynapi.js which will > 'complie' the code for the specific browser in use? > we can use place-holder vars (constants) and have dynapi.js set them > according to > what browser/platform is in use.. > Doug Melvin > ----- Original Message ----- > From: "Pascal Bestebroer" <pa...@dy...> > To: <dyn...@li...> > Sent: Sunday, December 10, 2000 2:51 AM > Subject: RE: [Dynapi-Dev] DynAPI build, Splitting files >> >> Once you split up parts of the API for every browser (that could > eventually >> include Opera, and other flavours) it means that people will start > focusing >> on a single browser because that's the browser they'll be using. Ofcourse >> this is already being done on a smaller scale (Dan's main focus seems to > be >> Netscape, and my focus is more IE5+) but at this point because of the code >> being one , we know that what ever we do should also work Netscape.. once >> you split things up I think this "awareness" will disappear and people > will >> just enhance the code for that single browser and let someone else worry >> about the other browsers files. >> >> "All this is done only to define two basic paisr of vars. Terrible. And >> impossible just to skip the nn stuff, becoause it's not clear, what refers >> to nn but only what is not for ie. I have to go through it and to >> learn the" >> >> that's correct, just two basic pairs of vars, so you want to split all > code >> up for simple things like these? And the fact that you have to go thru it >> and learn the differences is exactly my point, if you have the chance to >> only do your coding for IE, you will forget about NS and this might cause >> you to implement things in IE that are not possible in NS. Ofcourse this >> means we're holding back one browser because of the incompatibilities with >> the other, but that's the problem with cross-browser coding, and if you > need >> that extra functionality you should added it in your own code, not in the >> general API. >> >> The problem with speed that everybody talks about is not such a big issue, >> we're not developing for 386 or 486 machines anymore, Pentium machines > don't >> take 2 or 3 clock-cycles to do a simple IF statement. Besides the IF >> statements are only called at initialisation and when changing styles, the >> main bottle-neck is not the IF statement but the time it takes browsers to >> redo the style sheet (and rerender things). This is just a browser > problem, >> not a code problem. >> >> And ofcourse size isn't such a big issue neither, seeing that most of the >> differences (I know, not all) are done on single lines as you pointed out: >> >> is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset >> >> this will only be a few bytes difference once you split it up: >> >> e.x+document.body.scrollLeft >> >> so maybe you save some bytes with the split but you have to include all >> files multiple times and maintain all files multiple times for your site > to >> look good on all browsers. >> >> >> apologies for the long post :) >> >> cya, >> >> Pascal Bestebroer >> pa...@dy... >> http://www.dynamic-core.net >> >> > -----Oorspronkelijk bericht----- >> > Van: dyn...@li... >> > [mailto:dyn...@li...]Namens SReindl >> > Verzonden: zaterdag 9 december 2000 9:14 >> > Aan: dyn...@li... >> > Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files >> > >> > >> > Well, call it as you like: Lib ode API, ... An API has the task to > supply >> > you with a unique set of functions in order to perform some development >> > tasks. In this case this is cross browser compatible programming of web >> > sites (btw, an API can be stored in a lib ;-)) >> > I agree, that the API is not meant to be a play ground for fancy >> > stuff which >> > may be possible only for one particular browser. >> > But I don't see why the "streaming of the project" should be more work > for >> > separate files than for monolithic ones. >> > It's the definition of the basis of functions which is important, and > this >> > task has already been done, since the DynAPI is up and running. >> > >> > Look at this piece (from events.js): >> > >> > this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset >> > >> > this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset >> > this.x=is.ie?e.offsetX:e.layerX >> > this.y=is.ie?e.offsetY:e.layerY >> > var b = is.ie?e.button:e.which >> > if (is.ie){ >> > if (b==2) b = 3 >> > else if (b==4) b = 2 >> > } else { } >> > All this is done only to define two basic paisr of vars. Terrible. And >> > impossible just to skip the nn stuff, becoause it's not clear, what > refers >> > to nn but only what is not for ie. I have to go through it and to >> > learn the >> > syntax of several browsers (document.body.scrollLeft vs >> > window.pageXOffset, >> > etc., and do not forget the sign). >> > >> > My >> > > "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." >> > if of course *an example* only and not the goal of my programs. >> > >> > last not least, in addition to decrease in loading and rendering >> > time there >> > is one more feature which speaks for a split: control over >> > completeness. If >> > you have to assure that your implementation is complete you will have to >> > code all the functions. The chance just to forget an if branch is > smaller. >> > >> > I do not say that cross browser compatibility should be given up, >> > I think of >> > how this task can be done in a more transparent way. >> > 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: <f.k...@t-...> - 2000-12-11 09:09:49
|
hi all. is this event-bug in ns6 (events are triggered multiple times) fixed already? florian. |
From: <ton...@si...> - 2000-12-11 07:01:20
|
www10.ewebcity.com/tskoda/js.asp On this site you will find my treeview written in javascript. It works on IE and NS. Netscape verison also uses the dynapi scroll widget. |
From: Robert R. <rra...@ya...> - 2000-12-11 03:43:15
|
This has been fixed. Plus Dan updated CVS with a patch to the scrollbar widget that fixes the scrolling problem. The only other issue is the button/dynimage which Dan is working on. -- // Robert Rainwater On 12/10/2000, 11:04:42 PM EST, Doug wrote about "[Dynapi-Dev] Current Issues": > wierd.. I am using the latest(?) from the /src/ dir of a snap shot from a > couple of days ago, My scroll works fine? Mind you I am using the > skinscroll.. > Althogh, I may have over-written the scroll.js with a previous one.. > I seem to recall doing that but am not sure.. > ----- Original Message ----- > From: "Robert Rainwater" <rra...@ya...> > To: "DynAPI Development List" <dyn...@li...> > Sent: Friday, December 08, 2000 2:27 PM > Subject: [Dynapi-Dev] Current Issues >> >> Here are some of the current issues that I have seen: >> >> - The Scrollbar widget does not work in NS. It never appears. I >> believe this is due to the DynImage/Button widgets. Thus scrollpane >> is broken as well. Oddly though, pushpanel seems to work >> >> - The new list widget (in CVS) has some selection problems. When you >> select a list item, sometimes the wrong item is bolded. >> >> All of these are based on the latest files in CVS, not the snapshot >> (hasn't updated yet). >> >> Please take a look at the issues, especially the scrollbar problem >> because I am perplexed with that one. >> >> -- >> // Robert Rainwater >> >> >> > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Brandon M. <bnd...@ho...> - 2000-12-11 02:17:20
|
Ahh.. but when you're running those If statements through a loop that creates several hundred layers, there is a HUGE difference in performance.... and generation of layers in IE should be changed... as there is a huge performance hit when the createLayer method is called for all layers at once... if DOM methods are used, for IE specific, then the layers can be created as they are instanciated, and when they are to actually be displayed in the browser, simply use DOM methods to move the node into the visible browser buffer. It would be like an off-screen buffer holding all code and properties that would be quickly added in 2 method calls. IE has a built-in XML parser with DOM methods which can be the back-end buffer, and should be able to transfer node from the XML tree to the browser DOM tree. All the property setting would be done in the back-end native code, thus making it faster. Who knows DOM? (oh... to create an XML object in IE5+, simply document.writeln('<XML id="XMLObj"></XML> '); Then to access: document.all.XMLObj references the Document object of the XML DOM tree. ----- Original Message ----- From: "Pascal Bestebroer" <pa...@dy...> To: <dyn...@li...> Sent: Sunday, December 10, 2000 12:25 PM Subject: RE: AW: [Dynapi-Dev] DynAPI build, Splitting files > This is a repost (previous one seems to have gotten lost :) > > Once you split up parts of the API for every browser (that could eventually > include Opera, and other flavours) it means that people will start focusing > on a single browser because that's the browser they'll be using. Ofcourse > this is already being done on a smaller scale (Dan's main focus seems to be > Netscape, and my focus is more IE5+) but at this point because of the code > being one , we know that what ever we do should also work Netscape.. once > you split things up I think this "awareness" will disappear and people will > just enhance the code for that single browser and let someone else worry > about the other browsers files. > > "All this is done only to define two basic paisr of vars. Terrible. And > impossible just to skip the nn stuff, becoause it's not clear, what refers > to nn but only what is not for ie. I have to go through it and to > learn the" > > that's correct, just two basic pairs of vars, so you want to split all code > up for simple things like these? And the fact that you have to go thru it > and learn the differences is exactly my point, if you have the chance to > only do your coding for IE, you will forget about NS and this might cause > you to implement things in IE that are not possible in NS. Ofcourse this > means we're holding back one browser because of the incompatibilities with > the other, but that's the problem with cross-browser coding, and if you need > that extra functionality you should added it in your own code, not in the > general API. > > The problem with speed that everybody talks about is not such a big issue, > we're not developing for 386 or 486 machines anymore, Pentium machines don't > take 2 or 3 clock-cycles to do a simple IF statement. Besides the IF > statements are only called at initialisation and when changing styles, the > main bottle-neck is not the IF statement but the time it takes browsers to > redo the style sheet (and rerender things). This is just a browser problem, > not a code problem. > > And ofcourse size isn't such a big issue neither, seeing that most of the > differences (I know, not all) are done on single lines as you pointed out: > > is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset > > this will only be a few bytes difference once you split it up: > > e.x+document.body.scrollLeft > > so maybe you save some bytes with the split but you have to include all > files multiple times and maintain all files multiple times for your site to > look good on all browsers. > > > apologies for the long post :) > > cya, > > > Pascal Bestebroer > pa...@dy... > http://www.dynamic-core.net > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Doug M. <do...@cr...> - 2000-12-11 01:06:12
|
wierd.. I am using the latest(?) from the /src/ dir of a snap shot from a couple of days ago, My scroll works fine? Mind you I am using the skinscroll.. Althogh, I may have over-written the scroll.js with a previous one.. I seem to recall doing that but am not sure.. ----- Original Message ----- From: "Robert Rainwater" <rra...@ya...> To: "DynAPI Development List" <dyn...@li...> Sent: Friday, December 08, 2000 2:27 PM Subject: [Dynapi-Dev] Current Issues > > Here are some of the current issues that I have seen: > > - The Scrollbar widget does not work in NS. It never appears. I > believe this is due to the DynImage/Button widgets. Thus scrollpane > is broken as well. Oddly though, pushpanel seems to work > > - The new list widget (in CVS) has some selection problems. When you > select a list item, sometimes the wrong item is bolded. > > All of these are based on the latest files in CVS, not the snapshot > (hasn't updated yet). > > Please take a look at the issues, especially the scrollbar problem > because I am perplexed with that one. > > -- > // Robert Rainwater > > > |