Menu
▾
▴
dynapi-dev
|
From: Pascal B. <pa...@dy...> - 2001-02-24 21:55:11
|
the static methods we're not the BIG speed thing, but the default width/height values we're (your canvas doesn't do getContentWidth/getContentHeight.. those functions eat time) only a small increase in speed without static methods.. (come to think about it, it might have actually be just a random thing :) Note that NS still is MUCH slower then IE. And one thing that could make ever users code faster is by creating one big canvas layer and place all other layers as children on it, then add that canvas to the dyndocument and it will use 100% precreation code which should be faster (untested, but sounds right) Pascal Bestebroer pa...@dy... http://www.dynamic-core.net |
|
From: Pascal B. <pa...@dy...> - 2001-02-25 08:47:54
|
man, now your gonna get it :) leave the inheriting model alone! serious though, currently widgets really inherit from the dynlayer, so that all dynlayer methods are available without any extra code (or memory) if you make it a property of the widget, all these things are gone and you would need to call the dynlayer property to access dynlayer functionality (sizing,moveto) which should be simple widget methods. I think there has been already ALOT of discussion about this (see archives :) and I for one am against any widget model changes (always have been, always will :) Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Eytan Heidingsfeld > Verzonden: zaterdag 24 februari 2001 23:02 > Aan: dyn...@li... > Onderwerp: RE: [Dynapi-Dev] a few hours for only 2 lines of code.. damn! > > > The only thing I still want to change is the way that all widgets inherit > from DynLayer. Why don't we just make them have a dynlayer object > then it is > easier to free mem. (Taking care of DynLayer is a hassle but the object > isn't). > 8an > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Eytan H. <ey...@tr...> - 2001-02-25 08:53:46
|
It HURTS! My My The Rocks fell like rain!! (And Feb 24th is even my birthday ;-) There will be no difference in memory if you place it as an object but it is just better programming. Straight out! The problem is that you think of DynLayer as a widget instead of an interface remember it is Dyn - API (Interface is the I) 8an |
|
From: Robert R. <rra...@ya...> - 2001-02-25 09:09:33
|
As much as I liked DynAPI 1, I don't want to go back to those days :) I think the widget model as it is now, is much more extensible than by not using any type of inheriting. -- // Robert Rainwater On 2/25/2001, 3:48:41 AM EST, Pascal wrote about "[Dynapi-Dev] a few hours for only 2 lines of code.. damn!": > man, now your gonna get it :) > leave the inheriting model alone! > serious though, currently widgets really inherit from the dynlayer, so that > all dynlayer methods are available without any extra code (or memory) > if you make it a property of the widget, all these things are gone and you > would need to call the dynlayer property to access dynlayer functionality > (sizing,moveto) which should be simple widget methods. > I think there has been already ALOT of discussion about this (see archives > :) and I for one am against any widget model changes (always have been, > always will :) > Pascal Bestebroer > pa...@dy... > http://www.dynamic-core.net >> -----Oorspronkelijk bericht----- >> Van: dyn...@li... >> [mailto:dyn...@li...]Namens Eytan Heidingsfeld >> Verzonden: zaterdag 24 februari 2001 23:02 >> Aan: dyn...@li... >> Onderwerp: RE: [Dynapi-Dev] a few hours for only 2 lines of code.. damn! >> >> >> The only thing I still want to change is the way that all widgets inherit >> from DynLayer. Why don't we just make them have a dynlayer object >> then it is >> easier to free mem. (Taking care of DynLayer is a hassle but the object >> isn't). >> 8an >> >> >> _______________________________________________ >> Dynapi-Dev mailing list >> Dyn...@li... >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev >> > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev ---------------------- DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ DynAPI Homepage: http://dynapi.sourceforge.net/ |
|
From: Doug M. <do...@cr...> - 2001-02-25 21:04:34
|
I most whole heartedly agree. The inheriting model makes so much of what I do possible. Withou one you loose the most integral part of the API. (IMHO of course) Dogu ----- Original Message ----- From: "Robert Rainwater" <rra...@ya...> To: "DynAPI Development List" <dyn...@li...> Sent: Sunday, February 25, 2001 1:08 AM Subject: Re[2]: [Dynapi-Dev] a few hours for only 2 lines of code.. damn! > > As much as I liked DynAPI 1, I don't want to go back to those days :) > > I think the widget model as it is now, is much more extensible than by > not using any type of inheriting. > > -- > // Robert Rainwater > > On 2/25/2001, 3:48:41 AM EST, Pascal wrote about "[Dynapi-Dev] a few hours for only 2 lines of code.. damn!": > > > man, now your gonna get it :) > > > leave the inheriting model alone! > > > serious though, currently widgets really inherit from the dynlayer, so that > > all dynlayer methods are available without any extra code (or memory) > > > if you make it a property of the widget, all these things are gone and you > > would need to call the dynlayer property to access dynlayer functionality > > (sizing,moveto) which should be simple widget methods. > > > I think there has been already ALOT of discussion about this (see archives > > :) and I for one am against any widget model changes (always have been, > > always will :) > > > > Pascal Bestebroer > > pa...@dy... > > http://www.dynamic-core.net > > >> -----Oorspronkelijk bericht----- > >> Van: dyn...@li... > >> [mailto:dyn...@li...]Namens Eytan Heidingsfeld > >> Verzonden: zaterdag 24 februari 2001 23:02 > >> Aan: dyn...@li... > >> Onderwerp: RE: [Dynapi-Dev] a few hours for only 2 lines of code.. damn! > >> > >> > >> The only thing I still want to change is the way that all widgets inherit > >> from DynLayer. Why don't we just make them have a dynlayer object > >> then it is > >> easier to free mem. (Taking care of DynLayer is a hassle but the object > >> isn't). > >> 8an > >> > >> > >> _______________________________________________ > >> Dynapi-Dev mailing list > >> Dyn...@li... > >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev > >> > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > ---------------------- > DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ > DynAPI Homepage: http://dynapi.sourceforge.net/ > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |
|
From: Pascal B. <pa...@dy...> - 2001-02-25 10:16:25
|
And see the API part, this means not just for making things work cross-browser, but also make the underlying code transparent and as easy to use as possible. So the difference: myWidget.moveTo(50,50) or myWidget.DynLayer.moveTo(50,50) would 1. add more code in general 2. not as transparent as wanted. A DynLayer and Widget can now be controlled in exactly the same way, but if every widget needs to be accessed thru it's dynlayer object, a dynlayer and widget won't be controlled in the same way. The only thing you gain with this is the fact that any deletion code we might create (a single function probably) would be easier, yet all other code created by users would be larger and more "difficult to understand" for users. Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Eytan Heidingsfeld > Verzonden: zondag 25 februari 2001 9:54 > Aan: dyn...@li... > Onderwerp: Re: [Dynapi-Dev] a few hours for only 2 lines of code.. damn! > > > It HURTS! > My My The Rocks fell like rain!! > (And Feb 24th is even my birthday ;-) > There will be no difference in memory if you place it as an > object but it is > just better programming. Straight out! The problem is that you think of > DynLayer as a widget instead of an interface remember it is Dyn - API > (Interface is the I) > 8an > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Eytan H. <ey...@tr...> - 2001-02-25 10:24:25
|
A wrapper function would be added to myWidget that would look like this:
myWidget.prototype.moveTo = function(x,y){
this.dynlayer.moveto(x,y);
}
8an
|
|
From: Doug M. <do...@cr...> - 2001-02-25 21:07:49
|
um, that would make two function calls instead of one..
With an interpreted language that can add up over several objects to
noticeably slow down the whole application.
----- Original Message -----
From: "Eytan Heidingsfeld" <ey...@tr...>
To: <dyn...@li...>
Sent: Sunday, February 25, 2001 2:24 AM
Subject: Re: [Dynapi-Dev] a few hours for only 2 lines of code.. damn!
> A wrapper function would be added to myWidget that would look like this:
> myWidget.prototype.moveTo = function(x,y){
> this.dynlayer.moveto(x,y);
> }
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
|
|
From: Pascal B. <pa...@dy...> - 2001-02-25 10:32:26
|
extra code (size is also an issue with javascript) to be rude: these things have all been discussed many times in the last year.. and we (including Dan back then) decided that this was just the most straight forward way of doing the inheriting (and widgets SHOULD inherit from dynlayer for should be obvious reasons) The way you want to do this is just adding work arounds for something that can be done using build in Javascript ideas. There was one WidgetObject once that did it in the same way as you'r suggesting (all widgets inherited from this object and it had a set of functions that simple call the correct dynlayer function) but this is alot of overhead and extra code, making things slower, use more memory, and bigger... Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > A wrapper function would be added to myWidget that would look like this: > myWidget.prototype.moveTo = function(x,y){ > this.dynlayer.moveto(x,y); > } > > 8an |
|
From: Eytan H. <ey...@tr...> - 2001-02-25 10:46:19
|
Give me a break! Not meaning to sound rude: the over head of those bytes is the least of our problems and anyway since they are part of an object (not element) there isn't even a leak! 8an |
|
From: Pascal B. <pa...@dy...> - 2001-02-25 10:57:48
|
over head of those bytes IS a problem.. a webapplication or very enhanced website would have ALOT of extra code going on, so all files would require much more. I dont see what the big improvement would be.. you still have a DynLayer to deal with. The main problem is that your doing alot of workaround methods to call all dynlayer methods. Widgets are now completely the same as dynlayers only with added functionality. That's the beauty of the current model. I just can't believe that any deletion code we eventually get working 100% can't be used in the current widget model (on which MANY widgets are already based). Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Eytan Heidingsfeld > Verzonden: zondag 25 februari 2001 11:47 > Aan: dyn...@li... > Onderwerp: Re: [Dynapi-Dev] a few hours for only 2 lines of code.. damn! > > > Give me a break! > Not meaning to sound rude: the over head of those bytes is the > least of our > problems and anyway since they are part of an object (not element) there > isn't even a leak! > 8an > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Eytan H. <ey...@tr...> - 2001-02-25 12:01:58
|
The problem is actualy two: * Correct programming Just what it sounds like. Imagine in windows all components would inherit from canvas * Eaisier to write widgets. For instance a pop up menu (what a cool idea ;-) because you don't know where on the page you are and you might want the pop up menu to show up to the left of the cursor or right or above or below you could put that code in popup.prototype.moveTo 8an |
|
From: Pascal B. <pa...@dy...> - 2001-02-25 12:11:35
|
> * Correct programming > Just what it sounds like. Imagine in windows all components would inherit > from canvas look at delphi : TComponent (that's our DynLayer) the base object of all components/widgets. > * Eaisier to write widgets. > For instance a pop up menu (what a cool idea ;-) because you don't know > where on the page you are and you might want the pop up menu to show up to > the left of the cursor or right or above or below you could put > that code in > popup.prototype.moveTo You lost me there.. can't we do that now with our current widgets?.. I always thought that was the beauty of the current model! Pascal Bestebroer pa...@dy... http://www.dynamic-core.net |
|
From: Eytan H. <ey...@tr...> - 2001-02-25 12:18:51
|
No, Delphi TComponent (been reading about this because of the Kylix) is a basic component that wraps the calls to the API. I don't care if we make a TComponent or TWidget but I just perfer this over using the DynLayer itself. 8an |
|
From: Pascal B. <pa...@dy...> - 2001-02-25 12:42:42
|
DynLayer IS the root component (that's what I've been trying to say) Every widget needs the graphical functionality of a DynLayer, that's why it IS the base object. Ofcourse TComponent is Delphi only, because Windows internally probably doesn't have anything like it.. just graphics functions to draw canvas's. But that's what we're doing here as well, DynLayer is the canvas object to do all "graphical" interface tricks (this is DHTML, not windows, so mostly used for visual development of websites) If you want a widget without any graphicall functionality then don't base if on the DynLayer (never seen one, but it might happen). But as it is now, all widgets will always function the same they always have: moveTo, setSize, setHTML, etc,etc,etc This makes creating widgets that interact with each other alot easier because you don't have to check for these methods to be available, they are simply available.. so take a toolbar widget, you can add ANY other widget on it, without having to prepare them or checking there class type. If you want your widgets using another model, go ahead but most (not all though, but majority) people involved agreed that this was the way to do widget inheriting: it's simple, short, and standard Javascript inheriting. And I for one will stick to this way of widgets.. use your own model if you like, just make sure there fully compatible. Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > No, > Delphi TComponent (been reading about this because of the Kylix) > is a basic > component that wraps the calls to the API. > > I don't care if we make a TComponent or TWidget but I just perfer > this over > using the DynLayer itself. > > 8an |
|
From: Eytan H. <ey...@tr...> - 2001-02-25 12:54:08
|
Ok. You know what. I can see this. U win. (About the DynLayer not being a property) k? 8an |
|
From: Michael P. <mp...@po...> - 2001-02-25 13:28:34
|
I'm sorry if I'm late on the topic but it sux being 12 hours behind on all of these discussions. The API IS standalone. By itself it has NO visual components. If you want a root object on which to base your widgets, use the base JS object Object. This is what the DynLayer istelf in inhereting from.. The reason that almost all of the widgets inheret from DynLayer is because they are just that, VISUAL. If you want to create a widget that has NO functionality and no visual aspect, just use Object and write your own methods for it. Eytan Heidingsfeld wrote: > Ok. > You know what. > I can see this. > U win. (About the DynLayer not being a property) > > k? > 8an > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev -- Michael Pemberton mp...@ph... ICQ: 12107010 |
|
From: Eytan H. <ey...@tr...> - 2001-02-25 13:36:14
|
Ok. Now to another discussion that has to do with the previous one. What about creating an Application object. You don't have to use it. It will be optional but will take care of stuff like focus. 8an |
|
From: Michael P. <mp...@po...> - 2001-02-25 13:44:59
|
this can be done again by just extending an Object. it is actually something i'm thinking of looking into for use with my dynform objects. Eytan Heidingsfeld wrote: > Ok. > Now to another discussion that has to do with the previous one. > What about creating an Application object. > You don't have to use it. It will be optional but will take care of stuff > like focus. > 8an > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev -- Michael Pemberton mp...@ph... ICQ: 12107010 |
|
From: Eytan H. <ey...@tr...> - 2001-02-25 13:47:54
|
Are your dynform for forms as in vb delphi forms (windows) or as in HTML forms? Cause I was also going to devlop a vb delphi one. I'd love to see urs. 8an |
|
From: Henrik V. <hv...@ya...> - 2001-02-25 20:18:20
|
Heh, I was just about to post this as something similar was suggested = from others. Well, I guess it might add to the current turns as-is... --- I think that there's at least one occation when its useful of using an = object other than simply the dynlayer OR dyndocument - managers. With = managers I mean a toplevel object that holds value for multiple = instances of a certain widget (or other object?). Most could be included = with the widget they handle, but there's a couple of standalone managers = I would like to see.=20 * a window manager; I know Jordi might have something in the works here = (right?) * a focus manager; mainly to make alternative key navigation possible * a keymode manager; to toggle between control and normal(write) mode - = since modifier keys doesn't capture well together with char keys, but = works induvidually * a formmanager; for use and interface with servertasks as well as = clientside methods towards files (and databases?) I'm to code them myself, if nobody else will, it's just that I'm such a = messy a scripter that it takes me forever to finish off something :( Henrik V=E5glin [ hv...@ya... ] _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Doug M. <do...@cr...> - 2001-02-25 21:14:18
|
How about a compramise? A SlimDynLayer? it would have addchild, moveto, setsize and such.. but would not have sethtml,setcontent,getcontentwidth.. ect.. Just a super-basic object that can be used for 'lightweight' widgets ----- Original Message ----- From: "Pascal Bestebroer" <pa...@dy...> To: <dyn...@li...> Sent: Sunday, February 25, 2001 4:40 AM Subject: RE: [Dynapi-Dev] a few hours for only 2 lines of code.. damn! > > DynLayer IS the root component (that's what I've been trying to say) > Every widget needs the graphical functionality of a DynLayer, that's why it > IS the base object. > > Ofcourse TComponent is Delphi only, because Windows internally probably > doesn't have anything like it.. just graphics functions to draw canvas's. > But that's what we're doing here as well, DynLayer is the canvas object to > do all "graphical" interface tricks (this is DHTML, not windows, so mostly > used for visual development of websites) > > If you want a widget without any graphicall functionality then don't base if > on the DynLayer (never seen one, but it might happen). > > But as it is now, all widgets will always function the same they always > have: moveTo, setSize, setHTML, etc,etc,etc > This makes creating widgets that interact with each other alot easier > because you don't have to check for these methods to be available, they are > simply available.. so take a toolbar widget, you can add ANY other widget on > it, without having to prepare them or checking there class type. > > If you want your widgets using another model, go ahead but most (not all > though, but majority) people involved agreed that this was the way to do > widget inheriting: it's simple, short, and standard Javascript inheriting. > And I for one will stick to this way of widgets.. use your own model if you > like, just make sure there fully compatible. > > Pascal Bestebroer > pa...@dy... > http://www.dynamic-core.net > > > No, > > Delphi TComponent (been reading about this because of the Kylix) > > is a basic > > component that wraps the calls to the API. > > > > I don't care if we make a TComponent or TWidget but I just perfer > > this over > > using the DynLayer itself. > > > > 8an > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |
|
From: Eytan H. <ey...@tr...> - 2001-02-24 22:00:02
|
The only thing I still want to change is the way that all widgets inherit from DynLayer. Why don't we just make them have a dynlayer object then it is easier to free mem. (Taking care of DynLayer is a hassle but the object isn't). 8an |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X