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

Re: [Dynapi-Dev] [Bug #130357] small typo in list.js

[Jordi 'I. M. <jmi...@or...>]

use two parenthesis and NS6 will do fine

if ((this.selected=b))

Don't ask me why


martin strom wrote:

> i think it would, the reason i found this "bug"
> was because ns6 thrown an error on that line..
>
> /m
>
> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Cameron Hart
> Sent: den 30 januari 2001 14:42
> To: dyn...@li...
> Subject: RE: [Dynapi-Dev] [Bug #130357] small typo in list.js
>
> perhaps it would be safer to assign the value first and then test the
> condition...
> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Michael
> Pemberton
> Sent: 30 January 2001 13:28
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] [Bug #130357] small typo in list.js
>
> please put the "typo" back.  What is does is set the value of this.selected
> to b and then evaluates the returned value (the new value of this.selected).
> It is needed to change the selected state of the item.
> no...@so... wrote:
> Bug #130357, was updated on 2001-Jan-28 14:27
> Here is a current snapshot of the bug.
> Project: DynAPI 2
> Category: Core - Widgets
> Status: Closed
> Resolution: Fixed
> Bug Group: None
> Priority: 5
> Submitted by: marstr
> Assigned to : rainwater
> Summary: small typo in list.js
> Details: there's a small typo (i think) in list.js line 76
> if (this.selected=b)
>
> should be
> if (this.selected==b)
>
> right?
> Follow-Ups:
> Date: 2001-Jan-28 17:50
> By: rainwater
> Comment:
> Doh!  Its been updated in CVS.  Closing this bug.
> -------------------------------------------------------
> For detailed info, follow this link:
> http://sourceforge.net/bugs/?func=detailbug&bug_id=130357&group_id=5757
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> --
> Michael Pemberton
> mp...@ph...
> ICQ: 12107010
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

[Dynapi-Dev] border on layer

[francesco A. <fa...@we...>]

hi,

how can i add a border at the css of a scrollpane?

please help

Francesco

Re: SV: [Dynapi-Dev] Next Generation 9

[Chris H. <ch...@lo...>]

Agreed.

You've not heard from me before (I think), but I've been a DynAPI fan for
while now.

I am a server-side developer, I churn out the odd few JS hacks now and then
to help my designers.

The point is we need solutions now.  It's nice you guys continuing the good
work and I agree that you want to get it right.  But version 2 has been
around for a while now and I'm sure there's enough in it to be the
foundation of a web front.  Time to draw a line and leave alterations to a
point release.

The good thing about version 2 is it means there may well be a version 3.




----- Original Message -----
From: "Pascal" <pb...@oi...>
To: <dyn...@li...>
Sent: Wednesday, January 31, 2001 10:00 AM
Subject: RE: SV: [Dynapi-Dev] Next Generation 9


> Here's just a thought (already pointed out by others)
>
> DynAPI2 is opensource, you can get your hands on the code.. so GET YOUR
> HANDS ON THE CODE, take the current code and turn it into your
> next-generation thingie.. The current DynAPI 2 (read the 2!) should be
> finished up as it is, we'll iron out the bugs, create widgets, editors,
etc.
> In any case it is just a BAD idea to completely turn this version over
> leaving all the users hanging and waiting for the "next release"
>
> When this version is stable and people can actually use it without
worrying
> about changes they have to keep up with  it will be time for new and
better
> things.. by that time Next Gen might be completed or working as the
current
> code is now (supporting old browsers but not working correct enough for
the
> newest browsers).
>
> We can keep discussing this for another few months, but why not just start
> the next generation with all the people who are for restructuring it (ask
> Dan for permission on using the DynAPI name :-)  open a sourceforge
account
> for it, and go be happy..  we'll stick to this old scripted code using the
> prototyping way of development and finish it up for useability.
>
>
> again, just a thought.
>
> ps. I'm actually starting to think that making an official release version
> was a bad idea
>
>
> Pascal Bestebroer (pb...@oi...)
> Software ontwikkelaar
> Oberon Informatiesystemen b.v.
> http://www.oibv.com
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

RE: SV: [Dynapi-Dev] Next Generation 9

[Pascal <pb...@oi...>]

Here's just a thought (already pointed out by others)

DynAPI2 is opensource, you can get your hands on the code.. so GET YOUR
HANDS ON THE CODE, take the current code and turn it into your
next-generation thingie.. The current DynAPI 2 (read the 2!) should be
finished up as it is, we'll iron out the bugs, create widgets, editors, etc.
In any case it is just a BAD idea to completely turn this version over
leaving all the users hanging and waiting for the "next release"

When this version is stable and people can actually use it without worrying
about changes they have to keep up with  it will be time for new and better
things.. by that time Next Gen might be completed or working as the current
code is now (supporting old browsers but not working correct enough for the
newest browsers).

We can keep discussing this for another few months, but why not just start
the next generation with all the people who are for restructuring it (ask
Dan for permission on using the DynAPI name :-)  open a sourceforge account
for it, and go be happy..  we'll stick to this old scripted code using the
prototyping way of development and finish it up for useability.


again, just a thought.

ps. I'm actually starting to think that making an official release version
was a bad idea


Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

Re: SV: [Dynapi-Dev] Next Generation 9

[<hv...@ya...>]

OK, this is not to hide somehting from the debate, but
I'm going to cut a few things out of this response. I
f anybody hasn't read these, please go back in the
thread if you're confused of anything re-discussed and
not in this post.

BTW this isn't just to flame or anything, I think we
are coming along good to understand eachothers POV.


 --- Bart Bizon <ba...@ho...> skrev: > 
> -----Ursprungligt meddelande-----
> Från: Henrik Våglin <hv...@ya...>
> Till: dyn...@li...
> <dyn...@li...>
> Datum: den 30 januari 2001 20:39
> Ämne: Re: [Dynapi-Dev] Next Generation 9
> 
> 
> 
> ----- Original Message ----- 
> From: "Barre Bizon" <ba...@ho...>
> To: <dyn...@li...>
> Sent: Tuesday, January 30, 2001 5:35 PM
> Subject: [Dynapi-Dev] Next Generation 9
> 
> 
I earlier wrote:
>[...] 
> There's reason why SCRIPTING languages like
> Javascript have evolved too 
[...]
>
---------------------------------------------------------------------------
> 

Bart replied:

> [...]
> But this is not my point. I'm talking about
> implementing consepts that are not hard to use, but
> eliminate a lot of potentially "bad" code.

My response:

Javascript prototyping is experimental coding. Does
this mean it's less valuble for developing? I vote:
not.


> Scripting languages are easy to work with, yes, but
> when projects evolve into the level of complexity
> that DynAPI has, it actually becomes a drawback in
> certain cases. I'm sure you have spent more than one
> occasion wasting hours on end trying to find that
> little but oh so annoying bug ;) Now I'm not saying
> this will happen automagically just because you
> stick to Javascript's own inheritance scheme. You
> might be a superprogrammer that never makes any
> errors :) But since not all of us are, it is vital
> to have a good foundation for programming with.
> And as great as JS is, I believe it can be improved
> upon.
> 

hehe, no I'm definatly not a superprogrammer, rather
the opposite. My point is rather on that it's not the
code that defines what you can do it, it's in the
programmers head. If the DynAPI developers in general
are more comfortable with the reform of code symantics
they should consider it. But AS IS the Next Gen
haven't showed off how this will be implemented. Work
out a model, some more working code and foremost -
document it extremely well. THEN the developers can
decide wheter or not it suits them and their purpose -
cause that's what's mostly driving this project. 

Might seem a long way to go, but as I've stated, these
things of evolvement should take time and establish
themselves before they make for the radical change.
DynAPI2 have taken 1 year to move this far from Dan
Steinman's original DynAPI 1. We should expect Next
Gen to consume at least the same time. In the mean
time I propose we stick to developing DynAPI2 in the
current direction. I can adapt Next Gen when its
established and if it prove to be as ease of use and
extensability (widget-building). Don't take me wrong,
I will help in any way I can to see how Next Gen come
off ground - as a side development. When it's fairly
ready for implementation, we can evalute it and
everybody can take stand on wheter to move their
development efforts there. I think the same goes for
any other new subprojet including my DynBuilder build.


> 
> The fundamentals was built on  dan steinman's DynAPI
> 1 build [...] 
> 
>
----------------------------------------------------------------
> 
> Yes, but this is not the foundation I'm talking
> about. [...]
> Yes, proper OOP gives you heavier shoes to
> wear, but the shoes are there for a reason; to
> protect you from the cold, right? You wouldn't climb
> a mountain (read:.DynAPI) ,  without proper shoes
> (read:OOP), now would you?   
> 

I'm of viking-blood, I can take a little cold of the
feet if it means I don't sink as soon as I get out on
deep waters, if you catch my drift ;) But really, the
metamorfos is like my point; just cause something
seems like the way to go, doesn't mean that it's the
best in every occation.
 
>[...] 
> I'm not saying that Javascript is not object
> oriented. It's just that it's lacking.
> 

In the words of Pascal: "where, why, and what?"
Provide an examplification please...

> 
> > What you would want, is to have somekind of Object
> 
> > providing the remaining OOP functionality that
> Javascript 
> > does not inherantly support, so that you don't
> have to 
> > recreate the wheel everytime you develop somekind
> of 
> > application or extension to it.
> > Pascals DynObject and Eytans SuperObject, are
> examples of 
> > what I'm talking about.
> > DynObject provides better modularity for DynAPI,
> and a 
> > SuperObject would provide the tools with which to
> better 
> > build a more modular DynAPI (there are a couple of
> more 
> > people that have developed a
> SuperObject/SuperClass).
> > 
> 
> They are great ideas and soloutions for sure (I
> actually admire those who can realise these), but is
> it the only way to go? Is it the only thing
> desirable? is it waht everyone desires? You're of
> course free to convience anyone, but don't think you
> know the one and only best soloution - cause there
> are none that works for everyone...
> 
> 
>
-------------------------------------------------------------------
> 
> Correct, this is not the only way to go. I believe
> that it is a very sound way to go. But this is only
> my opinion obviously.
>

So why should we take this way. Work out the grounds
first, then step onto it if it really is more stable
 
>[...]
> 
> Yes this is obviously my opinion. If  I still am
> sane enough to know that I'm only one person ( I
> don't think I'm schizofrenic yet...... ) ;)

nah, you seem sane enough :)

> But your'e missing my point and getting hung up on
> semantics. 
> 

Then prove me wrong, just don't tell me I'm wrong,
cause I won't buy that - and neither should anyone
else in my opinion. I think this is what the
developers in control are waiting for - or as in
Pascal's case; doing.
  
> 
> > 1. DynAPI is a programming tool/interface for
> creating 
> > dHtml.
> > Now programming is the key word here. No matter
> what, you 
> > still have to PROGRAM. If you would want to create
> a 
> > simpler interface for creating dHtml (a WYSIWYG
> for 
> > instance), there still has to be someone who
> creates this 
> > interface, and I guarantee you, it won't be a
> designer! ;)
> > 
> 
> I challenge you there, cause I've already begun to
> build a DynBuilder for WYSIWYG DynAPI development.
> Andd it's not wheter to do programming or not I'm
> discussing - it's the level of advanced programming
> that I simple think something called an API is meant
> to avoid (its in the name for christs sake!!! ;)
> 
> ----------------------------------------------
> 
> Challenge me on what, have you not programmed when
> doing DynBuilder?
> Are you a designer, not a programmer? What are you
> saying?
> I'm using the term programmer and designer strictly.
> But obviously a designer can be a programmer and
> vice versa.

Yes, a designer is also a programmer in most cases. UI
development is more than just slick and neat graphics
- it involves user-interaction programming. Keep the
terms separated cause strictly said scripting is also
a form of programming even if simplified (and what's
so wrong about that?).

And I'm challanging you to have something to present,
something that evalutes how it works and how the code
behind is to be written. That's all...

> The concepts I'm proposing wouldn't change the end
> programmers utilization of the API. At all.
> It would even simplify, second level developers
> (i.e. people not developing the actual core, but
> doing widgets and that sort of thing)
> 

Yeah, but what about the level of in-depth insight to
how it works. A project needs to be extremely
well-documented to not have that. I can't believe
something will work so well that I don't need to be
able to at least figuring out why it works if i'm to
build extensions. I'm a strong believer that the same
goes for the code behind as for the inteface in an
open source project, it should be "readible" even if
not down to it's core details. Once again (in risk of
being boring repeating) exemplify and show how it
works, before you propse the step to be taken. I know
the frustration in getting something done for sure,
but you can't keep crying for this kind of great
reformation unless you have the full grounds for
replacing the previous version (for example no one
actually officially joined in for the DynBuilder
project, though many talk big about its potentials -
no single out one meant)

> [...]
> 
> Right, I'm not saying this functionality should be
> inherent in DynAPI. It should be external and you
> should be able to use it for creating whatever you
> would want... I foresee that DynAPI will probably be
> split up sooner or later. There probably are a lot
> of you already modifying it for own purposes.
> 

Will split up? It's already fractioned, but somehow it
slowly binds together - and that's what's good about
it. That stated, there's no reason for contributors to
lean back, just that maybe it's sound to realise that
the volume of this project is in that state now and
that is how it works. I admire Robert for keeping it
all together as well as he does.

I wrote:
> 
> I have no comment on this but that its a matter of
> focus.
> 
>
--------------------------------------------------------------------------

Bart respondeed:
> 
> Yes it is... so we should focus on it :)
> I believe that dividing up he code per browser basis
> is the best solution.
> More browsers will come ( a beta of IE6 has already
> surfaced), and it would simplify things a  lot if
> you could add code for another browser without
> touching the current code. Otherwise you're stuck
> with making a fix for one browser, and then checking
> if it has broken in any other browser, and repeat.
> This will be implausible as the browser list grows
> (depending on how backwards compatible you want to
> be).
> 

Is it really better to have it diveded per browser?
This also means a lot of redundant code - which is
actually is moving away from OOM and the DynAPI
fundamental of cross-browser. See why I propose to
move casually on taking this step too hastily...?

> 
> > True, the SuperClass would have to be flawless and
> 
> > completely without bugs for this premise to work. 
> > But this is not impossible. I know, because I'm in
> the 
> > finishing stages of creating a comprehensive
> SuperClass 
> > myself (I might even create an opensource forum
> for it ;D )
> > SuperClass is, and should be, inherantly separate
> from 
> > DynAPI, and you could create whatever class
> hierarchy you 
> > would want with it, including DynAPI. 
> > 
> 
> See, this technique too has its flaws - its not all
> fortune and glory to restructure a project, it has
> to move slowly in a focused direction. In DynAPI's
> case I figure it's a anarchy of different minds
> dragging in different direction - hence it's as
> flexibel as it is. Actually I think the mix of
> control VS anarchy combined with at least a few
> determmand mind is what's in its sucess to gotten as
> far as it has.
> 
>
---------------------------------------------------------------------------------------------------------------
> 
> Yes, the DynAPI is amazing, Nodoubt about it. But I,
> as most, want to make it even better.
> What I'm getting more and more, is that it probably
> has to be split up. Which is not a bad thing
> nesseccarily. It could be a joint venture,
> preserving DynAPI's current object model and
> developing it further, and having another opensource
> forum with people trying to rebuild it, structuring
> it up in a more, strict, OOP way.
> 

Then develop it side by side till Next Gen is a
working model - ie established - then we'll see if
this or someone elses will be the way to move forward.
Are we finally on same grounds maybe? [open for
anybody to respond here]

Henrik Våglin [hv...@ya... ]

__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

RE: [Dynapi-Dev] ns6 w/h and browser advocacy

[Matthew A. S. <ms...@go...>]

I have to support the macintosh as well, though because I get very little
responses on this list I usually have to limit myself to the things that I
can get to work.  Not being able to get the content size has been a very
irritating problem for me.  Usually I end having to set sizes manually which
can cause things to look a little wierd on some of the browsers.

M.

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Michael
Burge
Sent: Tuesday, January 30, 2001 3:38 PM
To: dyn...@li...
Subject: Re: [Dynapi-Dev] ns6 w/h and browser advocacy


> From: Joachim Lundgren <lu...@ho...>
> Reply-To: dyn...@li...
> Date: Tue, 30 Jan 2001 15:15:59 +0100
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] ns6 w/h and browser advocacy

[...]

> But I got the right result by calling the function as the result of a
timeout:
> setTimeout("alert("+o+".elm.offsetWidth)", 0);


this is also true for IE5 on the Mac, but you have to wait a little longer.
I did some tests some time ago and there wasn't a safe time, in which the
values would get updated. So I implemented a function (no DynAPI) that
stores the old values and then checks every few ms if the values have been
updated and if so, it calls whatever you like.
This was the only solution I could come up with, I haven't ever found a clue
on how it could be done differently. ...

the drawback is of course that you can't use return values to directly do
more stuff with it, there has to be another function that does the things
you want to do after you know the size of the content.
if this mechanism would be implemented into the DynAPI, it would change the
way one has to deal with getContentWidth/getContentHeight (maybe using a
"onThe_moment_our_contentsize_values_are_finally_correct"-event or something
like that)

i really need this feature in IE5/Mac too, so if nobody comes up with a
better solution, I will definitely implement it that way.

--
Michael Buerge

BTW: i have the impression that there arent any Mac-developers here. the
examples in this and last weeks snapshots mostly didn't work on the Mac and
there wasn't one post regarding that...
...and what about the bug i posted (elm problem)? can somebody reproduce it?
can somebody help me figuring it out?



_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/lists/listinfo/dynapi-dev

RE: [Dynapi-Dev] I have wrote a tree widget ....

[Darin K. <dka...@ef...>]

 
Agreed, this new tree is wicked fast!

-----Original Message-----
From: Richard Bennett
To: dyn...@li...
Sent: 1/30/01 3:50 PM
Subject: Re: [Dynapi-Dev] I have wrote a tree widget ....

No Doug, I don't think a rebuff was in order here, firstly, any widget
is
welcome, be it better or worse than what exists, if it's no good, don't
use
it.
But apart from that, I gave the code a once over, and although it
doesn't
look very conventional, that might just be it's strength, as far as I
can
see, it uses minimal layers, building the tree in a table.
The small example loads very fast, so maybe this would be interesting
for
large trees, which don't need the added functionality of opening on a
node
through a value passed to them (like mine), but should load fast, I'll
test
it with a thousand nodes or so (the limit of my widget), my criteria was
less than 10 seconds rendering time after 10 reloads on IE (on my pc).
And it also has the dotted lines, way cool!

Cheers,
Richard Bennett

ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of
DynAPI2)

----- Original Message -----
From: "Doug Melvin" <do...@cr...>
To: <dyn...@li...>
Sent: Wednesday, January 31, 2001 12:14 AM
Subject: Re: [Dynapi-Dev] I have wrote a tree widget ....


> what's wrong with the tree we have?
> see www.richardinfo.com
> ----- Original Message -----
> From: "J. Fernando Moyano" <tx...@wa...>
> To: <dyn...@li...>
> Cc: <dyn...@li...>
> Sent: Tuesday, January 30, 2001 11:16 AM
> Subject: [Dynapi-Dev] I have wrote a tree widget ....
>
>
> >
> > I have wrote a tree widget for DynAPI2 ...
> > It's very simple and it has some "dirty" feature (you mut pass the
> variable
> > name as parameter ... but i don't know very well the DynAPI. Someone
can
> fixit
> > in 5 minutes ???)
> >
> > I send a tgz file with the tree.js file (in dynapi/gui), the
> > necesary bitmaps (in dynapi/images/tree) and a working example.
> >
> > I'm using it in my project mainpage (http://wdbil.sourceforge.net)
> >
> > Bye,
> >
> > txino
> >
> > --
> >
> > "It is not the strongest of the species that survive, nor the most
> > intelligent,but the one most responsive to change."
> >
> >                                                         John McFee
> >
> > (*) SymeX ==> http://symex.lantik.com
> > (*) WDBIL ==> http://wdbil.sourceforge.net
> > (*) Informate sobre LINUX en http://www.linux.org
> >
>
>
> _______________________________________________
> 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
>


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/lists/listinfo/dynapi-dev

[Dynapi-Dev] [Patch #103520] List.js setSelected Patch

[<no...@so...>]

Patch #103520 has been updated. 

Project: dynapi
Category: DynAPI-Widget
Status: Open
Submitted by: rainwater
Assigned to : nobody
Summary: List.js setSelected Patch

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=103520&group_id=5757

[Dynapi-Dev] [Bug #130357] small typo in list.js

[<no...@so...>]

Bug #130357, was updated on 2001-Jan-28 14:27
Here is a current snapshot of the bug.

Project: DynAPI 2
Category: Core - Widgets
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: marstr
Assigned to : rainwater
Summary: small typo in list.js

Details: there's a small typo (i think) in list.js line 76

if (this.selected=b) {

should be

if (this.selected==b) {

right?


Follow-Ups:

Date: 2001-Jan-30 15:55
By: rainwater

Comment:
See patch at
http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103520&group_id=5757

-------------------------------------------------------

Date: 2001-Jan-28 17:50
By: rainwater

Comment:
Doh!  Its been updated in CVS.  Closing this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130357&group_id=5757

Re: [Dynapi-Dev] I have wrote a tree widget ....

[Richard B. <ma...@ri...>]

No Doug, I don't think a rebuff was in order here, firstly, any widget is
welcome, be it better or worse than what exists, if it's no good, don't use
it.
But apart from that, I gave the code a once over, and although it doesn't
look very conventional, that might just be it's strength, as far as I can
see, it uses minimal layers, building the tree in a table.
The small example loads very fast, so maybe this would be interesting for
large trees, which don't need the added functionality of opening on a node
through a value passed to them (like mine), but should load fast, I'll test
it with a thousand nodes or so (the limit of my widget), my criteria was
less than 10 seconds rendering time after 10 reloads on IE (on my pc).
And it also has the dotted lines, way cool!

Cheers,
Richard Bennett

ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)

----- Original Message -----
From: "Doug Melvin" <do...@cr...>
To: <dyn...@li...>
Sent: Wednesday, January 31, 2001 12:14 AM
Subject: Re: [Dynapi-Dev] I have wrote a tree widget ....


> what's wrong with the tree we have?
> see www.richardinfo.com
> ----- Original Message -----
> From: "J. Fernando Moyano" <tx...@wa...>
> To: <dyn...@li...>
> Cc: <dyn...@li...>
> Sent: Tuesday, January 30, 2001 11:16 AM
> Subject: [Dynapi-Dev] I have wrote a tree widget ....
>
>
> >
> > I have wrote a tree widget for DynAPI2 ...
> > It's very simple and it has some "dirty" feature (you mut pass the
> variable
> > name as parameter ... but i don't know very well the DynAPI. Someone can
> fixit
> > in 5 minutes ???)
> >
> > I send a tgz file with the tree.js file (in dynapi/gui), the
> > necesary bitmaps (in dynapi/images/tree) and a working example.
> >
> > I'm using it in my project mainpage (http://wdbil.sourceforge.net)
> >
> > Bye,
> >
> > txino
> >
> > --
> >
> > "It is not the strongest of the species that survive, nor the most
> > intelligent,but the one most responsive to change."
> >
> >                                                         John McFee
> >
> > (*) SymeX ==> http://symex.lantik.com
> > (*) WDBIL ==> http://wdbil.sourceforge.net
> > (*) Informate sobre LINUX en http://www.linux.org
> >
>
>
> _______________________________________________
> 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
>

RE: [Dynapi-Dev] Screen shots of Internet Explorer 6 if anyone is interested

[Darin K. <dka...@ef...>]

correct link is

http://www.the-ctrl-alt-del.com/2001/Daily_news/January/28/ie6.htm

-----Original Message-----
From: Raymond Smith [mailto:dst...@or...]
Sent: Tuesday, January 30, 2001 1:49 PM
To: dyn...@li...
Subject: [Dynapi-Dev] Screen shots of Internet Explorer 6 if anyone is
interested


http://www.the-ctrl-alt-del.com/2001/Dail

Looks like Real Media is next in line.  Full intergration of Media Player
into browser

Cheers

Ray


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Re: [Dynapi-Dev] ns6 w/h and browser advocacy

[Michael Br. <mb...@st...>]

> From: Joachim Lundgren <lu...@ho...>
> Reply-To: dyn...@li...
> Date: Tue, 30 Jan 2001 15:15:59 +0100
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] ns6 w/h and browser advocacy

[...]

> But I got the right result by calling the function as the result of a timeout:
> setTimeout("alert("+o+".elm.offsetWidth)", 0);


this is also true for IE5 on the Mac, but you have to wait a little longer.
I did some tests some time ago and there wasn't a safe time, in which the
values would get updated. So I implemented a function (no DynAPI) that
stores the old values and then checks every few ms if the values have been
updated and if so, it calls whatever you like.
This was the only solution I could come up with, I haven't ever found a clue
on how it could be done differently. ...

the drawback is of course that you can't use return values to directly do
more stuff with it, there has to be another function that does the things
you want to do after you know the size of the content.
if this mechanism would be implemented into the DynAPI, it would change the
way one has to deal with getContentWidth/getContentHeight (maybe using a
"onThe_moment_our_contentsize_values_are_finally_correct"-event or something
like that)

i really need this feature in IE5/Mac too, so if nobody comes up with a
better solution, I will definitely implement it that way.

--
Michael Buerge

BTW: i have the impression that there arent any Mac-developers here. the
examples in this and last weeks snapshots mostly didn't work on the Mac and
there wasn't one post regarding that...
...and what about the bug i posted (elm problem)? can somebody reproduce it?
can somebody help me figuring it out?

RE: [Dynapi-Dev] Screen shots of Internet Explorer 6 if anyone is interested

[Brendon D. <bda...@ma...>]

That link is dead

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Raymond
Smith
Sent: Tuesday, January 30, 2001 3:49 PM
To: dyn...@li...
Subject: [Dynapi-Dev] Screen shots of Internet Explorer 6 if anyone is
interested


http://www.the-ctrl-alt-del.com/2001/Dail

Looks like Real Media is next in line.  Full intergration of Media Player
into browser

Cheers

Ray


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/lists/listinfo/dynapi-dev

[Dynapi-Dev] Screen shots of Internet Explorer 6 if anyone is interested

[Raymond S. <dst...@or...>]

http://www.the-ctrl-alt-del.com/2001/Dail

Looks like Real Media is next in line.  Full intergration of Media Player
into browser

Cheers

Ray

Re: [Dynapi-Dev] Counting so far

[Cameron H. <ca...@bi...>]

I think Richard tested them.

Fair enough though if you're not sure about them. Perhaps if there are 
to be people moderating additions to the CVS you should assign a browser 
to each moderator (or are you the only moderator Robert?). If someone 
(or more than one person) is experience with NS6 or Mac IE5 then they 
should check and okay any changes.

The only testing I've done is with the DynAPI examples, and with the 
site I'm working on. It's better to test with something complicated I 
think, as it tends to show up faults in the code, the examples are a bit 
too simple for this. Widgets are good for highlighting problems I've found.

Some of the developers must know a bit about NS6 though as there is a 
lot of support in the API already, although some of it is a bit out of 
date (for example, NS6 final supports innerHTML).

Robert Rainwater wrote:

> 
>> I'm a bit curious on that front. I've submitted some patches for NS6, anyone
>> on the developers must know about them, I've dropped hints about them being
>> put into CVS numerous times. They never have been put into CVS, and I've
>> never received any explanation why not. Fair enough if my fixes aren't good
>> enough, if that's why they aren't going in tell me, perhaps I can improve
>> them. But it is frustrating not knowing, and it's not a great incentive to
>> carry on trying to contribute.
> 
> 
> I have no problem including many of the NS 6 patches.  However, I'm
> not very experienced in NS 6, so I hesitate to make any changes.
> Especially since its hard to tell of others have tested the patches
> themselves.
> 
> Maybe we just need a better process for patch submission.  But unless
> others in the group are actively testing the patches, then I don't
> want to make changes, especially NS 6 or Mac patches.

SV: [Dynapi-Dev] Next Generation 9

[Bart B. <ba...@ho...>]

-----Ursprungligt meddelande-----
Fr=E5n: Henrik V=E5glin <hv...@ya...>
Till: dyn...@li... =
<dyn...@li...>
Datum: den 30 januari 2001 20:39
=C4mne: Re: [Dynapi-Dev] Next Generation 9



----- Original Message -----=20
From: "Barre Bizon" <ba...@ho...>
To: <dyn...@li...>
Sent: Tuesday, January 30, 2001 5:35 PM
Subject: [Dynapi-Dev] Next Generation 9


>=20
> Hey...
>=20
> I think most of you seem to be missing the point somewhat.=20
> Let me explain:
>=20
> There are certain reasons why languages such as Java and=20
> other OO languages have evolved. Stability,=20
> reusabilty/modularity, ease of use, security etc. Object=20
> Orientation exists because people wanted a way to easier=20
> abstract problems, and represent them in a more human-like=20
> fashion.
> Now what DynLayer tries to do is simulate parts of this=20
> whilst providing funcionality for robust, consistant and=20
> simple dHtml creation.
>=20

There's reason why SCRIPTING languages like Javascript have evolved too =
- ease of use and implementation! From another point of view - for =
example a designers - it is as much or more valuble.

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

True. Don't get me wrong. I love scripting in Javascript, loose typing =
and all that jazz.=20
But this is not my point. I'm talking about implementing consepts that =
are not hard to use, but eliminate a lot of potentially "bad" code.
Scripting languages are easy to work with, yes, but when projects evolve =
into the level of complexity that DynAPI has, it actually becomes a =
drawback in certain cases. I'm sure you have spent more than one =
occasion wasting hours on end trying to find that little but oh so =
annoying bug ;) Now I'm not saying this will happen automagically just =
because you stick to Javascript's own inheritance scheme. You might be a =
superprogrammer that never makes any errors :) But since not all of us =
are, it is vital to have a good foundation for programming with.
And as great as JS is, I believe it can be improved upon.


> But how can you create a complex API such as DynAPI without=20
> having some fundamentals already in place? Such as a fast,=20
> stable, easy and safe way of creating a class=20
> hierarchy/implementing basic OOP functionality.
> I mean, how long has this "current" release been in a=20
> debugging phase ??! Do you not think that this could have=20
> been avoided, atleast in part, by having a more stable=20
> coding ground to develop with?
>=20

The fundamentals was built on  dan steinman's DynAPI 1 build - that's =
probably what kept the development of DynAPI 2 together through its =
establishing phase. There are fundamentals in the DynAPI 2 as it is, =
even if they're everchanging and more losely bound in the collaborated =
understanding of the developers interacting on its development.


----------------------------------------------------------------

Yes, but this is not the foundation I'm talking about. Granted that =
DynAPI is great, and has a lot of functionality that greatly simplifies =
and adds to dHtml creation. But the more you add to it, the more complex =
(and often slower) it gets. This, however, would be minimized if the =
stomping ground would be stable. Yes, proper OOP gives you heavier shoes =
to wear, but the shoes are there for a reason; to protect you from the =
cold, right? You wouldn't climb a mountain (read:.DynAPI) ,  without =
proper shoes (read:OOP), now would you?  =20



> True, Javascript's prototype based OO provide some=20
> functionality for creating "classes". But this approach is=20
> inherantly slow, memory consuming and error prone, since=20
> some of the most fundamental OOP functionality is not=20
> supported (such as true encapsulation).
> Why go halfway, sort of do OOP, but not really, because=20
> it's too hard ? It's not! In the long run it's much=20
> simpler. Which is the exact point of DynAPI in the first=20
> place. There is a longer learning curve before you can use=20
> it, but when you do, your efforts are greatly simplified=20
> and accellerated.
>=20

You're comparing apples with oranges. Prototyping is just another flavor =
of a OO-based technique - reread your OO system analysis book and you =
will see it fits, no matter what you're programming gurus tell you.


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

I'm not saying that Javascript is not object oriented. It's just that =
it's lacking.


> What you would want, is to have somekind of Object=20
> providing the remaining OOP functionality that Javascript=20
> does not inherantly support, so that you don't have to=20
> recreate the wheel everytime you develop somekind of=20
> application or extension to it.
> Pascals DynObject and Eytans SuperObject, are examples of=20
> what I'm talking about.
> DynObject provides better modularity for DynAPI, and a=20
> SuperObject would provide the tools with which to better=20
> build a more modular DynAPI (there are a couple of more=20
> people that have developed a SuperObject/SuperClass).
>=20

They are great ideas and soloutions for sure (I actually admire those =
who can realise these), but is it the only way to go? Is it the only =
thing desirable? is it waht everyone desires? You're of course free to =
convience anyone, but don't think you know the one and only best =
soloution - cause there are none that works for everyone...


-------------------------------------------------------------------

Correct, this is not the only way to go. I believe that it is a very =
sound way to go. But this is only my opinion obviously.


> Yes, you could argue that this would only lead to more=20
> bugs, and that you should rely on JavaScript's built-in way=20
> of handling OOP, and that this should be a API for=20
> designers, not for programmers and what have you...
> But this is simply not true.=20
>=20

From a oneway developer view maybe (no offence meant)

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

Yes this is obviously my opinion. If  I still am sane enough to know =
that I'm only one person ( I don't think I'm schizofrenic yet...... ) ;)
But your'e missing my point and getting hung up on semantics.=20

=20

> 1. DynAPI is a programming tool/interface for creating=20
> dHtml.
> Now programming is the key word here. No matter what, you=20
> still have to PROGRAM. If you would want to create a=20
> simpler interface for creating dHtml (a WYSIWYG for=20
> instance), there still has to be someone who creates this=20
> interface, and I guarantee you, it won't be a designer! ;)
>=20

I challenge you there, cause I've already begun to build a DynBuilder =
for WYSIWYG DynAPI development. Andd it's not wheter to do programming =
or not I'm discussing - it's the level of advanced programming that I =
simple think something called an API is meant to avoid (its in the name =
for christs sake!!! ;)

----------------------------------------------

Challenge me on what, have you not programmed when doing DynBuilder?
Are you a designer, not a programmer? What are you saying?
I'm using the term programmer and designer strictly. But obviously a =
designer can be a programmer and vice versa.
The concepts I'm proposing wouldn't change the end programmers =
utilization of the API. At all.
It would even simplify, second level developers (i.e. people not =
developing the actual core, but doing widgets and that sort of thing)

> 2. Having a SuperClass that provides basic OOP=20
> functionality, would provide the PROGRAMMER with the tools=20
> nessessary to create DynAPI with a lot more ease=20
> (again,this is the goal of OOP).=20

Sure, but then agaian I'm not voting against this development - I just =
propose to not move the current DynAPI in that direction, but rather to =
split up the builds of Next Gen and the current DynAPI, which - again to =
be clear - is an API. API means Application Programming Interface - not =
Advanced Programming Interpretor.


----------------------------------------------

Right, I'm not saying this functionality should be inherent in DynAPI. =
It should be external and you should be able to use it for creating =
whatever you would want... I foresee that DynAPI will probably be split =
up sooner or later. There probably are a lot of you already modifying it =
for own purposes.


> For example, say that you would want to split up DynAPI per=20
> browser basis and make this seamless for the end=20
> programmer. If you would not have fundamental OOP=20
> functionality in place, this would be HARD! =20
>=20

I have no comment on this but that its a matter of focus.

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

Yes it is... so we should focus on it :)
I believe that dividing up he code per browser basis is the best =
solution.
More browsers will come ( a beta of IE6 has already surfaced), and it =
would simplify things a  lot if you could add code for another browser =
without touching the current code. Otherwise you're stuck with making a =
fix for one browser, and then checking if it has broken in any other =
browser, and repeat. This will be implausible as the browser list grows =
(depending on how backwards compatible you want to be).


> True, the SuperClass would have to be flawless and=20
> completely without bugs for this premise to work.=20
> But this is not impossible. I know, because I'm in the=20
> finishing stages of creating a comprehensive SuperClass=20
> myself (I might even create an opensource forum for it ;D )
> SuperClass is, and should be, inherantly separate from=20
> DynAPI, and you could create whatever class hierarchy you=20
> would want with it, including DynAPI.=20
>=20

See, this technique too has its flaws - its not all fortune and glory to =
restructure a project, it has to move slowly in a focused direction. In =
DynAPI's case I figure it's a anarchy of different minds dragging in =
different direction - hence it's as flexibel as it is. Actually I think =
the mix of control VS anarchy combined with at least a few determmand =
mind is what's in its sucess to gotten as far as it has.

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

Yes, the DynAPI is amazing, Nodoubt about it. But I, as most, want to =
make it even better.
What I'm getting more and more, is that it probably has to be split up. =
Which is not a bad thing nesseccarily. It could be a joint venture, =
preserving DynAPI's current object model and developing it further, and =
having another opensource forum with people trying to rebuild it, =
structuring it up in a more, strict, OOP way.

SV: [Dynapi-Dev] Error in Netscape 4

[Bart B. <ba...@ho...>]

Well, from what I know Netscape 4.01 - 4.05 support Javascript 1.2,
4.05+ support 1.3...
And Javascript 1.2 has many "features" not found in later versions. Nor =
prior.
For instance, type conversion is turned off, i.e.
("345"=3D=3D345 ) would be false. In Javascript 1.3 and 1.1 this would =
be true.
(to achieve the same effect in Javascript 1.3 you would do  =
("345"=3D=3D=3D345 ), where =3D=3D=3D is equality without =
typeconversion.)=20
Also there are some differences where returning values are concerned. =
And this is without mentioning all the bugs that exist ;)
    -----Ursprungligt meddelande-----
    Fr=E5n: Pascal Bestebroer <pa...@dy...>
    Till: dyn...@li... =
<dyn...@li...>
    Datum: den 30 januari 2001 19:23
    =C4mne: RE: [Dynapi-Dev] Error in Netscape 4
   =20
   =20
    yep, NS4.04 sucks with code.
    =20
    The browser has some serious problems handling alot of basic =
javascript things.  I guess I'll have to add a note about non NS4.04  =
compatiblity to the f.a.q.
   =20
    There will probably be more problems even when adding the return =
lines to the functions.
    Pascal Bestebroer
    pa...@dy...
    http://www.dynamic-core.net=20

        -----Oorspronkelijk bericht-----
        Van: dyn...@li... =
[mailto:dyn...@li...]Namens Leon Reinders
        Verzonden: dinsdag 30 januari 2001 19:13
        Aan: dyn...@li...
        Onderwerp: [Dynapi-Dev] Error in Netscape 4
       =20
       =20
        Recently i've been testing Dynapi on my computer and have =
noticed that i get errorrs in netscape 4.04 using  mouseevents. (Even in =
the latest versions of Dynapi.)
        I found that placing a default return-false in a subroutine =
would easily fix this.
        Could anybody comfirm my findings?
       =20
        Thanks.

Re[2]: [Dynapi-Dev] Counting so far

[Robert R. <rra...@ya...>]

> I'm a bit curious on that front. I've submitted some patches for NS6, anyone
> on the developers must know about them, I've dropped hints about them being
> put into CVS numerous times. They never have been put into CVS, and I've
> never received any explanation why not. Fair enough if my fixes aren't good
> enough, if that's why they aren't going in tell me, perhaps I can improve
> them. But it is frustrating not knowing, and it's not a great incentive to
> carry on trying to contribute.

I have no problem including many of the NS 6 patches.  However, I'm
not very experienced in NS 6, so I hesitate to make any changes.
Especially since its hard to tell of others have tested the patches
themselves.

Maybe we just need a better process for patch submission.  But unless
others in the group are actively testing the patches, then I don't
want to make changes, especially NS 6 or Mac patches.
-- 
// Robert Rainwater
----------------------
DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
DynAPI Homepage: http://dynapi.sourceforge.net/

RE: [Dynapi-Dev] Counting so far

[Pascal B. <pa...@dy...>]

I haven't touched the DynAPI code for the last couple of months (only one or
two small things done) Robert has been implement bug-fixes alot and I guess
some of those he never got around to.

Patches on sourceforge will be looked at, as long as there not closed there
not checked out...

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Cameron Hart
> Verzonden: dinsdag 30 januari 2001 19:51
> Aan: dyn...@li...
> Onderwerp: RE: [Dynapi-Dev] Counting so far
>
>
> > * Group moderation, this is what Dann Pascal and Robert do
> (among others)
> > and is basically taking the decisions.
> > Someone has to do that, otherwise everybody would be overwriting
> > each others
> > code in CVS 'cause they didn't like the "style".
> > There are a few things that could be improved here to, as I
> feel a lot of
> > knowledge gets lost as it's simply ignored, but it should come from two
> > sides, submitters should be able to accept at face value that
> > their "great"
> > fix, wasn't accepted, but the moderator should at least
> acknowledge having
> > seen the submission, if not giving a reason for every line of code they
> > reject/accept.
>
> I'm a bit curious on that front. I've submitted some patches for
> NS6, anyone
> on the developers must know about them, I've dropped hints about
> them being
> put into CVS numerous times. They never have been put into CVS, and I've
> never received any explanation why not. Fair enough if my fixes
> aren't good
> enough, if that's why they aren't going in tell me, perhaps I can improve
> them. But it is frustrating not knowing, and it's not a great incentive to
> carry on trying to contribute.
>
> I'm sure this goes for anyone who's trying to help out, if your help is
> completely ignored then you stop helping. mind you if your efforts are
> completely shot down, perhaps you stop helping too. so be nice
> when you tell
> people they their code is shite ;-)
>
> cameron.
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] I have wrote a tree widget ....

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

what's wrong with the tree we have?
see www.richardinfo.com
----- Original Message -----
From: "J. Fernando Moyano" <tx...@wa...>
To: <dyn...@li...>
Cc: <dyn...@li...>
Sent: Tuesday, January 30, 2001 11:16 AM
Subject: [Dynapi-Dev] I have wrote a tree widget ....


>
> I have wrote a tree widget for DynAPI2 ...
> It's very simple and it has some "dirty" feature (you mut pass the
variable
> name as parameter ... but i don't know very well the DynAPI. Someone can
fixit
> in 5 minutes ???)
>
> I send a tgz file with the tree.js file (in dynapi/gui), the
> necesary bitmaps (in dynapi/images/tree) and a working example.
>
> I'm using it in my project mainpage (http://wdbil.sourceforge.net)
>
> Bye,
>
> txino
>
> --
>
> "It is not the strongest of the species that survive, nor the most
> intelligent,but the one most responsive to change."
>
>                                                         John McFee
>
> (*) SymeX ==> http://symex.lantik.com
> (*) WDBIL ==> http://wdbil.sourceforge.net
> (*) Informate sobre LINUX en http://www.linux.org
>

Re: [Dynapi-Dev] Next Generation 9

[<hv...@ya...>]

----- Original Message -----=20
From: "Barre Bizon" <ba...@ho...>
To: <dyn...@li...>
Sent: Tuesday, January 30, 2001 5:35 PM
Subject: [Dynapi-Dev] Next Generation 9


>=20
> Hey...
>=20
> I think most of you seem to be missing the point somewhat.=20
> Let me explain:
>=20
> There are certain reasons why languages such as Java and=20
> other OO languages have evolved. Stability,=20
> reusabilty/modularity, ease of use, security etc. Object=20
> Orientation exists because people wanted a way to easier=20
> abstract problems, and represent them in a more human-like=20
> fashion.
> Now what DynLayer tries to do is simulate parts of this=20
> whilst providing funcionality for robust, consistant and=20
> simple dHtml creation.
>=20

There's reason why SCRIPTING languages like Javascript have evolved too =
- ease of use and implementation! From another point of view - for =
example a designers - it is as much or more valuble.

> But how can you create a complex API such as DynAPI without=20
> having some fundamentals already in place? Such as a fast,=20
> stable, easy and safe way of creating a class=20
> hierarchy/implementing basic OOP functionality.
> I mean, how long has this "current" release been in a=20
> debugging phase ??! Do you not think that this could have=20
> been avoided, atleast in part, by having a more stable=20
> coding ground to develop with?
>=20

The fundamentals was built on  dan steinman's DynAPI 1 build - that's =
probably what kept the development of DynAPI 2 together through its =
establishing phase. There are fundamentals in the DynAPI 2 as it is, =
even if they're everchanging and more losely bound in the collaborated =
understanding of the developers interacting on its development.

> True, Javascript's prototype based OO provide some=20
> functionality for creating "classes". But this approach is=20
> inherantly slow, memory consuming and error prone, since=20
> some of the most fundamental OOP functionality is not=20
> supported (such as true encapsulation).
> Why go halfway, sort of do OOP, but not really, because=20
> it's too hard ? It's not! In the long run it's much=20
> simpler. Which is the exact point of DynAPI in the first=20
> place. There is a longer learning curve before you can use=20
> it, but when you do, your efforts are greatly simplified=20
> and accellerated.
>=20

You're comparing apples with oranges. Prototyping is just another flavor =
of a OO-based technique - reread your OO system analysis book and you =
will see it fits, no matter what you're programming gurus tell you.

> What you would want, is to have somekind of Object=20
> providing the remaining OOP functionality that Javascript=20
> does not inherantly support, so that you don't have to=20
> recreate the wheel everytime you develop somekind of=20
> application or extension to it.
> Pascals DynObject and Eytans SuperObject, are examples of=20
> what I'm talking about.
> DynObject provides better modularity for DynAPI, and a=20
> SuperObject would provide the tools with which to better=20
> build a more modular DynAPI (there are a couple of more=20
> people that have developed a SuperObject/SuperClass).
>=20

They are great ideas and soloutions for sure (I actually admire those =
who can realise these), but is it the only way to go? Is it the only =
thing desirable? is it waht everyone desires? You're of course free to =
convience anyone, but don't think you know the one and only best =
soloution - cause there are none that works for everyone...

> Yes, you could argue that this would only lead to more=20
> bugs, and that you should rely on JavaScript's built-in way=20
> of handling OOP, and that this should be a API for=20
> designers, not for programmers and what have you...
> But this is simply not true.=20
>=20

From a oneway developer view maybe (no offence meant)

> 1. DynAPI is a programming tool/interface for creating=20
> dHtml.
> Now programming is the key word here. No matter what, you=20
> still have to PROGRAM. If you would want to create a=20
> simpler interface for creating dHtml (a WYSIWYG for=20
> instance), there still has to be someone who creates this=20
> interface, and I guarantee you, it won't be a designer! ;)
>=20

I challenge you there, cause I've already begun to build a DynBuilder =
for WYSIWYG DynAPI development. Andd it's not wheter to do programming =
or not I'm discussing - it's the level of advanced programming that I =
simple think something called an API is meant to avoid (its in the name =
for christs sake!!! ;)

> 2. Having a SuperClass that provides basic OOP=20
> functionality, would provide the PROGRAMMER with the tools=20
> nessessary to create DynAPI with a lot more ease=20
> (again,this is the goal of OOP).=20

Sure, but then agaian I'm not voting against this development - I just =
propose to not move the current DynAPI in that direction, but rather to =
split up the builds of Next Gen and the current DynAPI, which - again to =
be clear - is an API. API means Application Programming Interface - not =
Advanced Programming Interpretor.

> For example, say that you would want to split up DynAPI per=20
> browser basis and make this seamless for the end=20
> programmer. If you would not have fundamental OOP=20
> functionality in place, this would be HARD! =20
>=20

I have no comment on this but that its a matter of focus.

> True, the SuperClass would have to be flawless and=20
> completely without bugs for this premise to work.=20
> But this is not impossible. I know, because I'm in the=20
> finishing stages of creating a comprehensive SuperClass=20
> myself (I might even create an opensource forum for it ;D )
> SuperClass is, and should be, inherantly separate from=20
> DynAPI, and you could create whatever class hierarchy you=20
> would want with it, including DynAPI.=20
>=20

See, this technique too has its flaws - its not all fortune and glory to =
restructure a project, it has to move slowly in a focused direction. In =
DynAPI's case I figure it's a anarchy of different minds dragging in =
different direction - hence it's as flexibel as it is. Actually I think =
the mix of control VS anarchy combined with at least a few determmand =
mind is what's in its sucess to gotten as far as it has.

> In closing, I do hope that what I've said will infact sink=20
> in, and not just be flamed ;)
>=20

Sink in as convinece - no - but I respect your oppossed point of view. I =
think though that way too many reason like you, and that's why projects =
go down, because people always figure new beginnings are the one method =
to improve (I've got a lot of experience of this in totally different =
kinds of projects). DynAPI is well established with a lot of developers =
as is, not to mention the user-base. A total remake will turn all that =
on end an there's nothing that can make certain how that will turn out.=20

(BTW if you flame me, I give my self the right to return the same, but I =
will keep within the line as long as you too keep it down to issue.)

> Alea Jacta Est,=20
> Bart
>=20
> PS. I apoligize if this mail is doubled, my mail client=20
> seems to have flaked out on me DS
>

Luckily it came through only once ;) - nah, I'm only teasing you, it was =
pretty well reasoned at least...


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Dynapi-Dev] I have wrote a tree widget ....

[J. F. M. <tx...@wa...>]

I have wrote a tree widget for DynAPI2 ...
It's very simple and it has some "dirty" feature (you mut pass the variable
name as parameter ... but i don't know very well the DynAPI. Someone can fixit
in 5 minutes ???)

I send a tgz file with the tree.js file (in dynapi/gui), the
necesary bitmaps (in dynapi/images/tree) and a working example.

I'm using it in my project mainpage (http://wdbil.sourceforge.net)

Bye,

txino

-- 

"It is not the strongest of the species that survive, nor the most
intelligent,but the one most responsive to change."

                                                        John McFee 

(*) SymeX ==> http://symex.lantik.com 
(*) WDBIL ==> http://wdbil.sourceforge.net
(*) Informate sobre LINUX en http://www.linux.org

RE: [Dynapi-Dev] Counting so far

[Cameron H. <ca...@bi...>]

> * Group moderation, this is what Dann Pascal and Robert do (among others)
> and is basically taking the decisions.
> Someone has to do that, otherwise everybody would be overwriting
> each others
> code in CVS 'cause they didn't like the "style".
> There are a few things that could be improved here to, as I feel a lot of
> knowledge gets lost as it's simply ignored, but it should come from two
> sides, submitters should be able to accept at face value that
> their "great"
> fix, wasn't accepted, but the moderator should at least acknowledge having
> seen the submission, if not giving a reason for every line of code they
> reject/accept.

I'm a bit curious on that front. I've submitted some patches for NS6, anyone
on the developers must know about them, I've dropped hints about them being
put into CVS numerous times. They never have been put into CVS, and I've
never received any explanation why not. Fair enough if my fixes aren't good
enough, if that's why they aren't going in tell me, perhaps I can improve
them. But it is frustrating not knowing, and it's not a great incentive to
carry on trying to contribute.

I'm sure this goes for anyone who's trying to help out, if your help is
completely ignored then you stop helping. mind you if your efforts are
completely shot down, perhaps you stop helping too. so be nice when you tell
people they their code is shite ;-)

cameron.

RE: [Dynapi-Dev] Error in Netscape 4

[Pascal B. <pa...@dy...>]

yep, NS4.04 sucks with code.

The browser has some serious problems handling alot of basic javascript
things.  I guess I'll have to add a note about non NS4.04  compatiblity to
the f.a.q.

There will probably be more problems even when adding the return lines to
the functions.
Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

  -----Oorspronkelijk bericht-----
  Van: dyn...@li...
[mailto:dyn...@li...]Namens Leon Reinders
  Verzonden: dinsdag 30 januari 2001 19:13
  Aan: dyn...@li...
  Onderwerp: [Dynapi-Dev] Error in Netscape 4


  Recently i've been testing Dynapi on my computer and have noticed that i
get errorrs in netscape 4.04 using  mouseevents. (Even in the latest
versions of Dynapi.)
  I found that placing a default return-false in a subroutine would easily
fix this.
  Could anybody comfirm my findings?

  Thanks.

Stats (WAS Re: [Dynapi-Dev] Next Generation)

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

Not a bad idea.
I will look into such an association for www.AllTheWhile.com
(my other company)
I'll let y'all know how that goes..

Doug

----- Original Message -----
From: "Michael Ellis" <Mic...@il...>
To: <dyn...@li...>
Sent: Tuesday, January 30, 2001 9:20 AM
Subject: RE: [Dynapi-Dev] Next Generation


> Just to further clarify... Doug and Raymond's statement are correct. The
> www.statmarket.com is much broader based... they collect the stats from
> anyone using 'HitBox'. There daily sample is supposed to be based on
around
> 50,000,000 hits. Unfortunately the free report uses old sample data, and
the
> subscriptions/custom demographic reports aren't cheap (about $950/report,
I
> don't even know what they charge for a full subscription).
>
> This is a list of the browsers/platforms that most of our domestic
customers
> need supported (this may differ for your clients needs. Please feel free
to
> flame me on this, I don't pretend to have the answers... just a starting
> point):
>
> Windows:
>
> IE 4.1 (SP1)
> IE 5.0
> IE 5.5
>
> NS 4.08
> NS 4.76
> NS 6.0
>
> Mac:
>
> IE 5.0 (Ugly, I know)
> NS 4.08
> NS 6.0
>
> Maybe it would make sense for someone in charge of the site to see about a
> ASP/strategic alliance (link) with an organization that provides good
> statistics. It would certianly help educate us, and lend an air of
> credability to our cross platform/cross browser code premise. Then again,
> setting up these relationships is usually a pain in the ass.
>
> Mike
>
>
> -----Original Message-----
> From: Doug Melvin [mailto:do...@cr...]
> Sent: Tuesday, January 30, 2001 11:23
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] Next Generation
>
>
> that's not 'in the world'
> All stats on that site are from visiter to that site, and
> represent ONLY visiters to that site.
> Not the world.
>
> ----- Original Message -----
> From: "Cameron Hart" <ca...@bi...>
> To: <dyn...@li...>
> Sent: Tuesday, January 30, 2001 1:59 AM
> Subject: RE: [Dynapi-Dev] Next Generation
>
>
> > It is quite frightening to know that 5 people in the world are using
MSIE
> > 1.x ;-)
> >
> > I mean, has anyone even seen IE 1???
> >
> > > -----Original Message-----
> > > From: dyn...@li...
> > > [mailto:dyn...@li...]On Behalf Of Raymond
> > > Smith
> > > Sent: 30 January 2001 05:50
> > > To: dyn...@li...
> > > Subject: Re: [Dynapi-Dev] Next Generation
> > >
> > >
> > > Carefull if your using the "sample stats" from there.  They date back
to
> > > 1999 and reflect an older reality.  Most recent browser stats I have
> found
> > > are at www.thecounter.com.  From October 2000.
> > >
> > > ----- Original Message -----
> > > From: "Michael Ellis" <Mic...@il...>
> > > To: <dyn...@li...>
> > > Sent: Monday, January 29, 2001 2:53 PM
> > > Subject: RE: [Dynapi-Dev] Next Generation
> > >
> > >
> > > > Amen brother!
> > > >
> > > > No argument here... Although we can be educated to, we cannot expect
> nor
> > > > demand which platform/browser our end-users choose. If our
> > > software is to
> > > be
> > > > taken seriously, and serve a broad community we must be reasonable
> about
> > > > which platforms/browsers we support. If you think I'm full of it,
> check
> > > the
> > > > browser/platform statistics at www.statmarket.com (don't rely on
> > > statistics
> > > > gathered by developer forums, they attract developers like us and
are
> > > > typically not representative of our products end-users).
> > > >
> > > > Mike Ellis
> > > >
> > > > -----Original Message-----
> > > > From: .:: OCB ::. [mailto:oc...@ho...]
> > > > Sent: Monday, January 29, 2001 10:15
> > > > To: dyn...@li...
> > > > Subject: Re: [Dynapi-Dev] Next Generation
> > > >
> > > >
> > > > Next generation ???
> > > >
> > > > Would it not be a good idea to get the DynApi2 working in all
browsers
> > > > (basic methods, moveTo, event handlers etc; not wigits, IMO they
take
> a
> > > > backseat to basic functionality) before even discussing another
> > > generation
> > > > of the API.
> > > >
> > > > I haven't contributed anything in months (which is beyond my
control)
> so
> > > > feel quite apprehensive about posting this but again, IMO, it
> > > makes common
> > > > sense to get the basic's of this project crossbrowser (NN6 included)
> and
> > > bug
> > > >
> > > > free before launching into another generation of the API.
> > > >
> > > > Flame away !!!!
> > > >
> > > >
> > > > >From: "Jared Nuzzolillo" <ja...@aa...>
> > > > >Reply-To: dyn...@li...
> > > > >To: <dyn...@li...>
> > > > >Subject: [Dynapi-Dev] Next Generation
> > > > >Date: Mon, 29 Jan 2001 11:46:41 -0500
> > > > >
> > > > >I have a feeling that certain people are wanting to implement
> > > class-like
> > > > >inheritance because it is more familiar/comfortable to them.
> > > > >
> > > > >I strongly agree with Pascal. Prototype-based inheritance works
> > > > >beautifully,
> > > > >and is native to javascript, so why would we want to enforce a
> > > different
> > > > >type of inheritance to use the API? Most dynapi users will at least
> be
> > > > >familiar with javascript, and may be expecting Prototype-like
> behavior.
> > > > >
> > > > >It's kind of like creating a number class instead of using built in
> > > number
> > > > >objects and primitive types. It's pointeless.
> > > > >
> > > > >As far as the class/prototype argument as to what Netscape says,
the
> > > first
> > > > >line of this article:
> > > > >
> > > >
> > > >http://developer.netscape.com/docs/manuals/communicator/jsobj/con
> > tents.htm
> > > >
> > > >reads as follows:
> > > >
> > > >"JavaScript is an object-oriented language based on prototypes,
rather
> > > >than,
> > > >as is common, being class-based."
> > > >
> > > >-jaredn
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Dynapi-Dev mailing list
> > > >Dyn...@li...
> > > >http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > >
> > >
> _________________________________________________________________________
> > > Get Your Private, Free E-mail from MSN Hotmail at
> http://www.hotmail.com.
> > >
> > >
> > >
> > > _______________________________________________
> > > 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-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