Ok... I've been away for the last few days so this is the "1 reply fits all"
mail - so if I missed something, sorry - lots of stuff there! :)
OK. first. Ibukun (xcomp) - i know where you're coming from - but remember - it
was this playing with "apps" that was a learning stage for you and many others.
i encourage people to use it to learn, but at the same time you're right - it
should not become the FOCUS for people. That is why often i write a test app to
exercise things - get it done, then dump it and stop work in favor of something
else. it's a good tool for testing and learning.
but yes - we should have a meeting. the problem is organising a time. the
majority of people are in north America, with Europe probably second and well
I'm over here in Japan... so... that gets us spreading around the world pretty
much in all timezones. many of us have "work" - some of us can use IRC during
work, some can't.
so...
when? personally i'd say 11am Saturdays Tokyo time :) That'd be 1pm Sydney
time... but in the end i think it's going to be hard for everyone to make it -
e-mail is a good medium that allows us to dicuss this without a time issue... it
just takes longer :)
i will admit i haven't given evas a lot of attention of late, but its also a
sign of its maturity - it WORKS. there are many areas it could be improved - and
yes large object count efficiency is one. i have some plans that could reduce
the object count markedly too by adding api's for smart objects to provide PAINT
methods instead of creating multiple sub-objects to do drawing. this would lead
the way to extending evas directly with first-class objects just the same as
evas's internal objects work. evas technically could be worked on forever in its
own right - but i've chosen to stand back mostly as "it works" and until i NEED
something from it or find a bug it lies dormant in favor of other important
issues... such as edje, ecore and now e17 wm proper.
ecore is an ongoing expansion project - i can see it growing markedly. ecore_x
will expand as e17 and other apps need x wrappers/facilities. the old ecore code
is still there to "steal from" as needed. i intend to add code to ecore_x as i
need it as i work on e17. edje is the same. it works. i have stopped adding to
it as it is sufficient for e17's purposes for now. i will add to it, optimize
and fix "as needed". it can be worked on later.
this does NOT exclude others adding to it. ecore, edje and evas are open game
for improvements - but since each of these matures and grows changing/adding
becomes more of a large task so be ware of what you do and how you do it.
i have been working on e17 lately again - its not in cvs because i don't want to
encourage people to help just yet. i want to make it a solid foundation first.
when its ready it will go in. menus are moving along. they should be done (to
the point of being sufficient for use) soon.
my personal priorities focus towards getting e17 out the door. in the background
my intention is to make every component that goes to make the wm possible
modular and useful beyond the wm. i would like to later on produce a lot of cool
useful apps. i even would like to see E included on handheld distributions such
as familiar for pda's - but a stripped down "E for embedded" so to speak. i keep
this in the back of my mind for everything i am working on.
now back to e. before it goes in cvs i will flesh out my document on "how it
works" and "coding standards" i have some there - but i will watch e17's code
like a hawk - i want this code to remain clean and beautiful from the start.
previously e has suffered from code degredation - "code rot" over time with
different code, different styles, people, systems not interacting properly etc.
kwo is doing a great job of moving it along - but there's a lot of futz there
that e17 is intended to clear up - and i want it to STAY CLEAR.
now as for todo thigs that rbdpgn sent...
things i don't agree with (as i agree with most):
evas: text hinting <- eh? evas does hinted truetype kerned text... ? what
hinting? :)
estyle: i have it on my todo list to bring this into evas. the massive object
count (and repeated objects just at offsets and differing colours) really should
be done in evas. it's on the todo list - either in evas or via smart objects
with PAINT methods that draw all the text. also i want to add "filters" to evas
that u can apply to an object... blur was my first candidate... :)
as for docs. user docs right now aren't much of an issue as there is no "wm" to
install or configure. the libs themselves needs docs. some are fully documented,
some are partially documents, some are not documented at all. we need to compete
the docs for libs - and this is library api/tutorial etc. docs. the docs need to
go in the code as javadoc comments that doxygen processes. thats the priority in
the doc world atm. anyone who likes docs is invited to discuss maybe a better
way of generating the docs, but i think the javadoc format within the code is
here to stay. it is an industry standard...
now as to how to generate... doxygen does work - i have some issues with the way
it generates what are essentially documents for a library api - and doxygen
wants to generate docs as if the library's internal code is being documented (a
completely separate matter). right now doxygen doesnt do the best of jobs for an
api doc. i point to my old documentation i wrote by hand in staroffice for evas
0.6.0. that documentation is what a library api doc should be like.
now what we need to do is:
1. fix doxygen
2. replace with a new doc tool that does better and handles javadoc
3. take other doc tool and modify to produce nice docs given javadoc comments
4. write brand new doc tool.
i invite people to stand up to the plate here. vincent has already been poking
at it. but docs are important. right now library api, build, use, overall design
and tutorial docs are important, benr, rephorm, atmos and many others have
snippets of tutorials and docs. some bigger or smaller. we should at some point
combine these or move them to appropriate places. eg: evas tutorials and
"cookbook": examples that are only related to evas probably should go within the
evas docs etc.
i will admit though i'm not that fond of doing docs when there's so much code to
be done. help is ALWAYS appreciated.
now as for other things. i think entrance could do with more people working on
it. it does have bugs in many conditions - strange bugs but as a login manager
it needs to be fairly solid. it needs lots of testing in obscure circumstances
and fixing. it needs to be improved to handle peoples sessions failing and
providing useful feedback to a user than just presenting a login screen again if
their session fails to run. gui config tools and much more. it might need a
security audit - especially with xdcmp if its added.
there's so much to do... many libs have todo lists in their code/TODO files and
docs. a lot of code has FIXME's in it. they are easy to grep for.
anyway - i say we should continue the discussion on mail for now pending a time
we can all talk on irc, but that will be tough.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 (数田) [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
