Menu
▾
▴
dynapi-dev
|
From: labCoat <la...@xe...> - 2001-02-11 23:22:23
|
Robert (and all), > I believe the right click context menu disabling > can be removed. I don't see why it is needed. > Unless it kills the events, it should be > removed since it doesn't work cross-browser > anyways. > -- > //Robert Rainwater Right-mouse click menu disablement can be cross-browser. As you might know, I have been working on fixing most of the existing (known) bugs with the current release, as well as implementing the DynaCore's DynObject, reorganizing package structure, and adding some extras that I have noticed have been "lack-of feature" complaints in the past. One of the things that I have done is to make the right mouse event disablment cross-browser (I have tested this on IE4+ & NS4+ on the Windows OS), and made it optional. You can disable-enable the right menu, on the fly. Anyway, I have a question about events/our EventMethod... (some of the below has been a reference from Scott Andrew's web site -- scottandrew.com -- in the Netscape 6 Events article) In Netscape 4, events will travel inward towards the target of the event. window --> document --> layer --> childlayer(target) In Internet Explorer, events travel outward towards the browser window. childlayer(target) --> layer --> document --> window In Netscape 6, events start at the window and travel to the target element (event capture). But upon reaching the target, the event travels backward the way it came, until it reaches the browser window again (event bubbling). window --> document -->layer --> childlayer(target) --> layer --> document --> window So, I beleive (and I could be wrong, so please correct me if I am) the model that we are wanting to use is the IE's target to document to window. You might think that events are working in NS6 with the current release, but they are not. Upon closer examination and testing with very extensive examples, the events to not trigger correctly. Well, I have fixed the event's in NS6 (the reason everything was happening more than once is the fact that there is more than one event phase -- 3 actually). But the problem is NS4's window to document to target. If we want the events to behave in the same way cross-browser in very complex examples/widgets that uses bubbling, than we need to reverse the way that NS4 captures events (like IE's), and then use our own event bubbling method for the bubble (like in IE). HERE IS THE QUESTION: ** What are thoughts on this? ** I have been working on a method that will do this, but I am still ironing out bugs. By the way, Part of my reorganization consisted of breaking away mouse events form the events.js file, and making it a sperate "mouse.js" file. This way, you can still have create/delete/resize/etc... events get triggered, but not have to worry about the weighing down the code/processor with mouse events, if they are unecessary. (Plus, I saw this as being consistant with some if the file structure now, ie. keyevets.js). Also, because it they are required by the DynAPI (dynapi.js), I have made certain files (document.js, object.js, events.js) be automatically included when you set the library path. PLEASE, anybody that has any thoughts on this, reply! :-) --proteanman |
|
From: labCoat <la...@xe...> - 2001-02-12 01:59:37
|
Richard, Thank you for the quick response... But, what did you (and anyone who is reading) think about what I mentioned about needing to reverse the mouse (actually, just mouseover/mouseout seem to be different) events in NS4. Robert?? Pascal??? > A lot of interesting points touched on there, some examples/code would be > nice. Yes, soon... I promise. I am just finishing commenting and documenting before hand. > feel free to use this ftp to upload anything if you want I will, but first, I need to get my example site up and running with all of he examples and docs. Another thing that would be appriciated is that, once it is finished, if anyone that has the time can test the examples on different platforms/browsers. --proteanman |
|
From: Pascal <pb...@oi...> - 2001-02-12 09:51:27
|
> Right-mouse click menu disablement can be cross-browser. sure about IE4 ? > Anyway, > > I have a question about events/our EventMethod... > (some of the below has been a reference from Scott Andrew's > web site -- scottandrew.com -- in the Netscape 6 Events article) > > So, I beleive (and I could be wrong, so please correct me if > I am) the model that we are wanting to use is the IE's target > to document to window. You might think that events are > working in NS6 with the current release, but they are not. > Upon closer examination and testing with very extensive > examples, the events to not trigger correctly. Well, I have > fixed the event's in NS6 (the reason everything was happening > more than once is the fact that there is more than one event > phase -- 3 actually). As far as I'm aware someone had already posted a fix for this aswell.. and I noticed some code in the event code to try and catch it. > But the problem is NS4's window to > document to target. If we want the events to behave in the > same way cross-browser in very complex examples/widgets that > uses bubbling, than we need to reverse the way that NS4 > captures events (like IE's), and then use our own event > bubbling method for the bubble (like in IE). In my memory, this has always been our target.. and I thought the Eventlistener was build to make NS work the same as IE. I'm actually not sure if the bubbling thing is actually working in the current releases. > Part of my reorganization consisted of breaking away mouse > events form the events.js file, and making it a sperate > "mouse.js" file. > This way, you can still have create/delete/resize/etc... > events get triggered, but not have to worry about the > weighing down the code/processor with mouse events, if they > are unecessary. (Plus, I saw this as being consistant with > some if the file structure now, ie. keyevets.js). Good idea > Also, because it they are required by the DynAPI (dynapi.js), > I have made certain files (document.js, object.js, events.js) > be automatically included when you set the library path. Not sure if that's the way to go.. there might eventually be lite versions (again :) or some other versions of the document/object/event files. In that case you would need to be able to switch.. making people get used to including files will then be easier for them. Also, why so "secretive" about your things.. if you fix something try posting information or better post a patch.. this could help speed the DynAPI development. If you fix things in your code great! but you can also fix it in the DynAPI code aswell (even better!) Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com |
|
From: Richard B. <ma...@ri...> - 2001-02-12 00:07:33
|
A lot of interesting points touched on there, some examples/code would be nice. feel free to use this ftp to upload anything if you want: ftp.dynapi.f2s.com username: dynapi pass: dynapi port 21 url www.dynapi.f2s.com PHP & CGI & mySql & SSI enabled That goes for everybody. I haven't had time to make an entrance page etc, anyone who wants to can make one. Cheers, Richard Bennett ma...@ri... www.richardinfo.com (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2) ----- Original Message ----- From: "labCoat" <la...@xe...> To: <dyn...@li...> Sent: Monday, February 12, 2001 12:22 AM Subject: Re: Re[2]: [Dynapi-Dev] buttons bug?? > Robert (and all), > > > I believe the right click context menu disabling > > can be removed. I don't see why it is needed. > > Unless it kills the events, it should be > > removed since it doesn't work cross-browser > > anyways. > > -- > > //Robert Rainwater > > Right-mouse click menu disablement can be cross-browser. > > As you might know, I have been working on fixing most of the existing (known) bugs with the current release, as well as implementing the DynaCore's DynObject, reorganizing package structure, and adding some extras that I have noticed have been "lack-of feature" complaints in the past. > > One of the things that I have done is to make the right mouse event disablment cross-browser (I have tested this on IE4+ & NS4+ on the Windows OS), and made it optional. You can disable-enable the right menu, on the fly. > > > Anyway, > > I have a question about events/our EventMethod... > (some of the below has been a reference from Scott Andrew's web site -- scottandrew.com -- in the Netscape 6 Events article) > > In Netscape 4, events will travel inward towards the target of the event. > window --> document --> layer --> childlayer(target) > > In Internet Explorer, events travel outward towards the browser window. > childlayer(target) --> layer --> document --> window > > In Netscape 6, events start at the window and travel to the target element (event capture). But upon reaching the target, the event travels backward the way it came, until it reaches the browser window again (event bubbling). > > window --> document -->layer --> childlayer(target) --> layer --> document --> window > > So, I beleive (and I could be wrong, so please correct me if I am) the model that we are wanting to use is the IE's target to document to window. You might think that events are working in NS6 with the current release, but they are not. Upon closer examination and testing with very extensive examples, the events to not trigger correctly. Well, I have fixed the event's in NS6 (the reason everything was happening more than once is the fact that there is more than one event phase -- 3 actually). But the problem is NS4's window to document to target. If we want the events to behave in the same way cross-browser in very complex examples/widgets that uses bubbling, than we need to reverse the way that NS4 captures events (like IE's), and then use our own event bubbling method for the bubble (like in IE). > > HERE IS THE QUESTION: ** What are thoughts on this? ** > > I have been working on a method that will do this, but I am still ironing out bugs. > > > By the way, > > Part of my reorganization consisted of breaking away mouse events form the events.js file, and making it a sperate "mouse.js" file. > This way, you can still have create/delete/resize/etc... events get triggered, but not have to worry about the weighing down the code/processor with mouse events, if they are unecessary. (Plus, I saw this as being consistant with some if the file structure now, ie. keyevets.js). > > Also, because it they are required by the DynAPI (dynapi.js), I have made certain files (document.js, object.js, events.js) be automatically included when you set the library path. > > PLEASE, anybody that has any thoughts on this, reply! :-) > > --proteanman > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > ____________________________________________________________ > Get your free domain name and domain-based e-mail from > Namezero.com. New! Namezero Plus domains now available. > Find out more at: http://www.namezero.com > |
×
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