dynapi-dev — List related to the current DynAPI Core development

Re: [Dynapi-Dev] update for DynAPI 3.0.0 Beta 2

[Leland S. <ls...@ns...>]

Unfortunately, Qooxdoo does not support Mac OS X.  If you're looking  
for a tool to build web applications that will work across the board,  
there are many others more highly rated than Qooxdoo.  A survey in  
Ajaxian recently rated the popularity of the Ajax toolkits (and  
libraries), and the ones that show up as most popular are all fully  
cross-platform, cross-browser compliant (except for Atlas--at least,  
based on my testing in July 2006):
http://ajaxian.com/archives/ajaxiancom-2006-survey-results

Regards,
Leland

P.S. I'm one of the guys who uses Prototype and Script.aculo.us, by  
the way.

On Sep 27, 2006, at 6:15 AM, Braitschev, Alexander wrote:

> Hi,
>
> there doesn't seem to be anything alive anymore.
>
> Though it has a bit a different focus i moved over to http://qooxdoo.org 
>  some time ago, maybe this is also in interrest for other people here.
>
> Quite promising, and highly active.
>
> Cheers,
> Alex
>
> Von: dyn...@li... im Auftrag von Andriy  
> Kopystyansky
> Gesendet: Mi 27.09.2006 12:04
> An: dyn...@li...
> Betreff: [Dynapi-Dev] update for DynAPI 3.0.0 Beta 2
>
> Hi people, Dan!
> I was using DynAPI a years ago, when it was hosted on
> www.dansteinman.com. I'm glad DynAPI project still alive :)
> Thanks to all developers!
>
> Recently we need a tool for nagios hostextinfo.cfg visual
> configuration. There is script in the net (cheops-ng2nagios) for this
> purpose using gnome-libs and a lot of other stuff... Due to
> installation problem I made a new one based on DynAPI 3.0.0 beta2. If
> anybody interested, contact me...
>
> Well, the subject:
> Looks like there should be removeLine method in dynapi.gui.Graphics
> object, like this:
>
>
> Graphics.prototype.removeLine = function(shape) {
>         if (Graphics.useVML)    this._dlyr.elm.removeChild(shape.elm);
>         else this._dlyr.removeChild(shape);
>         return ;
> };
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn  
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>
> <ATT6612012.txt>
> <ATT6612014.txt>

Re: [Dynapi-Dev] update for DynAPI 3.0.0 Beta 2

[Braitschev, A. <ab...@be...>]

Hi,
=20
there doesn't seem to be anything alive anymore.
=20
Though it has a bit a different focus i moved over to http://qooxdoo.org =
some time ago, maybe this is also in interrest for other people here.
=20
Quite promising, and highly active.
=20
Cheers,
Alex

________________________________

Von: dyn...@li... im Auftrag von Andriy =
Kopystyansky
Gesendet: Mi 27.09.2006 12:04
An: dyn...@li...
Betreff: [Dynapi-Dev] update for DynAPI 3.0.0 Beta 2



Hi people, Dan!
I was using DynAPI a years ago, when it was hosted on=20
www.dansteinman.com. I'm glad DynAPI project still alive :)
Thanks to all developers!

Recently we need a tool for nagios hostextinfo.cfg visual=20
configuration. There is script in the net (cheops-ng2nagios) for this=20
purpose using gnome-libs and a lot of other stuff... Due to=20
installation problem I made a new one based on DynAPI 3.0.0 beta2. If=20
anybody interested, contact me...

Well, the subject:
Looks like there should be removeLine method in dynapi.gui.Graphics=20
object, like this:


Graphics.prototype.removeLine =3D function(shape) {
        if (Graphics.useVML)    this._dlyr.elm.removeChild(shape.elm);
        else this._dlyr.removeChild(shape);
        return ;
};



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-------------------------------------------------------------------------=

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://www.mail-archive.com/dyn...@li.../

[Dynapi-Dev] update for DynAPI 3.0.0 Beta 2

[Andriy K. <an...@po...>]

Hi people, Dan!
I was using DynAPI a years ago, when it was hosted on  
www.dansteinman.com. I'm glad DynAPI project still alive :)
Thanks to all developers!

Recently we need a tool for nagios hostextinfo.cfg visual  
configuration. There is script in the net (cheops-ng2nagios) for this  
purpose using gnome-libs and a lot of other stuff... Due to  
installation problem I made a new one based on DynAPI 3.0.0 beta2. If  
anybody interested, contact me...

Well, the subject:
Looks like there should be removeLine method in dynapi.gui.Graphics  
object, like this:


Graphics.prototype.removeLine = function(shape) {
	if (Graphics.useVML) 	this._dlyr.elm.removeChild(shape.elm);
	else this._dlyr.removeChild(shape);
	return ;
};



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

RE: [Dynapi-Dev] weird dynapi problem with setHTML, IE, and images

[<jir...@co...>]

Hi,
Is this list still alive, or is my subscribtion faulty ?

Cheers,
J.


-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...] On Behalf Of Anton Roolaart
Sent: Friday, December 30, 2005 3:49 PM
To: dyn...@li...
Subject: [Dynapi-Dev] weird dynapi problem with setHTML, IE, and images

Hi,

I need some help....

I've been using dynapi for a long time...
I've tried version 2.5.6 and 3.0x beta... I thought that 3.x might have 
fixed this issue which I believe is an IE issue/bug but I"m not sure.
I can't get it working for IE with both releases...However, FF and 
Mozilla work fine.  I did see an example page here that lead me to 
believe I could get it working:

http://www.messe-duesseldorf.de/md/dynapi/examples/dynapi.api.sethtml.htm 
(don't know what version he's using)

The above example page works for IE when I fill in an image located at 
any URL... in the field provided... hummm so I don't know why it doesn't 
work for me.

Here's what I'm doing...

I'm trying to create a dynlayer and when a user clicks on an image I 
want to use setHTML method
to produce a larger version of the image and scroll the image into the 
viewing area of the browser...
I've spent MANY hours trying to figure out why it doesn't work in IE.  
The funny thing is setHTML for text and other HTML elements works in IE, AND
to make it even more interesting is that it works correctly in IE when I 
have the web site on my local PC (it loads the images fine after a click 
on the smaller image).  One more important thing, when I uploaded the 
web site at the below URL I can get IE to show the larger picture if I 
right-click and use IE's "Show Picture" .. .then it shows up... What's 
up with that?"  

Here is the page that I'm working on:

http://www.arteffects.info/stone.shml

Try it in Mozilla and then IE and you'll see what I'm trying to 
do...Mozilla works fine.

I'm using latest versions of Mozilla and IE on XP (latest updates too).

I need to come up with a solution ASAP.   I know of some work arounds... 
but I was hoping to just be able to modify the menu1.js file.

Regards

Anton




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://www.mail-archive.com/dyn...@li.../

[Dynapi-Dev] weird dynapi problem with setHTML, IE, and images

[Anton R. <an...@te...>]

Hi,

I need some help....

I've been using dynapi for a long time...
I've tried version 2.5.6 and 3.0x beta... I thought that 3.x might have 
fixed this issue which I believe is an IE issue/bug but I"m not sure.
I can't get it working for IE with both releases...However, FF and 
Mozilla work fine.  I did see an example page here that lead me to 
believe I could get it working:

http://www.messe-duesseldorf.de/md/dynapi/examples/dynapi.api.sethtml.htm 
(don't know what version he's using)

The above example page works for IE when I fill in an image located at 
any URL... in the field provided... hummm so I don't know why it doesn't 
work for me.

Here's what I'm doing...

I'm trying to create a dynlayer and when a user clicks on an image I 
want to use setHTML method
to produce a larger version of the image and scroll the image into the 
viewing area of the browser...
I've spent MANY hours trying to figure out why it doesn't work in IE.  
The funny thing is setHTML for text and other HTML elements works in IE, AND
to make it even more interesting is that it works correctly in IE when I 
have the web site on my local PC (it loads the images fine after a click 
on the smaller image).  One more important thing, when I uploaded the 
web site at the below URL I can get IE to show the larger picture if I 
right-click and use IE's "Show Picture" .. .then it shows up... What's 
up with that?"  

Here is the page that I'm working on:

http://www.arteffects.info/stone.shml

Try it in Mozilla and then IE and you'll see what I'm trying to 
do...Mozilla works fine.

I'm using latest versions of Mozilla and IE on XP (latest updates too).

I need to come up with a solution ASAP.   I know of some work arounds... 
but I was hoping to just be able to modify the menu1.js file.

Regards

Anton

RE: [Dynapi-Dev] loading *.js files - resolved ?

[<jir...@co...>]

Hi,

Thanks for pointing me to the tip.createwidget.html.

I put my files to src/dod4/ folder and added these lines to the =
packages.js:

// dod4
l.addPackage('dynapi.dod4',p+'dod4/');
l.add('dynapi.dod4.data','data.js');
l.add('dynapi.dod4.showhide','showhide.js');
l.add('dynapi.dod4.mouse','mouse.js');
l.add('dynapi.dod4.image','image.js');


and then this into my index.html:
...
	dynapi.library.setPath('./src/');
	dynapi.library.include('dynapi.api');
	dynapi.library.include('dynapi.debug');
	dynapi.library.include('dynapi.library');
=09
	dynapi.library.include('dynapi.dod4');


The files load just fine, but the DynAPI debugger still says:

...
loaded [dynapi.api.DynLayer]
loaded [dynapi.api.MouseEvent]
Library Error: could not find [data]
Library Error: could not find [showhide]
Library Error: could not find [mouse]
Library Error: could not find [image]


Do i need to worry about this?
Is there a better way to include the files?

Thanks,
Jirka



-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...] On Behalf Of Leif W
Sent: Monday, October 17, 2005 12:40 AM
To: dyn...@li...
Subject: Re: [Dynapi-Dev] loading *.js files

> From: Ji=F8=ED Bla=BEek / comcare <jir...@co...>
> Received: Sat, 15 Oct 2005 05:40:44 PM EDT
>=20
> I am updating an old site done in dynAPI 2.54 to work with dynapi3.

Hopefully you've noticed it's not a drop-in replacement.  Some things =
are a
bit different... widgets, function names, arguments (type or order)...
general
API differences.

> Due to my lack of knowledge of both Javascript and dynAPI, I don't =
know
how
> to include my .js files.

Old JS files can't be dropped in and expected to automatically work... =
but
to
include files, check the stuff in "examples".  View the source.

> It used to be like this:
>=20
> DynAPI.include('data.js','./scripts/')

If you need to create new widgets, you probably want to put them under =
src,
maybe make your own folder, but otherwise follow the tips for creating
widgets.

dynapi/docs/docs/tip.createwidget.html
=20
> How do i do this with the new library syst=E9m? I have the DynAPI 2.9

The current release is dynapi-3.0.0-beta2.  It is a dump of the CVS as =
of
early August 2005.  Several bugs had been fixed since the beta1 release.

> changelog, but I still don't understand. Is there anywhere else to =
find
more
> information on this?

Most of the formal documentation is under the docs folder, and code is =
in
the
examples folder.

If you are converting, it may be easier to identify all the widgets you =
use
in
DynAPI2, then look through the examples, make some of your own =
modifications
as needed, and so determine which of the DynAPI3 widgets you can use, =
and
then
have an idea of what (if anything) you might need to create or port.

Without downloading anything, you can look at
http://dynapi.sourceforge.net/releases/ to find the most current version =
of
the API.  I try to update the CVS there when I add something to real =
CVS,
but
it is not an exact mirror and not automated so it can lag behind actual =
CVS.


Leif




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, =
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://www.mail-archive.com/dyn...@li.../

Re: [Dynapi-Dev] loading *.js files

[Leif W <war...@us...>]

> From: Ji=F8=ED Bla=BEek / comcare <jir...@co...>
> Received: Sat, 15 Oct 2005 05:40:44 PM EDT
> =

> I am updating an old site done in dynAPI 2.54 to work with dynapi3.

Hopefully you've noticed it's not a drop-in replacement.  Some things are=
 a
bit different... widgets, function names, arguments (type or order)... ge=
neral
API differences.

> Due to my lack of knowledge of both Javascript and dynAPI, I don't know=
 how
> to include my .js files.

Old JS files can't be dropped in and expected to automatically work... bu=
t to
include files, check the stuff in "examples".  View the source.

> It used to be like this:
> =

> DynAPI.include('data.js','./scripts/')

If you need to create new widgets, you probably want to put them under sr=
c,
maybe make your own folder, but otherwise follow the tips for creating
widgets.

dynapi/docs/docs/tip.createwidget.html
 =

> How do i do this with the new library syst=E9m? I have the DynAPI 2.9

The current release is dynapi-3.0.0-beta2.  It is a dump of the CVS as of=

early August 2005.  Several bugs had been fixed since the beta1 release.

> changelog, but I still don't understand. Is there anywhere else to find=

more
> information on this?

Most of the formal documentation is under the docs folder, and code is in=
 the
examples folder.

If you are converting, it may be easier to identify all the widgets you u=
se in
DynAPI2, then look through the examples, make some of your own modificati=
ons
as needed, and so determine which of the DynAPI3 widgets you can use, and=
 then
have an idea of what (if anything) you might need to create or port.

Without downloading anything, you can look at
http://dynapi.sourceforge.net/releases/ to find the most current version =
of
the API.  I try to update the CVS there when I add something to real CVS,=
 but
it is not an exact mirror and not automated so it can lag behind actual C=
VS.


Leif

[Dynapi-Dev] loading *.js files

[<jir...@co...>]

Hi,

I am updating an old site done in dynAPI 2.54 to work with dynapi3.
Due to my lack of knowledge of both Javascript and dynAPI, I don't know =
how
to include my .js files.


It used to be like this:

DynAPI.include('data.js','./scripts/')

How do i do this with the new library syst=E9m? I have the DynAPI 2.9
changelog, but I still don't understand. Is there anywhere else to find =
more
information on this?


Thanks,
Jirka

[Dynapi-Dev] Re: [ dynapi-Bugs-1274309 ] unable to redraw dynlayer object in IE 6.0

[Leif W <war...@us...>]

> From: "SourceForge.net" <no...@so...>
> Sent: 2005 September 01 Thursday 10:14

> ----------------------------------------------------------------------
>
> Comment By: Andrew Gillett (agillett)
> Date: 2005-09-01 08:04
>
> Message:
> Logged In: YES
> user_id=134108
>
> The removeFromParent() function deletes the DIV element
> associated with the DynLayer from the DOM. The addChild()
> function creates a new element and inserts it into the
> parents (layer1) DOM.

I didn't see the "delete" (builtin?) function called, but did see false 
and null assignments.

removeFromParent in event.js line 196 calls removeChild
removeChild in event.js line185 calls _remove, sets dyndoc, elm, css, 
and doc to null, and calls dropChildIndex
_remove in dynlayer_base.js line 107 calls removeChild (recursive), else 
sets outerHTML to empty string, elm to null, and releases key and mouse 
events

deleteFromParent in event.js line 172 calls deleteChild
deleteChild in event.js line 164 calls _destroy and dropChildIndex
_destroy is defined differently in dyndocument and dynlayer objects as 
they do different things
    we want the _destroy for dynlayer objects
_destroy in dynlayer_base.js line 76 calls _destroyAllChildren, 
removeAllEventListeners, _remove, and sets a bunch of values to null.

To me, they seem to be doing nearly the same thing.  They both call 
_remove.  I don't understand why there's functions with remove, delete, 
and destroy which all do similar things, namely render an object's 
contents or the object itself unusable.  Why do we need three functions 
to do nearly the same thing?  If we do need three, then we can pick more 
suitable names for them.  The following ideas would break compatibility 
but with the benefit of greatly simplifying things.

For me, removeFromParent should remove the parent/child relationship in 
DynAPI, leave the object intact, and hide it.  deleteFromParent should 
destroy the object.  Then destroy is superfluous.  But that is still 
confusing because DOS and U*IX file system commands rm and del tend to 
be thought of as the same thing.  Since it's parent/child relationship, 
maybe call the function removeFromParent orphan and call removeChild 
disown or abandon.  ;-)  Then we can use destroy, delete or remove (pick 
one, I like delete) for the function names which obliterate objects and 
free memory back to the browser.  Disown and abandon however may or may 
not describe it well, it's more like unlink, but that is a Perl/UN*X 
synonym for file deletion or removal.  detachFromParent, detachChild 
might be a better choice.

> The problem is that the _create() function in dynlayer_ie.js
> uses "document.createElement()" to create the new DIV
> element. Because this action is initiated from your "Set
> Desktop" button, the "document" variable refers to the menu
> document, not the content document. You cannot add an
> element created in one frame to the DOM of another frame.

Oh yeah, you can't just take a DOM element and unhook it, can you?  If 
it's created using DOM, it's got to be tucked away in a hidden part of 
the DOM.  We could make a hidden orphanage, and just put all the orphans 
there.  :-)  Or if using detach names simply called it detached.  Is 
that a feasible idea?

Leif

Re: [Dynapi-Dev] DynAPI 1 & 2?

[<do...@cr...>]

The translation layer is what came to my mind about a paragraph before you
mentioned it.. howver, you are right that it would be nightmare to porduce and
maintain... Plus many, if not most, users of DynAPI tend to make their own
modifications to the code for whatever reason.. This I think would make it
really quite difficult.

As for porting all the widgets.. I'm all over that.
Tho if we are going to do that I'd like to see a documented standard..
(yes, i pulled out the 'S' word again)

Nothing too fancy, just a description of the basic structure, and all expected
functionality.. maybe revive the style object, or whatnot.

It would be nice to see all ported widgets implement the border manager, the
existing button objetc, existing form objetcs, etc so that they are more
tightly bundled with the API and associated files. 

Thus an update to the DynAPI border manager that fixes Bug X in browser Y
would fix said bug for all widgets that use borders (for example)
Or for another example, say we find a more efficient button animation method,
then all widgets which use the button-image object would automatically use the
new code.. etc, etc...

Leif W <war...@us...> said:

> Hmm, I'm skimming through the recently pinged bug reports and noticed a 
> DynAPI 2 question raised by Doug, "Are we patching DynAPI 2 for 
> distribution?" (paraphrase).
> 
> Short answer is no.  Why?  Because we have a lot of work to do on DynAPI 
> 3 still.
> 
> Long answer?  I think it would be great to consider this for a moment. 
> This is just pure speculation at this point.
> 
> Should we continue to upgrade DynAPI 2 and DynAPI 1 for that matter, to 
> run in the most recent browsers?  I wonder about the feasibility of this 
> at the moment and in the future.  Shall we endeavour to maintain three 
> targets as opposed to one, when it's all we can do to work on the most 
> recent one?  It's not feasible at present with the number of volunteer 
> hours we have.  There have been some other parties who have done a bit 
> of this work on their own, notably getting DynAPI to run in Gecko 
> engines.  But integrating and testing everything, that's a trick.
> 
> Am I personally opposed to this?  No.  In the back of my mind I think it 
> would be nice to bring the older versions up to dat, if at all possible. 
> But, there's so many different browsers, and during each AI incarnation, 
> different browsers and version reigned.  It would all have to be recoded 
> to split up arch as needed, to avoid dumping it all into single large 
> files with a bunch of if/else conditionals.  That would be a nightmare.
> 
> In any event, the pipe dream would be to have a drop-in replacement, so 
> nothing has to be done to old code.  Hmm, well, yeah, impossible, but 
> let's play "what if?".  What if we had some translation layer on top of 
> the newest API, so you could optionally bridge the gap between the two 
> namespaces (current and whatever the old was).  Likewise, a nightmare 
> for maintenance, probably sluggish for performance.  But hey, computers 
> are a lot faster now, right?
> 
> Hmm, yeah, so then there's also the idea, what if we could provide a 
> conversion tool.  Let the end-developer run this tool on their DynAPI 1 
> or DynAPI 2 code, and convert it to a DynAPI 3 target.  Nice, but 
> probably quite difficult to achieve, when you consider the amalgamation 
> of widgets that were never ported or dupliated across all DynAPI 
> revisions.  Then you also have to consider that people may prefer DynAPI 
> 1 or DynAPI 2, so a conversion or translation layer should be able to go 
> back and forth any DynAPI version.
> 
> So, we come to the final two ideas for ways to handle this.
> 
> First, we make a push to port all DynAPI 1 and DynAPI 2 widgets to 
> DynAPI 3 platform and techniques.  During this process we make note of 
> the steps involved.
> 
> Second, we update the documentation based on the notes, so an 
> end-developer can understand how to go back and forth.  This provides 
> the groundwork for some of the previously mentioned ideas.
> 
> These are probably the most realistic things that could be achieved, but 
> are still by no means feasible at present.  If we get to the point where 
> DynAPI 3 satisfies most people, then maybe we can put new features on 
> hold and revisit the ideas to recycle some old code.
> 
> Ideas?  Opinions?
> 
> Leif
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
> 



-- 

Re: [Dynapi-Dev] DynAPI 3.0.0 Beta 2 release notice.

[<do...@cr...>]

Just browsed the release notes..
It's amazing just how much change a couple years can bring :-P
It's also very nice to continue to see forward movement in this project, even
if it is at a snail's pace hehe

cheers
Leif W <war...@us...> said:

> Well, if you missed the release announcement this morning, it's because 
> you're not subscribed to the dynapi-announce mailing list.  :-)
> 
> DynAI 3.0.0 Beta 2 is released.  Go check it out.
> 
> http://dynapi.sourceforge.net/ (SF has some DB load issues, this is slow 
> or broken).
> 
> Or check the dynapi-announce mail archive.
> Or go straight to the project page's File Release System.
> 
> Leif
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
> 



-- 

Re: [Dynapi-Dev] DynAPI 1 & 2?

[<jir...@co...>]

Hey Leif,

thanks for the effort and time you put in this project.
You know from my recent post that I would make a good use of DynAPI2 working 
with latest browsers, but...

From what i read, my suggestion is get 3 up and running and have a good 
documentation and possibly manual written. If the developers have a sound 
documentation on 3 it would make much more sense to work with 3 that going 
back to 2 or even 1, wouldn't it.

cheers,
Jirka




----- Original Message ----- 
From: "Leif W" <war...@us...>
To: <dyn...@li...>
Sent: Wednesday, August 03, 2005 2:31 PM
Subject: [Dynapi-Dev] DynAPI 1 & 2?


> Hmm, I'm skimming through the recently pinged bug reports and noticed a 
> DynAPI 2 question raised by Doug, "Are we patching DynAPI 2 for 
> distribution?" (paraphrase).
>
> Short answer is no.  Why?  Because we have a lot of work to do on DynAPI 3 
> still.
>
> Long answer?  I think it would be great to consider this for a moment. 
> This is just pure speculation at this point.
>
> Should we continue to upgrade DynAPI 2 and DynAPI 1 for that matter, to 
> run in the most recent browsers?  I wonder about the feasibility of this 
> at the moment and in the future.  Shall we endeavour to maintain three 
> targets as opposed to one, when it's all we can do to work on the most 
> recent one?  It's not feasible at present with the number of volunteer 
> hours we have.  There have been some other parties who have done a bit of 
> this work on their own, notably getting DynAPI to run in Gecko engines. 
> But integrating and testing everything, that's a trick.
>
> Am I personally opposed to this?  No.  In the back of my mind I think it 
> would be nice to bring the older versions up to dat, if at all possible. 
> But, there's so many different browsers, and during each AI incarnation, 
> different browsers and version reigned.  It would all have to be recoded 
> to split up arch as needed, to avoid dumping it all into single large 
> files with a bunch of if/else conditionals.  That would be a nightmare.
>
> In any event, the pipe dream would be to have a drop-in replacement, so 
> nothing has to be done to old code.  Hmm, well, yeah, impossible, but 
> let's play "what if?".  What if we had some translation layer on top of 
> the newest API, so you could optionally bridge the gap between the two 
> namespaces (current and whatever the old was).  Likewise, a nightmare for 
> maintenance, probably sluggish for performance.  But hey, computers are a 
> lot faster now, right?
>
> Hmm, yeah, so then there's also the idea, what if we could provide a 
> conversion tool.  Let the end-developer run this tool on their DynAPI 1 or 
> DynAPI 2 code, and convert it to a DynAPI 3 target.  Nice, but probably 
> quite difficult to achieve, when you consider the amalgamation of widgets 
> that were never ported or dupliated across all DynAPI revisions.  Then you 
> also have to consider that people may prefer DynAPI 1 or DynAPI 2, so a 
> conversion or translation layer should be able to go back and forth any 
> DynAPI version.
>
> So, we come to the final two ideas for ways to handle this.
>
> First, we make a push to port all DynAPI 1 and DynAPI 2 widgets to DynAPI 
> 3 platform and techniques.  During this process we make note of the steps 
> involved.
>
> Second, we update the documentation based on the notes, so an 
> end-developer can understand how to go back and forth.  This provides the 
> groundwork for some of the previously mentioned ideas.
>
> These are probably the most realistic things that could be achieved, but 
> are still by no means feasible at present.  If we get to the point where 
> DynAPI 3 satisfies most people, then maybe we can put new features on hold 
> and revisit the ideas to recycle some old code.
>
> Ideas?  Opinions?
>
> Leif
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
> 

[Dynapi-Dev] DynAPI 1 & 2?

[Leif W <war...@us...>]

Hmm, I'm skimming through the recently pinged bug reports and noticed a 
DynAPI 2 question raised by Doug, "Are we patching DynAPI 2 for 
distribution?" (paraphrase).

Short answer is no.  Why?  Because we have a lot of work to do on DynAPI 
3 still.

Long answer?  I think it would be great to consider this for a moment. 
This is just pure speculation at this point.

Should we continue to upgrade DynAPI 2 and DynAPI 1 for that matter, to 
run in the most recent browsers?  I wonder about the feasibility of this 
at the moment and in the future.  Shall we endeavour to maintain three 
targets as opposed to one, when it's all we can do to work on the most 
recent one?  It's not feasible at present with the number of volunteer 
hours we have.  There have been some other parties who have done a bit 
of this work on their own, notably getting DynAPI to run in Gecko 
engines.  But integrating and testing everything, that's a trick.

Am I personally opposed to this?  No.  In the back of my mind I think it 
would be nice to bring the older versions up to dat, if at all possible. 
But, there's so many different browsers, and during each AI incarnation, 
different browsers and version reigned.  It would all have to be recoded 
to split up arch as needed, to avoid dumping it all into single large 
files with a bunch of if/else conditionals.  That would be a nightmare.

In any event, the pipe dream would be to have a drop-in replacement, so 
nothing has to be done to old code.  Hmm, well, yeah, impossible, but 
let's play "what if?".  What if we had some translation layer on top of 
the newest API, so you could optionally bridge the gap between the two 
namespaces (current and whatever the old was).  Likewise, a nightmare 
for maintenance, probably sluggish for performance.  But hey, computers 
are a lot faster now, right?

Hmm, yeah, so then there's also the idea, what if we could provide a 
conversion tool.  Let the end-developer run this tool on their DynAPI 1 
or DynAPI 2 code, and convert it to a DynAPI 3 target.  Nice, but 
probably quite difficult to achieve, when you consider the amalgamation 
of widgets that were never ported or dupliated across all DynAPI 
revisions.  Then you also have to consider that people may prefer DynAPI 
1 or DynAPI 2, so a conversion or translation layer should be able to go 
back and forth any DynAPI version.

So, we come to the final two ideas for ways to handle this.

First, we make a push to port all DynAPI 1 and DynAPI 2 widgets to 
DynAPI 3 platform and techniques.  During this process we make note of 
the steps involved.

Second, we update the documentation based on the notes, so an 
end-developer can understand how to go back and forth.  This provides 
the groundwork for some of the previously mentioned ideas.

These are probably the most realistic things that could be achieved, but 
are still by no means feasible at present.  If we get to the point where 
DynAPI 3 satisfies most people, then maybe we can put new features on 
hold and revisit the ideas to recycle some old code.

Ideas?  Opinions?

Leif

[Dynapi-Dev] DynAPI 3.0.0 Beta 2 release notice.

[Leif W <war...@us...>]

Well, if you missed the release announcement this morning, it's because 
you're not subscribed to the dynapi-announce mailing list.  :-)

DynAI 3.0.0 Beta 2 is released.  Go check it out.

http://dynapi.sourceforge.net/ (SF has some DB load issues, this is slow 
or broken).

Or check the dynapi-announce mail archive.
Or go straight to the project page's File Release System.

Leif

Re: [Dynapi-Dev] Does Dynapi support AJAX?

[Leif W <war...@us...>]

> From: <jy...@mo...>
> Sent: 2005 July 31 Sunday 13:44
>

> Itd be really nice if Dynapi did support AJAX and provided an 
> interface to

As I understand it, AJAX is a collection of techniques, not a 
specification or protocol.  So in that regard nothing can ever support 
AJAX until it is formally defined in a RFC or specification or 
something.  Then applications can all agree to do things "The AJAX Way". 
Right now it's a general concept of how to use a mixture of different 
web technologies.

> some PHP library that generated Dynapi UI changes on the fly.

There is the IOElement and SODA infrastructure.  These allow data to be 
exchanged asynchronously from the user interface.  What is done with 
that data (UI actions and whatnot) has been left as an exercise for the 
developer.

> OK, for those not familiar with AJAX: 
> http://en.wikipedia.org/wiki/AJAX

I've been roughly familiar with the concept since about the year 2000. 
It has only recently gotten this AJAX name, earlier this year I think. 
It will probably be a matter of months before "standardizations" start 
to emerge.

> And a PHP server side AJAX library that generates UI changes:
> http://xajax.sourceforge.net/
>
> You'll see that all the client UI changes are expressed in the server
> code, which makes writing server applications (and client side UIs 
> :) )
> very simple.
>
> Just an idea :)

Ahh, cool.  See, that functionality didn't exist a few months ago unless 
you did it yourself.  It definitely needs to be examined how best to 
proceed.  It would be nice if we could drop-in some other project's 
implementation instead of duplicating work efforts.  It would be nice to 
improve upon what already exists.  If you have already examined both 
DynAPI's IOElement/SODA (in CVS) and xajax, and have a specific 
suggestion, please discuss here.  If you have a detailed outline of some 
ideas, submit a feature suggestion to the trackers, so we don't forget.

Leif

[Dynapi-Dev] Does Dynapi support AJAX?

[<jy...@mo...>]

Itd be really nice if Dynapi did support AJAX and provided an interface to
some PHP library that generated Dynapi UI changes on the fly.

OK, for those not familiar with AJAX: http://en.wikipedia.org/wiki/AJAX

And a PHP server side AJAX library that generates UI changes:
http://xajax.sourceforge.net/

You'll see that all the client UI changes are expressed in the server
code, which makes writing server applications (and client side UIs :) )
very simple.

Just an idea :)

Re: [Dynapi-Dev] SODA-RPC and php5

[Leif W <war...@us...>]

> From: "=D7=E5=F0=ED=E5=F6=EE=E2 =CC=E8=F5=E0=E8=EB" <div...@ya...=
>
> Sent: 2005 July 31 Sunday 09:34
>

> Hi DynAPI developers!!! =3D)
>


Hi and thank you for the interest in DynAPI!

> php, dynapi and soda. I got the latest(??) release version 3.0.0 and

The latest release is 3.0.0-beta1.  A 3.0.0-beta2 release is planned=20
sometime this week.  If you can wait, ok, but if not, just grab a CVS=20
copy.

> tried to apply soda-rpc examples to the latest version of php5.1.x.
> And if i am right it turned out that it does not work with php 5?

Last time I checked it didn't even work with PHP3 or PHP4.  It was=20
incomplete, and the coded parts were having issues with different=20
flavors/versions of PHP4.

> So, i wanted to ask is there anibody in your team working on this

Hmm, well, I was the one who started it.  I have plans to work on it,=20
but not the time to sit down and do it right now.

> subject? And if there any way i could help u work in that direction?

Well, if you can get it to work, then great.  Someone else contributed=20
some PHP4 code, but as an email attachment to me.  It's on a disc I=20
can't access right now.  :-\  One of the things I am working on is to=20
get the data off that disc.  If you make changes, make it work in both=20
PHP4 and PHP5, or just label it as .php5.  Submit it to the Patches=20
tracker, so there won't be loss or delays getting it in the future.

> Thank u!

Thank you!

Leif

[Dynapi-Dev] SODA-RPC and php5

[<div...@ya...>]

Hi DynAPI developers!!! =)

Not so long ago I have found out abput the excistence of this project,
made sure that it is REALLY COOL and POWERFULL and decided to use it
in my development routine. I am a web(and also php) developer and got
very interested in development of such dynamic web applications using
php, dynapi and soda. I got the latest(??) release version 3.0.0 and
tried to apply soda-rpc examples to the latest version of php5.1.x.
And if i am right it turned out that it does not work with php 5?

So, i wanted to ask is there anibody in your team working on this
subject? And if there any way i could help u work in that direction?

Thank u!

Re: [Dynapi-Dev] inline layer funness

[Leif W <war...@us...>]

Just to let you know I saw this and the 7 other Bugs tracker 
notifications on Friday (thanks to dynapi-notify, which already has four 
other subscribers besides myself, yay!).  I've got one system running 
now after quite a bit of rebuild and recovery.  I'll try to play with 
some of the code tomorrow (err, later today).  I'm about ready for bed 
so I'll just read them now and think of it as I sleep.  Thanks very much 
for pointing out what needs attention and giving some ideas.

I can only test on IE6 at the moment.  Maybe more in the future.

Leif

----- Original Message ----- 
From: <do...@cr...>
To: <dyn...@li...>
Sent: 2005 July 29 Friday 14:08
Subject: [Dynapi-Dev] inline layer funness


>
>
>
> yes i know.. funness is not a word :-P
>
> Okay, in the past when you use dynapi.inline to load an inline layer 
> that did
> not have positioning set, the layers .x and .y would be inistialzed to 
> 0
>
> I done fixed it!
>
> When you do not set a left or top in the style (eitherin style sheet 
> on inline
> style) IE fills these propeties with "auto" so lines 51 and 52
> in dynlayer.inline.js :
> dlyr.x = parseInt(css.left);
> dlyr.y = parseInt(css.top);
>
> both values equate to 0 (parseInt('auto') == 0)
>
> Da fix! NOT CONFIRMED IN ANY OTHER VERSION OF IE
>
> Lines: 51 and 52
> in dynlayer.inline
> dlyr.x = parseInt((css.left!="auto")?css.left:dlyr.elm.offsetLeft);
> dlyr.y = parseInt((css.top!="auto")?css.top:dlyr.elm.offsetTop);
>
> This done fixes it for top level layers: have not checked out child 
> layers yet
> I am at work and can't spend too much time on this but wanted to get 
> it out to
> you guys.
>
> For frowards compatability we could use the following instead (check 
> for 0
> rather than for "auto")
>
> dlyr.x = parseInt(css.left)||dlyr.elm.offsetLeft;
> dlyr.y = parseInt(css.top)||dlyr.elm.offsetTop;
>
> If will check this out for child layers ect when i get home or on the 
> weekend.
>
> Feel free to remind me if I let it slide :-P
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
>
> 

[Dynapi-Dev] inline layer funness

[<do...@cr...>]

yes i know.. funness is not a word :-P

Okay, in the past when you use dynapi.inline to load an inline layer that did
not have positioning set, the layers .x and .y would be inistialzed to 0

I done fixed it!

When you do not set a left or top in the style (eitherin style sheet on inline
style) IE fills these propeties with "auto" so lines 51 and 52
in dynlayer.inline.js : 
dlyr.x = parseInt(css.left);
dlyr.y = parseInt(css.top);

both values equate to 0 (parseInt('auto') == 0)

Da fix! NOT CONFIRMED IN ANY OTHER VERSION OF IE

Lines: 51 and 52
in dynlayer.inline
dlyr.x = parseInt((css.left!="auto")?css.left:dlyr.elm.offsetLeft);
dlyr.y = parseInt((css.top!="auto")?css.top:dlyr.elm.offsetTop);

This done fixes it for top level layers: have not checked out child layers yet
I am at work and can't spend too much time on this but wanted to get it out to
you guys.

For frowards compatability we could use the following instead (check for 0
rather than for "auto")

dlyr.x = parseInt(css.left)||dlyr.elm.offsetLeft;
dlyr.y = parseInt(css.top)||dlyr.elm.offsetTop;

If will check this out for child layers ect when i get home or on the weekend.

Feel free to remind me if I let it slide :-P

RE: [Dynapi-Dev] IE6 support for DynAPI2

[Leif W <war...@us...>]

> Ji=F8=ED Bla=BEek / comcare <jir...@co...>
> Thu, 28 Jul 2005 02:38:27 PM EDT
> =

> Thanks for the info.
> Is there a way to use the website code i wrote for 2.54 with DynAPI3 ?

DynAPI3 can do the same basic things but maybe different calls.  There is=

documentation regarding those changes.

http://dynapi.sourceforge.net/releases/dynapi-3.0.0-beta1/docs/changelog.=
html

This is the same as in the .zip file.

> Or is DynAPI3 a completely different thing. What happened to all the
DynAPI1

It's different in that some of the function calls are different, and even=
t
handlers are set up a bit different.  It might be confusing at first but =
seems
a bit easier after a while.

> and 2 websites? They all died when IE6 appeared:) ? I cant believe it.

Dan has gone off the internet for a few years.  I wasn't able to retrieve=
 the
domain names as the domain registrars have some policy to ignore everyone=
,
even those with a just claim to a domain, and a 5 year history of ownersh=
ip. =

Unless I get a powerful group of international internet lawyers and the m=
oney
to pay them, then those domains are gone.

> To be honest, I primarilly used DynAPI for it was cross-browser and I
didn't
> have to worry about optimizing code for different browsers. So this sit=
e
> didn't use any advanced widgets, mostly dynlayers and mouse events acti=
on.
> =

> You can see it at>
> http://www.comcare.cz/dynapi/archive/dod/latest.html
> =

> =

> If it is too difficult i will have to drop it, I just wanted to make 10=
0%
> sure there is no way I can make this work within less then 10 hours.

Well, it shouldn't be too difficult.  I can't estimate time requirements =
very
well.  You'll have to spend an hour or two to skim the docs and try some
things.  If you have any widgets, you will need to port them.  If you hav=
e any
widgets ported which you think might be generally useful, please submit t=
hem. =

If you make progress then you can probably complete in that time.  Feel f=
ree
to ask questions.  However, note that with my hardware problems, and lack=
 of
any permanently installed OS, I am severely limited in terms of testing,
developing or responding at the moment.  I'll try to keep checking my mai=
l
every so often, if possible.

Leif


> Thanks,
> Jirka
> =

> =

> =

> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...] On Behalf Of Leif W
> Sent: Thursday, July 28, 2005 4:52 PM
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] IE6 support for DynAPI2
> =

> > Ji=F8=ED Bla=BEek <jir...@co...>
> > Thu, 28 Jul 2005 10:31:10 AM EDT
> > =

> > Hi,
> > =

> > I developed a website back in 2001 based on DynAPI2.
> > Now the ppl ask me if it was possible to update it so it works on IE6=
=2E
> > =

> > I tried to find some info and it seems that DynAPI3 supports IE6. =

> > Is there a way to upgrade? That is, without rewriting the whole thing=
 :).
> > =

> > I was using version 2.54
> >  =

> > =

> > Thanks,
> > Jirka
> =

> Hi Jirka,
> =

> At present, there has not been much discussion to update DynAPI2 to sup=
port
> newer browsers.  I'm personally not opposed to it or anything.  It's ju=
st
> that
> trying to get current with DynAPI3 in preparation for a stable release =
is a
> higher priority.  Also my time and resources are limited and I'ving
hardware
> problems.
> =

> DynAPI3 (in CVS) will support IE6 better, but there may be undiscovered=

> bugs,
> as it's still in beta.  The DynAPI3 beta1 release has had a few problem=
s
and
> is patched in CVS.  A beta2 or rc1 release is planned for early August.=
 =

I'm
> still learning CVS and the SourceForge system, and while I have compute=
r
> problems I can't do much reading or testing of anything.
> =

> The DynAPI3 widget sets are different than DynAPI2.  Most DynAPI2 widge=
ts
> have
> not been ported to DynAPI3.  Those require some non-trivial modificatio=
ns. =

> I'm doing my best to fix my hardware, configure OSes, read about CVS & =
SF,
> and
> understand the DynAPI3 code.  If you do find specific problems, or make=
 any
> modifications to DynAPI, please submit bug reports, patches, feature
> requests,
> or new code using trackers on the SF developer's site.
> =

> Leif
> =

> =

> =

> =

> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
> =

> =

> =

> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://www.mail-archive.com/dyn...@li.../
> =

RE: [Dynapi-Dev] IE6 support for DynAPI2

[<jir...@co...>]

Thanks for the info.
Is there a way to use the website code i wrote for 2.54 with DynAPI3 ?

Or is DynAPI3 a completely different thing. What happened to all the =
DynAPI1
and 2 websites? They all died when IE6 appeared:) ? I cant believe it.

To be honest, I primarilly used DynAPI for it was cross-browser and I =
didn't
have to worry about optimizing code for different browsers. So this site
didn't use any advanced widgets, mostly dynlayers and mouse events =
action.

You can see it at>
http://www.comcare.cz/dynapi/archive/dod/latest.html


If it is too difficult i will have to drop it, I just wanted to make =
100%
sure there is no way I can make this work within less then 10 hours.

Thanks,
Jirka



-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...] On Behalf Of Leif W
Sent: Thursday, July 28, 2005 4:52 PM
To: dyn...@li...
Subject: Re: [Dynapi-Dev] IE6 support for DynAPI2

> Ji=F8=ED Bla=BEek <jir...@co...>
> Thu, 28 Jul 2005 10:31:10 AM EDT
>=20
> Hi,
>=20
> I developed a website back in 2001 based on DynAPI2.
> Now the ppl ask me if it was possible to update it so it works on IE6.
>=20
> I tried to find some info and it seems that DynAPI3 supports IE6.=20
> Is there a way to upgrade? That is, without rewriting the whole thing =
:).
>=20
> I was using version 2.54
> =20
>=20
> Thanks,
> Jirka

Hi Jirka,

At present, there has not been much discussion to update DynAPI2 to =
support
newer browsers.  I'm personally not opposed to it or anything.  It's =
just
that
trying to get current with DynAPI3 in preparation for a stable release =
is a
higher priority.  Also my time and resources are limited and I'ving =
hardware
problems.

DynAPI3 (in CVS) will support IE6 better, but there may be undiscovered
bugs,
as it's still in beta.  The DynAPI3 beta1 release has had a few problems =
and
is patched in CVS.  A beta2 or rc1 release is planned for early August.  =
I'm
still learning CVS and the SourceForge system, and while I have computer
problems I can't do much reading or testing of anything.

The DynAPI3 widget sets are different than DynAPI2.  Most DynAPI2 =
widgets
have
not been ported to DynAPI3.  Those require some non-trivial =
modifications.=20
I'm doing my best to fix my hardware, configure OSes, read about CVS & =
SF,
and
understand the DynAPI3 code.  If you do find specific problems, or make =
any
modifications to DynAPI, please submit bug reports, patches, feature
requests,
or new code using trackers on the SF developer's site.

Leif




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO =
September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
Security * Process Improvement & Measurement * =
http://www.sqe.com/bsce5sf
_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://www.mail-archive.com/dyn...@li.../

Re: [Dynapi-Dev] IE6 support for DynAPI2

[Leif W <war...@us...>]

> Ji=F8=ED Bla=BEek <jir...@co...>
> Thu, 28 Jul 2005 10:31:10 AM EDT
> =

> Hi,
> =

> I developed a website back in 2001 based on DynAPI2.
> Now the ppl ask me if it was possible to update it so it works on IE6.
> =

> I tried to find some info and it seems that DynAPI3 supports IE6. =

> Is there a way to upgrade? That is, without rewriting the whole thing :=
).
> =

> I was using version 2.54
>  =

> =

> Thanks,
> Jirka

Hi Jirka,

At present, there has not been much discussion to update DynAPI2 to suppo=
rt
newer browsers.  I'm personally not opposed to it or anything.  It's just=
 that
trying to get current with DynAPI3 in preparation for a stable release is=
 a
higher priority.  Also my time and resources are limited and I'ving hardw=
are
problems.

DynAPI3 (in CVS) will support IE6 better, but there may be undiscovered b=
ugs,
as it's still in beta.  The DynAPI3 beta1 release has had a few problems =
and
is patched in CVS.  A beta2 or rc1 release is planned for early August.  =
I'm
still learning CVS and the SourceForge system, and while I have computer
problems I can't do much reading or testing of anything.

The DynAPI3 widget sets are different than DynAPI2.  Most DynAPI2 widgets=
 have
not been ported to DynAPI3.  Those require some non-trivial modifications=
=2E =

I'm doing my best to fix my hardware, configure OSes, read about CVS & SF=
, and
understand the DynAPI3 code.  If you do find specific problems, or make a=
ny
modifications to DynAPI, please submit bug reports, patches, feature requ=
ests,
or new code using trackers on the SF developer's site.

Leif

[Dynapi-Dev] IE6 support for DynAPI2

[<jir...@co...>]

Hi,

I developed a website back in 2001 based on DynAPI2.
Now the ppl ask me if it was possible to update it so it works on IE6.

I tried to find some info and it seems that DynAPI3 supports IE6.=20
Is there a way to upgrade? That is, without rewriting the whole thing =
:).

I was using version 2.54
=20

Thanks,
Jirka

Re: [Dynapi-Dev] [ dynapi-Bugs-840767 ] mouse_ie.js null error, with possible patch

[Leif W <war...@us...>]

My replies are out of order for clarity.

> <do...@cr...>
> Mon, 25 Jul 2005 09:48:03 AM EDT
> =

> I always use the production version downloadable from the front page as=
 tis
is
> what any client will be evaluating.

Yeah, it's been so long, and there are at least a few non-trivial changes=
=2E =

We're all agreed, beta2 it is.

> I would like to get the current cvs packed up and delivered as the curr=
ent
> production version on the front page soonest, like say, Aug 7th? (for s=
ome
> reason i've started hating deadlines far less than I used to..)

Hmm, I'll try to do quicker than that.  I should just release whatever th=
ere
is now, and whatever we fix after release should be the next beta.  I jus=
t
have to learn how to make a release.  :p

> Ug.. more bugs you say?

Yeah well, it's still beta.  ;-)

> I will put asside an hour or so of my gaming time
> in the evenings to test and bughunt.

> To the lurkers: Please let us know you are out there.. even if you do n=
ot
have
> time to help with the current beta push, It would make me feel better
knowing
> that you guys ares till out there to help if we get in a bad bind with =
a
> particular bug :-)

There are open/unconfirmed/unresolved bug reports. Start with those.  See=
 if
they still exist.  Don't have to solve it now unless the solution occurs =
to
you.  Just at least check what you can in an hour.  Then just send a quic=
k
note here with eat bug number and wether or not you could verify/reproduc=
e,
wether or not any provided solutions (patches, info, etc.) solve the prob=
lem. =

Maybe do the same for patches.  The bugs and patches trackers ought to be=

related to existing code, and the feature requests and code submissions o=
ught
to be related to new code.  However over the years things could have gott=
en
intermingled, so we need to check those as well.

If at least 2-3 of us can not verify or reproduce a bug, we'll have to ju=
st
update the tracker and say we tried.  Otherwise hopefully be able to reso=
lve
some problems.  In any case we'll have a sense that we're current.

Leif