On Wed, 8 Oct 2003 13:23:59 -0400 Ben Jansens <[EMAIL PROTECTED]> babbled:
> Greetings,
>
> I've been looking for a project to work on recently, and heard that
> Enlightenment's Window Manager had been scrapped in favor of a rewrite. This
> interested me greatly and so I have started digging around in the e17 source
> tree.
ok - let me clarify what you heard... e's codebase has been in that state for
something like a YEAR. it's been pending the libraries underneath it to 1.
sabilize, 2. be cleaned up, 3. be finished.
basically recently the last bits needed for going back to work on the wm came to
a sane level of maturity (this last piece was edje). most of e's "brains" live
in the libraries under it. a LOT of work has gone into these and is still going
on. several libraries keep being worked on in parallel which aren't per-se
required for the wm, or are so intrinsicly required thet their feature set will
expand as the wm does. ewl, ewd, etox are working in parallel, ecore itself is a
prerequisite for almost everything, but part of it (ecore_x) will grow
significantly as E does. the old ecore code is still in that tree so it can be
"stolen from" as needed.
> I have noticed throughout that there is a lack of support for new standards
> coming out of freedesktop.org, and so I was wondering the position of the
> Enlightenment project on such standards as the WM Spec, Base-dir Spec, Menu
> Spec, MIME Types Spec, Icon Theme Spec, StartupNotification Spec, etc.
you might be surprised. first the OLD ecore has support for xdnd. there is SOME
minimal support for NETWM in the new ecore and help is MORE THAN APPRECIATED. we
want to support these things (where appropriate) by wrapping them up in api
calls in ecore/ecore_x or some other new library (look in e17/proto/esmart and
u'll see some "prototype" code for supporting thumbnails specs).
> There are quite a few good things coming out of freedesktop.org and I think
> Enlightenment would be missing out greatly to not work with these
> specifications.
we take all things with a grain of salt. just because there's a standard does
not mean its good, efficient or appropriate to our needs. we will support
standards where this is applicable, otherwise will will do what we see fit. in
some cases we may not have a choice. but we do want to support standards. we
won't jump on them the moment they appear as someone's idea on a mailing list -
we will likely let them sit and gestate for a while.
> As my interest is in the Window Manager paricularily, I am concerned with
> the lack of UTF-8 text support. The ECore library provides functions for
> getting/setting window titles, but not the new UTF-8 titles provided for in
> the freedesktop.org WM Spec. Adding support for UTF-8 also means adding a
yes these calls are mere simple wrappers adound the basic x calls to do this.
they dont really define much as far as input/output goes yet. yes we want to
support utf-8. evas is completely utf-8 supporting. utf-8 is what we'd like to
deal with ONLY - and no other encodings. the job of ecore_x would be to convert
form utf-8 in the client api into whatever encodings needed in X and back again.
right now it doesnt do that all - but it'd be desired. i.e. it'd take the utf-8
input text and set the window title text in whatever encoding was needed, then
when getting the title translate back to utf-8. if multiple properties are used
for utf-8 title text and old-style wm hints, then ecore would preference the
utf-8 one and in parallell set/get the old legacy properties as well. you get
the idea.
> lot of functions somewhere for handling such strings. For a decent idea of
> what sorts of functions could be needed, take a look at
> http://developer.gnome.org/doc/API/2.0/glib/glib-Unicode-Manipulation.html
> and
> http://developer.gnome.org/doc/API/2.0/glib/glib-Character-Set-Conversion.html
the only functions really needed (prev and next char) are alreayd provided by
evas. edje alreayd handles text "manipulation" when fitting text into a box etc.
it's utf-8 safe.
> For just a Window Manager, only a rather small subset of those would be
> needed, but as the e17 libraries do much more than just window management,
> in the end many of those would probably need to be implemented. UTF-8 is
> emerging as the standard for all text in the open source world, and I would
> suggest that all of the e17 libs text handling routings (e.g. in Evas)
> should deal strictly with UTF-8 strings.
that is the case already - well in the mature libs it is. evas is one of the
most mature that actuaslly needs to care about utf-8 at all - and it is all
unicode utf-8. that's its assumption with the strings coming in. i would like
all e17 libs to think the same way - saves us work having to convert text
strings all the time, and is a standard that is really a superset of what is
needed anyway - so it handles anything we will need in future. ecore is being
moulded all the time, so expect it to change. help is definitely appreciated as
there is simply tonnes of it to do.
> So where is Enlightenment trying to go in regard to such specifications?
see above. :)
> Thanks,
> Ben
>
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 [EMAIL PROTECTED]
Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
