> After a few weeks of spare-time development, I'd like to announce
> Efreet, a new implementation of the XDG (freedesktop) specs for
> Icons, Menus and Desktop Entries.
> The current implementation, Ecore_Desktop, while a commendable
> effort for a sole developer under time constraints, leaves a bit
> to be desired. So, dj2 and I started reading through the xdg specs,
> and playing around with our own implementation, code named Efreet.
> After speaking with onefang about some of the issues with ecore_
> desktop, he said it was due for a rewrite, so we continuted with
> our replacement implementation. Rbdpngn and Engelbass also pitched
> in.
>
I think that this is a remarkable and commendable effort
on the part of all those involved, and I hope that it also inspires
more such coordinated group efforts in other areas as well. :) This
particular area, ie. xdg 'specs' and such, I believe is important
to e, and it should be well covered (much credit must go to onefang
for having single-handedly taken this difficult task on, and having
done so much with it.. BTW: what's become of the fanged one?).
> The next question is, assuming you guys see it as a viable
> replacement for ecore_desktop, do we stick this somewhere in libs
> (as efreet or e_xdg, or whatever name) or do we cram it in to
> ecore? My vote is that we stop bloating ecore in the name of a
> 'dependency freeze' and keep proper separation of libraries.
> (Its all 'new code' that needs to be verified and tested regardless
> of where we stick it).
>
> Let us know what you guys think.
>
> rephorm
There are many aspects of the current structuring of 'ecore'
that are less than satisfactory. If "e" is to advance in a constructuve
way, then it must build upon what it builds (and upon other 'external'
sources as well).
Wether ecore is a single lib, or a set of libs with some tree
of dependencies, it still needs a clear, logical structure. There are
many ways one could do that, and if one looks eg. at other projects
(gnome/kde/gnustep/...), one might see some patterns that could be
useful.
Things like qt and gtk seem to have fairly decent "core" libs,
and seem to have a separation between that and their "gui" aspects,
which latter depend on the non-gui 'core' part. But it still leaves
open the question of just 'what' should belong in one but not the
other, or what should be a separate entity that depends on one or
both such, etc.
I would say though that it's important to keep a 'large',
rather than a 'small', view in mind... if one wants "Enlightenemnt",
not only the window manager, to grow.
jose.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
