On Mon, 16 Feb 2004 01:44:40 -0600 Nathan Ingersoll
<[EMAIL PROTECTED]> babbled:
> On Mon, Feb 16, 2004 at 04:08:35PM +0900, Carsten Haitzler wrote:
> >
> > 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? :)
>
> You would need to ask xcomp about this, I wasn't quite clear on what he
> meant by this either. His example was a comparison of Evas font
> rendering to gnome, apparently Evas looked rather bad in comparison.
hmm - we could be calculating kerning differently with sub-pixel co-ords... not
sure though. evas does its position in 26.6 sub-pixel positioning (then a glyph
will be placed rounded down to the nearest pixel position)
> > 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... :)
>
> Yay! :-) Last we talked about this, there didn't seem to be a clear
> decision on whether pixel level access to text would be available. If
> that will be possible, then I'm all for estyle either a) moving into evas
> or b) adapting to the availability of these features.
oh oh.. no - not pixel-level access to the text. the filter idea would be
internal so u say evas_object_filter_set(o, "blur", "10"); to indicate this
object is to blur 10 pixels... whatever object it is. i'm not clear on the api
yet tho... :)
> > 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...
>
> At this point, I would be more inclined to spend time writing more
> actual documentation than messing the tool that generates the end docs.
> API doc's are nice, but the "cookbook" is far more important. Ideally,
> we would have a set of introductory articles for each major lib.
yup. cookbook is very important. doctools - i'm not planning on doing much
myself. just writing docs (when i get to it). how those comments in the C code
become a document.. is another matter
> Lots to do indeed.
>
> --
> ------------------------------------------------------------------------
> | Nathan Ingersoll \\ Computer Systems & Network Coordinator |
> | [EMAIL PROTECTED] \\ http://www.ruralcenter.org |
> | http://ningerso.atmos.org/ \\ Rural Health Resource Center |
> ------------------------------------------------------------------------
>
>
--
------------- 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
