[xinf] info for potential new developers

[Rostislav Siryk]

Dan, 

Thank you for sharing such interesting project!

At this moment I have not very much time to dive into this project but
one thing I can remember just right is now often flash developers
complained of poor realization of delegating events in AS2 API. One of
the complaints claims that Delegate.create method leaves created
delegate object in memory un-garbaged). So I wish you to not fall into
this trap (and the ones like it) from the early stage of XINF platform
development and to provide elegant and built-in delegating of events in
XINF API.

Good Luck with cool initiative of XINF!


Rost
http://flash-ripper.com/



>> -----Original Message-----
>> From: xinf-bounces at xinf.org [mailto:xinf-bounces at xinf.org] On Behalf
Of
>> daniel fischer
>> Sent: Friday, June 09, 2006 6:29 PM
>> To: xinf at xinf.org
>> Subject: [xinf] info for potential new developers
>> 
>> 
>> hi all, especially a warm welcome to the new members of this list.
>> 
>> some people have already expressed their interest to help development
of
>> xinf- which is great!
>> 
>> i have very little experience in terms of actual cooperation on
software
>> projects- so you'll have to bear with me if things go wrong. i
suggest
>> about the following:
>> 
>> if you're interested, maybe you could post a short intro about
yourself,
>> your experiences, and if you have any specific areas in mind where
you'd
>> like to help out. you are of course free to pick any area- there's
lots
>> to do. just let me know what you're working on, at least early. i
know
>> from my own experience that it's a bit hard to announce publically
some
>> work that you might not be sure you can finish- but to avoid too much
>> duplication, please at least tell me privately :) also, even if it's
>> unfinished, it might still be good for others to pick up on your
work- or
>> at least, not make the same mistakes.
>> 
>> also, of course, if you need starting pointers or ideas and
discussions
>> about how to do specific things- i (and others) might already have
ideas.
>> 
>> specifically, i see the following areas as needing most work that i
>> currently cannot do myself (or would delay if anyone would do them):
>> 
>>  * trying to get xinfinity to work on windows and OSX- the bindings
are
>> preliminary, and some stuff might be very linux-specific (yet). of
>> course, all the libraries i currently use should work well
cross-platform
>> (it is a fundamental criterion), but there's issues about linking,
>> compilers, etc.
>>  * architectural review- do you have any comments about how i
currently
>> do things in org.xinf.ony?
>>  * extension of xinfony- i would gladly delay work on the drawing api
>> (movieclip, canvas, xinfinity) if anyone is interested to start
working
>> here, or on other classes.
>>  * build system- currently it's all makefiles, maybe ant is better
suited
>> for cross-platform work? i have also some ideas to do a neko-based
build
>> tool (and configuration utility)- the support libraries/bindings
could
>> well be moved out of xinf because they could be useful for other
>> projects, too- but then i'd miss a tool to find out if and where
those
>> are installed etc.
>>  * see how it works out to base applications on xinfony- again, build
>> system here, but also testing if the basic ideas work.
>>  * starting on xinful- and/or a component set based on xinfony.
>> obviously, some stuff in xinfony might be missing to be able to do
this,
>> but i'm unsure what exactly :). this is a huge area where probably
some
>> design should be discussed first. OTOH, why not "just start" with
some
>> things like layout containers, basic buttons, etc. i'm a fan of
iterative
>> development- just dont be offended if things are thrown out/replaced
at
>> some point :)
>>  * a string-editing component for xinfinity would be great, and a
huge
>> step towards cross-runtime forms.
>>  * anything you might come up with- open for anything!
>> 
>> my own current focus is on the core xinfony api, the basic bindings,
and
>> what i call the "rendering equality test"- i want to make sure early
that
>> rendering looks as similar as possible, and to avoid regressions in
this
>> area, i want an automated system that uses Xvfb (the XWindows virtual
>> framebuffer) and compares the output of the various runtimes. once
the
>> test framework is running, it could also be used to test more than
just
>> rendering- but also UI event handling and the like.
>> 
>> so much for the start- let me know ;)
>> 
>> -dan
>> 
>> --
>> http://0xDF.com/
>> http://iterative.org/
>> 
>> --
>> xinf is not flash
>> http://xinf.org/