[xinf] HA: info for potential new developers

[Rostislav Siryk]

Dan,

As you probably know, 'flash' trademark is owned by Adobe. And not so long ago there was one unpleasant legal issue with SWFObject by Geoff Sterns which was previously named FlashObject. He renamed FlashObject to SWFObject because Adobe legal department asked him to do that. You can read all details about that issue directly at the Geoff Sterns blog: http://blog.deconcept.com/2006/04/21/flashobject-to-become-swfobject/

I don't want to bring you a headache but you'll probably fall into more tangled issues at next phases of the XINF project if I'll don't alarm right now at the current very early stage of XINF development. It will be harder to rename all project stuff later if Adobe legals ask you to do it.

Good Luck!

rost,
http://flash-ripper.com/

P.S. I've just wrote this message and thought: what about my site's name? I use 'flash' there too... hm. 




-----Исходное сообщение-----
От: xinf-bounces at xinf.org от имени daniel fischer
Отправлено: Пт, 09.06.2006 18:28
Кому: xinf at xinf.org
Тема: [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/