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: Brandon M. <bnd...@ho...> - 2000-12-05 16:41:04
|
YIKES! That would be a serious pain to devlop! Testing would really be hard. Think of all the stuff that would have to be stripped out and added back in. We might as well then develop seperate distributions. Ouch! Keeping everything in a specific heirchy, I think, is a better solution. ----- Original Message ----- From: "Cameron Hart" <ca...@bi...> To: <dyn...@li...> Sent: Tuesday, December 05, 2000 5:31 AM Subject: RE: [Dynapi-Dev] DynAPI Makefile/code compression almost complete > This is probably a good way of splitting the code into different browser > versions. If you put equivant of #IFDEF (or whatever, it's been a long time > since I touched C!) in the source Javascript, you could compile browser > specific versions from the one source distribution. At least then, all the > code is in one place, and browser specific versions are developed together, > not seperately. > > Cameron. > > > -----Original Message----- > > From: dyn...@li... > > [mailto:dyn...@li...]On Behalf Of Dan Steinman > > Sent: 04 December 2000 03:52 > > To: dyn...@li... > > Subject: [Dynapi-Dev] DynAPI Makefile/code compression almost complete > > > > > > This weekend I took on the task of creating a "build" system for DynAPI. > > > > First part involved writing my own JavaScript whitespace/comment > > removal script (in Perl). It's pretty much complete and as good > > or better than any others I've seen. I'm calling it JSPack and > > will release this as a separate program that must be downloaded > > in order to "build" the DynAPI. > > > > It not only compresses JS code, it also packages the files > > together. And this will be used to create js packages for the > > DynAPI. For example, it will create the files dynapi.api.js, > > dynapi.gui.js... which contain all the classes in that > > subdirectory. I have to add one more feature to my script that > > determines the order that the objects should be added to the > > Package. For example, ScrollPane extends off of ViewPort, so in > > the dynapi.gui.js file, viewport.js must be added first. > > Therefore I plan to add files to the /lib/dynapi/ directories > > that state the order of the files. These will be named .jspack > > and will be a simple list of the js files in the order they are > > to be added to a package. My JSPack program will take care of the rest. > > > > Right now JSPack does not parse the JavaScript, so it will not go > > through each of your lines and fix and incorrect or missing > > semicolon. There for it is essential that all files in the > > DynAPI have semi's on each line, as well in the following case: > > > > f = function() { > > }; // absolutely needed > > > > Second part is the Makefile. Up until now we've just been > > editing our files in /js/. But now we can use a separate > > directory /src/. This is where we edit our files. Our > > JavaScripts can contain comments, and do not have to be bunched > > up, because the Makefile will use the /src/ directory, compress > > all the code, and produce js packages, and jar files, and output > > it to /js/. > > > > So the /js/ directory will then contain a compressed release of our code. > > > > In order to build the DynAPi you need to be using unix/linux or > > have Cygwin installed in Windows, along with Perl and the JDK > > (for Jarring the files). You need to place JSPack in your path, > > and then type: > > > > make > > > > in the /dynapi/ source tree. This runs the commands in the > > Makefile which does everything needed to produce the /js/ tree. > > > > I'm going through all of the existing JS code and putting the > > necessary semi colons, and will have everything ready to use in > > another day or 2. A first run-through of building the DynAPI > > produced a Jar file which 16KB!!!! (yes the entire DynAPI with > > the existing widgets can be compressed a lot). > > > > We can also use GZip to compress the files for use in IE 5, these > > will be a bit smaller than the Jar files. I don't believe there > > is any compression we can do for IE 4 though (other than > > whitespace removal). > > > > over and out, > > Dan > > > > _______________________________________________ > > 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-05 16:34:39
|
On Tue, 5 Dec 2000, Brandon Myers wrote: > there is sufficient interest, I can revamp the code, which has some bugs > that need to be squashed, and release it. It would be interesting if you put it on some web (or post me ;) Also I could show my version of JS debuger. I have used it to understand JS at all (and IE/NN4 objects model) http://cad.ntu-kpi.kiev.ua/~netlib/js/JS_MDV/js_mdv.tgz view/list, execute (eval) , change properties Malx |
From: Brandon M. <bnd...@ho...> - 2000-12-05 16:17:06
|
I have a debugging program that I wrote in javascript, simply add the debug.js file in the front, and the ability to "watch" variables, evaluate expressions, call functions, and write to a log within code is available. I have been using if for over 2 years now with great success. It's what I used to understand how DynAPI worked, and how the event system was structured. If there is sufficient interest, I can revamp the code, which has some bugs that need to be squashed, and release it. I should be in CVS, as I included it in the initial import. ----- Original Message ----- From: "Alexey Medvedev" <ma...@ca...> To: <dyn...@li...> Sent: Tuesday, December 05, 2000 10:53 AM Subject: [Dynapi-Dev] JS debuger > > > I wonder if there is a good javascript debugger that will run on my > > I thinks there is different debuggers for Netscape and for > IE (latest you have tried to install). > > For Netscape - look at http://developer.netscape.com for > "Visual JavaScript". It is written in Java - and run as an applet in > same Netscpae. But asks permissions for "Universal.debug" or something > and for reading local files from JS/Java. > > Malx > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Brandon M. <bnd...@ho...> - 2000-12-05 16:13:05
|
Given the following code: <html> <title>SuperClass Test Page</title> <head> <script language="JavaScript" src="../js/SuperClass.js"> </script> <script language="JavaScript"> function t1(id) { this.id = id || "t1" } SuperClass.subclass(t1); function t2() { this.superConstructor("t2") } t1.subclass(t2); SuperClass.extendClasses(); t=new t2(); anotherT=new t1(); alert(t.id); alert(anotherT.id); </script> </head> <body bgcolor="#000000"></body> </html> I had just added the removeFromArray to allow SuperClass to be completely seperate from DynAPI, such that it is completly independent and usable for ANY javascript object chain. With the fix to the removeFromArray, everything works fine. I get an alert that says 't2', followed by another that says 't1'. Don't forget that you must call "SuperClass.extendClasses()" after all classes have been extended. The reason behind this is so that any extentions that you may add to the class before or after calling SuperClass.subclass() will be passed down the chain. Simply adding this before any instances are created, such as in the DynAPI.loadHandler will work. ----- Original Message ----- From: "Robert Rainwater" <rra...@ya...> To: "DynAPI Development List" <dyn...@li...> Sent: Tuesday, December 05, 2000 10:06 AM Subject: Re[2]: [Dynapi-Dev] Multiple Inheritence > Brandon, > > I noticed a couple of problems with your superClass: > > - removeFromArray does not work because of the 1st line. It should > say: > SuperClass.prototype.removeFromArray=function(arry, index, id) { > > - superConstructor always throws an error. > > Unless I am using it wrong, I believe these are errors in the code. > > I tried something like: > > function t1(id) { > this.id = id || "t1" > } > SuperClass.subclass(t1) > > function t2() { > this.superConstructor("t2") > } > t1.subclass(t2) > > After fixing the removeFromArray, an error occured at the > superConstructor call. > > -- > // Robert Rainwater > > On 12/4/2000, 11:21:14 PM EST, Brandon wrote about "[Dynapi-Dev] Multiple Inheritence": > > > This is my implementation of a SuperClass (Top-level class) that takes care of everything that you want. > > > It does not require maintaining of an array of inheritable methods, other than the methods which are "static" to the constructor (Not part of the prototype chain) It also maintains changes to the > > default object methods, such as .valueOf, and .toString. It also maintains a list of instances for each class, and has methods to delete/destroy objects which can be overriden to perform special > > functions when destroying complex objects. > > > Also, it takes care of many other problems that I have found. I have used it in developing a split API. My revision of the API is split for each browser, and for each object type. The SuperClass is > > a generic top-level that does not require that the next level object be a GUI object, such as DynAPI. I have been able to seperate event based objects with non event GUI objects. DynLayer no longer > > has any event structure. This increased the total number of layers that can be placed on a page, since there are some object that really don't need events. There are GUI objects that are only for > > events and do not inherit any Animation functions. Since animation functions can be applied to another class, as an extention, which the SuperClass then passes down the inheritance chain. > > > Now, two lines will have to be added to the DynAPI.loadHandler method: > > if (SuperClass) > > SuperClass.extendClasses(); > > Add this before creating any instances of any objects in the loadHandler. (Such as before creating the DynDocument, and before calling any events) Maybe even placed at the first line. > > > Ok.. also included is a sample usage with a borderFactory class. > > Add the following line at the end of DynLayer: > > SuperClass.inherit(DynLayer); > > > Then, the borderFactory should work. > > > Assign a border to ANY subclass of DynLayer: > > > myBorder=BorderFactory.getBorder("SimpleBevel",2,"Black"); > > > button=new DynLayer("MyButton1",50,50,100,50); > > button.setBgColor("Silver"); > > button.setBorder(myBorder); // You could also do: myBorder.assignTo(button) > > DynAPI.document.addChild(myBorder); > > > Tada.. it's done. > > This is a VERY effective border, and works with ANY subclass of DynLayer. It's large only because of all the comments, and the spacing. It could be crunched down to less than half it's current size. > > It might take a little more work to get everything up to speed, but with the stability I have achieved, and speed increase, I feel this is a great asset to the community. > > ----- Original Message ----- > > From: Eytan Heidingsfeld > > To: dyn...@li... > > Sent: Sunday, December 03, 2000 7:31 AM > > Subject: [Dynapi-Dev] Multiple Inheritence > > > > I wrote a function inherit that can do multipule inheritence. The only problem is that any methods/properties that you want to let other objects inherit must be included in an array called > > oInterface. I know this is all vague. If anyone want the code just email me offlist. > > 8an > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Guangyi Wu <gua...@al...> - 2000-12-05 15:59:16
|
> I find it a bit of a waste to hear Dan is spending > one or two days putting semi-colons at the end of all the lines. It takes only a few lines of scripts to add semi-colons at the end of all non-empty lines. I am very glad to know that Dan would work it out. If the new convension is confirmed, developers can add comment to make source files readable. Even more, they can follow the javadoc comment conversion, so that we can always have the up to date document/reference from author. Isn't it what we want? > Isn't it usually considered bad netiquette to send attachments with your mail, > (or is this less important now most people have fast connections/machines) > especially as you can't get the attachments on the web interface. Compressed attachments are smaller than plain text. ;-) I fully agree with you that it would be better if we could upload files somewhere. I am also curious on the official answers to your questions. br George Hi, a few questions: Is it the idea that everybody following this project makes their changes through CVS, or only the admins/developers. How do we know who has done what, or what they are working on at the moment? Is it not possible to put different compact tasks up for the takers, who take the job, and keep the list up to date on their work? I find it a bit of a waste to hear Dan is spending one or two days putting semi-colons at the end of all the lines. Is it best just to submit bugreports here (mailinglist) ? Do the developers mind other people debugging their code, or prefer a bugreport? Isn't it usually considered bad netiquette to send attachments with your mail, (or is this less important now most people have fast connections/machines) especially as you can't get the attachments on the web interface. Isn't there anywhere (ftp or so) where anyone (not only admins) can upload a file. And what's wrong with the mailing lists, only help and dev seem to work. Back to work now... cheers, Richard:o) |
From: Alexey M. <ma...@ca...> - 2000-12-05 15:54:56
|
> I wonder if there is a good javascript debugger that will run on my I thinks there is different debuggers for Netscape and for IE (latest you have tried to install). For Netscape - look at http://developer.netscape.com for "Visual JavaScript". It is written in Java - and run as an applet in same Netscpae. But asks permissions for "Universal.debug" or something and for reading local files from JS/Java. Malx |
From: Jordi 'I. M. <jmi...@or...> - 2000-12-05 15:50:10
|
I have given a look to the code. I haven't tried it yet, and I can't tell if it works or not, but I would suggest that the Superclass is included as a tool rather than become mandatory. I think the API should stay simple, and so should stay a widget interface. I'm running into several problems when trying to have complex object structures. Hopefully the Superclass will solve them. However, there are lots of things that can be achieved using simple prototyping. There has been some discussion lately about OOP, OO, being formal, being strict, etc, etc. I'd like to point out that we are talking Javascript here. Instead of trying to make it more Java-like I think the efforts should move towards designing our widgets in a prototype way. Thinking our object structures as if we were programming Java and then finding a way to make them work under Javascript is not the way to go, IMHO. I'll try to design my object structures as if I was using a prototype-inherited language, which is what I am using. I do recognise the value of the superclass and I congratulate Brandon, but again this is not Java and I don't want it to be. My 2 euros Brandon Myers wrote: > This is my implementation of a SuperClass (Top-level class) that takes > care of everything that you want. It does not require maintaining of > an array of inheritable methods, other than the methods which are > "static" to the constructor (Not part of the prototype chain) It also > maintains changes to the default object methods, such as .valueOf, and > .toString. It also maintains a list of instances for each class, and > has methods to delete/destroy objects which can be overriden to > perform special functions when destroying complex objects. Also, it > takes care of many other problems that I have found. I have used it in > developing a split API. My revision of the API is split for each > browser, and for each object type. The SuperClass is a generic > top-level that does not require that the next level object be a GUI > object, such as DynAPI. I have been able to seperate event based > objects with non event GUI objects. DynLayer no longer has any event > structure. This increased the total number of layers that can be > placed on a page, since there are some object that really don't need > events. There are GUI objects that are only for events and do not > inherit any Animation functions. Since animation functions can be > applied to another class, as an extention, which the SuperClass then > passes down the inheritance chain. Now, two lines will have to be > added to the DynAPI.loadHandler method: if (SuperClass) > SuperClass.extendClasses(); > Add this before creating any instances of any objects in the > loadHandler. (Such as before creating the DynDocument, and before > calling any events) Maybe even placed at the first line. Ok.. also > included is a sample usage with a borderFactory class.Add the > following line at the end of DynLayer: > SuperClass.inherit(DynLayer); Then, the borderFactory should > work. Assign a border to ANY subclass of > DynLayer: myBorder=BorderFactory.getBorder("SimpleBevel",2,"Black"); button=new > DynLayer("MyButton1",50,50,100,50);button.setBgColor("Silver");button.setBorder(myBorder); > // You could also do: > myBorder.assignTo(button)DynAPI.document.addChild(myBorder); Tada.. > it's done.This is a VERY effective border, and works with ANY subclass > of DynLayer. It's large only because of all the comments, and the > spacing. It could be crunched down to less than half it's current > size.It might take a little more work to get everything up to speed, > but with the stability I have achieved, and speed increase, I feel > this is a great asset to the community. > > ----- Original Message ----- > From: Eytan Heidingsfeld > To: dyn...@li... > Sent: Sunday, December 03, 2000 7:31 AM > Subject: [Dynapi-Dev] Multiple Inheritence > I wrote a function inherit that can do multipule > inheritence. The only problem is that any methods/properties > that you want to let other objects inherit must be included > in an array called oInterface. I know this is all vague. If > anyone want the code just email me offlist.8an > |
From: Bill W. <bil...@us...> - 2000-12-05 15:38:52
|
One of the reasons I saw was that there was no oncreate being captured by the Label, only onresize. In the Button object, (assuming text was passed to it), the first thing is does is to call its own 'setText' method which eventually makes it down to the dynlayer's setSize method, which invokes the resize event, which is being captured by the label. The onresize handler gets the ContentWidth and ContentHeight which, since it has not been created yet, is still at null. This makes the coverlyr's width and height, 0 and 0. What I did was to give the label an oncreate method: listener.oncreate = function(e) { o = e.getTarget() o.setText(text) o.pack() if(o.hasCover){ o.coverlyr.setSize(o.w,o.h) } } Likewise, I changed the Button object's setText method to (if it wasn't that way to begin with, I'd have to look back): Button.prototype.setText = function(text) { if (this.label==null) { this.label = this.addChild(new Label(arguments[0])) this.label.setSelectable(false) } else { this.label.setText(text) this.label.packWidth() } } Lastly, I added these lines to the first part of Button's recenter method: if (this.label.hasCover){ this.label.coverlyr.setSize(this.w,this.h) }else{ this.label.addCover(this.w, this.h) } That way, the text is set and the label is added when the button is instanciated, the label is added when the button is created, now its size is known, and therefore, the label size can be set. This is kludgy to me, and it was only to get the Button object to work right. But I think the answer may just lie in making a proper oncreate handler for the label. If you want, I can attach my modified label.js and button.js files. I saw what you did with the Button, that is, it will take either text or an image, and thought I would apply the idea to a slide out menu widget I'm making. Now, my widget will take a string, a Button, or a CoreGridButton (which I also had to make work with the new core). I love that CoreGridButton. Domino has something similar. Speaking of Domino, If there are any other domino developers out there, I have managed to port DynAPI into a Domino database. pretty easy, but then it was only DynAPI 1 which was a lot flatter than this version. Now I can do things like having having dynamic forms, views, agents, etc. that I can submit back to the server for processing, and get responses back. Dan Steinman <dy...@fu...> wrote: > The only reason "add cover" was in the original Label was to prevent the text from being selectable. A layer covering the text is one solution, however this can/should be accomplished with event handling. As far as I can tell setSelectable() works perfectly fine in Netscape. It cancels the mouse down event and stops selecting of the test. There must be an equivalent IE method to do the same. > > I'd prefer having the method called "setSelectable" only because it makes more sense of what it accomplishes. > > Dan > > > On Mon, Dec 04, 2000 at 09:36:50PM -0500, Robert Rainwater wrote: > > > > I'm sure this has been mentioned before but here it goes again. > > > > The addCover method does not seem to work. When used, there is no > > change in IE 5. Also, what is the purpose of setSelectable versus > > addCover. In the label example it says that 2 of the labels have a > > cover, but there is no call to addCover, but there is one to > > setSelectable(). This seems like an error to me. > > > > -- > > // 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 ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 |
From: Bill W. <bil...@us...> - 2000-12-05 15:08:16
|
I kind of like the idea too. Perhaps it could be part of the perl make file that Dan (?) made over the weekend. Pass it a param to spit out IE4, IE5, NS4, NS6 etc. Then after the browser sniffer figures out which ua you have, load only the one you need. fast! -bw Alexey Medvedev <ma...@ca...> wrote: > > > versions. If you put equivant of #IFDEF (or whatever, it's been a long time > > code is in one place, and browser specific versions are developed together, > > It is interesting idea. > I thinks it could be done just with a "grep" (grep.exe) and sed :) > > ---src.js--- > > code.... > #IE sghd > #NN uuuuu > ------------ > > cat src.js | grep -v "^#IE" | sed s/"^#NN"//g >out.js > > But! > It would be hard to create the codes :-/ > If implementation ideology of DynLayer in IE and NN would be different. > (for example - use of <layer (or = new Layer())for NN as more > stable , than </div>). > > This one better to keep in different files. > > Malx > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 |
From: Robert R. <rra...@ya...> - 2000-12-05 15:05:28
|
Brandon, I noticed a couple of problems with your superClass: - removeFromArray does not work because of the 1st line. It should say: SuperClass.prototype.removeFromArray=function(arry, index, id) { - superConstructor always throws an error. Unless I am using it wrong, I believe these are errors in the code. I tried something like: function t1(id) { this.id = id || "t1" } SuperClass.subclass(t1) function t2() { this.superConstructor("t2") } t1.subclass(t2) After fixing the removeFromArray, an error occured at the superConstructor call. -- // Robert Rainwater On 12/4/2000, 11:21:14 PM EST, Brandon wrote about "[Dynapi-Dev] Multiple Inheritence": > This is my implementation of a SuperClass (Top-level class) that takes care of everything that you want. > It does not require maintaining of an array of inheritable methods, other than the methods which are "static" to the constructor (Not part of the prototype chain) It also maintains changes to the > default object methods, such as .valueOf, and .toString. It also maintains a list of instances for each class, and has methods to delete/destroy objects which can be overriden to perform special > functions when destroying complex objects. > Also, it takes care of many other problems that I have found. I have used it in developing a split API. My revision of the API is split for each browser, and for each object type. The SuperClass is > a generic top-level that does not require that the next level object be a GUI object, such as DynAPI. I have been able to seperate event based objects with non event GUI objects. DynLayer no longer > has any event structure. This increased the total number of layers that can be placed on a page, since there are some object that really don't need events. There are GUI objects that are only for > events and do not inherit any Animation functions. Since animation functions can be applied to another class, as an extention, which the SuperClass then passes down the inheritance chain. > Now, two lines will have to be added to the DynAPI.loadHandler method: > if (SuperClass) > SuperClass.extendClasses(); > Add this before creating any instances of any objects in the loadHandler. (Such as before creating the DynDocument, and before calling any events) Maybe even placed at the first line. > Ok.. also included is a sample usage with a borderFactory class. > Add the following line at the end of DynLayer: > SuperClass.inherit(DynLayer); > Then, the borderFactory should work. > Assign a border to ANY subclass of DynLayer: > myBorder=BorderFactory.getBorder("SimpleBevel",2,"Black"); > button=new DynLayer("MyButton1",50,50,100,50); > button.setBgColor("Silver"); > button.setBorder(myBorder); // You could also do: myBorder.assignTo(button) > DynAPI.document.addChild(myBorder); > Tada.. it's done. > This is a VERY effective border, and works with ANY subclass of DynLayer. It's large only because of all the comments, and the spacing. It could be crunched down to less than half it's current size. > It might take a little more work to get everything up to speed, but with the stability I have achieved, and speed increase, I feel this is a great asset to the community. > ----- Original Message ----- > From: Eytan Heidingsfeld > To: dyn...@li... > Sent: Sunday, December 03, 2000 7:31 AM > Subject: [Dynapi-Dev] Multiple Inheritence > I wrote a function inherit that can do multipule inheritence. The only problem is that any methods/properties that you want to let other objects inherit must be included in an array called > oInterface. I know this is all vague. If anyone want the code just email me offlist. > 8an |
From: Bill W. <bil...@us...> - 2000-12-05 15:03:20
|
Álvaro- I looked for that, but I must have missed it, you're right. Hmmm. I'll have to look at it some more. I wish I had a debugger. I was about to install Visual Interdev on my laptop but it wanted to 'correct' my JDK1.3 back to 1.2.... some upgrade, sheesh. I love the debugger though. I wonder if there is a good javascript debugger that will run on my Linux system at home? -bw Álvaro Peña González <ice...@ve...> wrote: > OK, Bill, thanks for your aid, but other things more :-) > > You are right as far as that acceding to the wide one by means of the > function getWidth() more is OO than directly by means of w. > > But as far as the one of which this.css.width is single for ie or ns5 I do > not agree. > Watching the following code that is called during the creation of the layer > we found that: > > DynLayer.prototype.assignElement=function(elm) { > this.elm=elm > if (is.ns4) > > this.css=this.elm > this.doc=this.elm.document > this.doc.lyrobj=this > } > else if (is.ie || is.ns5) { > this.css=this.elm.style > this.doc=this.parent.doc > } > this.elm.lyrobj=this > this.created=true > } > > this.css directly points in the style of the layer independientemete of the > browser, in addition use ie. > > Although I repeat that you are right and the correct way to obtain the wide > of the layer is by means of the method getWidth(). > > bye. > > ----- Original Message ----- > From: "Bill Wheaton" <bil...@us...> > To: <dyn...@li...> > Sent: Monday, December 04, 2000 8:29 PM > Subject: Re: [[Dynapi-Dev] Re: Layer Aling] > > > > Perhaps, (and I am not sure) it is because this.css.width is only for ie > and > > ns5 and you might be using netscape 4.7???? > > > > I found this in DynLayer's setSize method. Otherwise it sets the clip > width > > and height. > > if (is.ie || is.ns5) { > > this.css.width=w > > this.css.height=h > > } > > For cross browser compatability use the '.getWidth()' method or, the '.w' > > property (not .css.width) > > > > But this.w accesses the width directly, which is really a no-no in OO. > > getWidth() is better, because someone may change the '.w' property to > > '.widthofmyfunkylayerthingamajig' someday. If you use this.getWidth() it > > should still work even then, assuming they did it right. > > Regards > > -bw > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 |
From: Bill W. <bil...@us...> - 2000-12-05 14:57:16
|
Ah hah! I got it directly from the forum. I didn't start subscribing directly until the other day, and I don't think I am subscribing at all to the help... my bad. thanks though -bw Robert Rainwater <rra...@ya...> wrote: > > What email program are you using? If you are reading from the web, > then it will not read the attachments correctly. > > -- > // Robert Rainwater > > On 12/4/2000, 3:15:27 PM EST, Bill wrote about "[RE: [Dynapi-Dev] Developers reference]": > > > Does anyone know why, when I am reading posts here I get hex character > > conversion? > > > for example when looking at the developers guide that Pascal posted, it came > > through as html source beginning with the following line. > > > <h3 id=3D'#ID-1.2' class=3D'div3'>1.2. Browser detection</h3> > > > > Aside seems like the file is missing the first part (particularly the style > > sheets), but the main thing is, that every time there is an equals sign it is > > followed with its hex equiv, '3D' many lines have '=' at the end, some > > have'=20'. > > > Do I have to set my browser encoding to something other than Western > > European? > > I'm running ID5 on WinNT, and its driving me nuts (both windows and the hex > > thing <hehe>) > > any suggestions? > > thanks > > -bw > > > > > > > ____________________________________________________________________ > > Get free email and a permanent address at http://www.netaddress.com/?N=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 ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 |
From: Alexey M. <ma...@ca...> - 2000-12-05 14:07:12
|
> versions. If you put equivant of #IFDEF (or whatever, it's been a long time > code is in one place, and browser specific versions are developed together, It is interesting idea. I thinks it could be done just with a "grep" (grep.exe) and sed :) ---src.js--- code.... #IE sghd #NN uuuuu ------------ cat src.js | grep -v "^#IE" | sed s/"^#NN"//g >out.js But! It would be hard to create the codes :-/ If implementation ideology of DynLayer in IE and NN would be different. (for example - use of <layer (or = new Layer())for NN as more stable , than </div>). This one better to keep in different files. Malx |
From: Richard :o <ma...@ri...> - 2000-12-05 13:53:45
|
Hi, a few questions: Is it the idea that everybody following this project makes their changes = through CVS, or only the admins/developers. How do we know who has done what, or what they are working on at the = moment? Is it not possible to put different compact tasks up for the = takers, who take the job, and keep the list up to date on their work? I find it a bit of a = waste to hear Dan is spending one or two days putting semi-colons at the end of all the lines. =20 Is it best just to submit bugreports here (mailinglist) ? Do the developers mind other people debugging their code, or prefer a = bugreport? Isn't it usually considered bad netiquette to send attachments with your = mail, (or=20 is this less important now most people have fast connections/machines) = especially=20 as you can't get the attachments on the web interface. Isn't there = anywhere (ftp or so) where anyone (not only admins) can upload a file. And what's wrong with the mailing lists, only help and dev seem to work. Back to work now... cheers, Richard:o) |
From: Liam C. <met...@ma...> - 2000-12-05 12:42:30
|
For anonymous access for those people who do not have read/write privileges but want to follow the development of the API, you do not have to mess about with ssh, just do the following: Set your CVSROOT to: :ext:ano...@cv...:/cvsroot/dynapi And choose: pserver As your authentication system. When prompted leave the password field empty. This will work for command line and GUI implementations Liam Clancy -- "Everything in moderation ... including moderation" Please note my NEW address: met...@ma... pgp on request |
From: Eytan H. <ey...@tr...> - 2000-12-05 10:56:28
|
I remember a ew problems people were having when using dynamic images. = There is also the problem of the loading of the image. I don't remember = if I commented about it but there is a better way to make dynamic images = then to change the html from "IMG SRC=3D1" to "IMG SRC=3D2". I'm talking = about starting the HTML doc with an IMG tag with a name. Then in JS = creating Img objects. Then when you want to switch you do simple = assignment. This works in IE4 and up and NN4 and up |
From: Cameron H. <ca...@bi...> - 2000-12-05 10:51:50
|
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 |
From: Cameron H. <ca...@bi...> - 2000-12-05 10:31:56
|
This is probably a good way of splitting the code into different browser versions. If you put equivant of #IFDEF (or whatever, it's been a long time since I touched C!) in the source Javascript, you could compile browser specific versions from the one source distribution. At least then, all the code is in one place, and browser specific versions are developed together, not seperately. Cameron. > -----Original Message----- > From: dyn...@li... > [mailto:dyn...@li...]On Behalf Of Dan Steinman > Sent: 04 December 2000 03:52 > To: dyn...@li... > Subject: [Dynapi-Dev] DynAPI Makefile/code compression almost complete > > > This weekend I took on the task of creating a "build" system for DynAPI. > > First part involved writing my own JavaScript whitespace/comment > removal script (in Perl). It's pretty much complete and as good > or better than any others I've seen. I'm calling it JSPack and > will release this as a separate program that must be downloaded > in order to "build" the DynAPI. > > It not only compresses JS code, it also packages the files > together. And this will be used to create js packages for the > DynAPI. For example, it will create the files dynapi.api.js, > dynapi.gui.js... which contain all the classes in that > subdirectory. I have to add one more feature to my script that > determines the order that the objects should be added to the > Package. For example, ScrollPane extends off of ViewPort, so in > the dynapi.gui.js file, viewport.js must be added first. > Therefore I plan to add files to the /lib/dynapi/ directories > that state the order of the files. These will be named .jspack > and will be a simple list of the js files in the order they are > to be added to a package. My JSPack program will take care of the rest. > > Right now JSPack does not parse the JavaScript, so it will not go > through each of your lines and fix and incorrect or missing > semicolon. There for it is essential that all files in the > DynAPI have semi's on each line, as well in the following case: > > f = function() { > }; // absolutely needed > > Second part is the Makefile. Up until now we've just been > editing our files in /js/. But now we can use a separate > directory /src/. This is where we edit our files. Our > JavaScripts can contain comments, and do not have to be bunched > up, because the Makefile will use the /src/ directory, compress > all the code, and produce js packages, and jar files, and output > it to /js/. > > So the /js/ directory will then contain a compressed release of our code. > > In order to build the DynAPi you need to be using unix/linux or > have Cygwin installed in Windows, along with Perl and the JDK > (for Jarring the files). You need to place JSPack in your path, > and then type: > > make > > in the /dynapi/ source tree. This runs the commands in the > Makefile which does everything needed to produce the /js/ tree. > > I'm going through all of the existing JS code and putting the > necessary semi colons, and will have everything ready to use in > another day or 2. A first run-through of building the DynAPI > produced a Jar file which 16KB!!!! (yes the entire DynAPI with > the existing widgets can be compressed a lot). > > We can also use GZip to compress the files for use in IE 5, these > will be a bit smaller than the Jar files. I don't believe there > is any compression we can do for IE 4 though (other than > whitespace removal). > > over and out, > Dan > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Eytan H. <ey...@tr...> - 2000-12-05 09:42:40
|
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 |
From: <ice...@ve...> - 2000-12-05 09:40:48
|
OK, Bill, thanks for your aid, but other things more :-) You are right as far as that acceding to the wide one by means of the function getWidth() more is OO than directly by means of w. But as far as the one of which this.css.width is single for ie or ns5 I do not agree. Watching the following code that is called during the creation of the layer we found that: DynLayer.prototype.assignElement=function(elm) { this.elm=elm if (is.ns4) this.css=this.elm this.doc=this.elm.document this.doc.lyrobj=this } else if (is.ie || is.ns5) { this.css=this.elm.style this.doc=this.parent.doc } this.elm.lyrobj=this this.created=true } this.css directly points in the style of the layer independientemete of the browser, in addition use ie. Although I repeat that you are right and the correct way to obtain the wide of the layer is by means of the method getWidth(). bye. ----- Original Message ----- From: "Bill Wheaton" <bil...@us...> To: <dyn...@li...> Sent: Monday, December 04, 2000 8:29 PM Subject: Re: [[Dynapi-Dev] Re: Layer Aling] > Perhaps, (and I am not sure) it is because this.css.width is only for ie and > ns5 and you might be using netscape 4.7???? > > I found this in DynLayer's setSize method. Otherwise it sets the clip width > and height. > if (is.ie || is.ns5) { > this.css.width=w > this.css.height=h > } > For cross browser compatability use the '.getWidth()' method or, the '.w' > property (not .css.width) > > But this.w accesses the width directly, which is really a no-no in OO. > getWidth() is better, because someone may change the '.w' property to > '.widthofmyfunkylayerthingamajig' someday. If you use this.getWidth() it > should still work even then, assuming they did it right. > Regards > -bw |
From: <wan...@ya...> - 2000-12-05 07:46:19
|
TCL is not a problem. You need only ssh installed and properly configured. The problem is that CVS isn't runnig now. You must wait for this guys seting up CVS again ----- Original Message ----- From: "Darin Kadrioski" <dka...@ef...> To: <dyn...@li...> Sent: Monday, December 04, 2000 7:55 PM Subject: RE: [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 > > -- > // 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 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Robert R. <rra...@ya...> - 2000-12-05 06:30:52
|
I don't think I would have ever seen that one. Anyway, it has been updated (in CVS). -- // Robert Rainwater On 12/3/2000, 4:02:51 PM EST, Richard wrote about "[Dynapi-Dev] Attn Dan, small bug in pathanim.js": > Hi, > I noticed an error in line 133, y2==y2 should be y2==y1. > var dy = y2==y1? 0 : (y2-y1)/N; > Cheers, > Richard:o |
From: Robert R. <rra...@ya...> - 2000-12-05 05:47:00
|
What email program are you using? If you are reading from the web, then it will not read the attachments correctly. -- // Robert Rainwater On 12/4/2000, 3:15:27 PM EST, Bill wrote about "[RE: [Dynapi-Dev] Developers reference]": > Does anyone know why, when I am reading posts here I get hex character > conversion? > for example when looking at the developers guide that Pascal posted, it came > through as html source beginning with the following line. > <h3 id=3D'#ID-1.2' class=3D'div3'>1.2. Browser detection</h3> > Aside seems like the file is missing the first part (particularly the style > sheets), but the main thing is, that every time there is an equals sign it is > followed with its hex equiv, '3D' many lines have '=' at the end, some > have'=20'. > Do I have to set my browser encoding to something other than Western > European? > I'm running ID5 on WinNT, and its driving me nuts (both windows and the hex > thing <hehe>) > any suggestions? > thanks > -bw > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Brandon M. <bnd...@ho...> - 2000-12-05 04:21:32
|
Yes.. but it would have to be a single document.write after all code has completed. As the page wouldn't be rendered untill the thread which executed the write method has completed. So.. only on loading of a page would this actually increase performance for IE. And even then, writing directly to the innerHTML would be faster, speaking strictly IE. In Netscape, the adding Layers is definitly preferred. ----- Original Message ----- From: "Scott Andrew LePera" <sc...@sc...> To: <dyn...@li...> Sent: Thursday, November 30, 2000 2:46 AM Subject: Re: [Dynapi-Dev] Updated Release, fixes/changes > <snip> > It's entirely possible have the DynLayer generate LAYER and DIV tags (ala > dynapi1) this would allow you to insert Dynlayers before onLoad, as well you > can get an enormous boost in drawing time in Netscape by writing all the > children layers as layer/div's at the same time in one document.write(). > </snip> > > I imagine this could help IE, too. IE rendering is *extremely* slow when > generating lots of DynLayers. I think Netscape handles it better, because > the JS evaluation and rendering happen separately and simultaneously, while > IE has to wait for one process to complete before starting the other. A > document.write might be quicker and cleaner in IE. > > scottandrew > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Brandon M. <bnd...@ho...> - 2000-12-05 04:21:30
|
The object may be destroyed, but the Javascript garbage collector = doesn't run untill the next page load. It's standard practice in the = known browsers (From what I've read). I'm not sure about the Mozilla/Seamonkey versons though. I'd have to = research this. ----- Original Message -----=20 From: Eytan Heidingsfeld=20 To: dyn...@li...=20 Sent: Sunday, December 03, 2000 8:06 AM Subject: Re: [Dynapi-Dev] My new Object I managed to fix the problem by making the FreeObj method external. = The problm was that the scope was still in the object and then it could = not be deleted. =20 Thanx, 8an |