<br><br><div><span class="gmail_quote">On 1/19/07, <b class="gmail_sendername">Gervais Mulongoy</b> <<a href="mailto:gervais.mulongoy@gmail.com">gervais.mulongoy@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>From <a href="http://www1.get-e.org/E17_User_Guide/English/_pages/3.7.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Get-E</a> website:<br><br><p style="margin-left: 40px;">EDJ comes from the word
Edje, which is one of the Enlightenment Foundation Libraries (EFL).
Here is a slightly edited (some references related to an old theme
format that's no longer in use in E17 have been removed) quote from <a href="http://www.enlightenment.sourceforge.net/" title="http://www.enlightenment.sourceforge.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.enlightenment.sourceforge.net
</a>:</p>
<p style="margin-left: 40px;"><i>"Edje
is a complex graphical design & layout library. For the purposes of
Enlightenment 0.17, Edje should serve all the purposes of creating
visual elements (borders of windows, scrollbars, etc.) and allow the
designer the ability to animate, layout and control the look and feel
of any program using Edje as its basic GUI constructor. This library
allows for multiple collections of Layouts in one file, sharing the
same image database and thus allowing a whole theme to be conveneintly
packaged into 1 file and shipped around.</i> </p>
<p style="margin-left: 40px;"><i>Edje separates
the layout and behavior logic. Edje files ship with an image database,
used by all the parts in all the collections to source graphical data.
It has a directory of logical part names pointing to the part
collection entry ID in the file (thus allowing for multiple logical
names to point to the same part collection, allowing for the sharing of
data betwene display elements). Each part collection consists of a list
of visual parts, as well as a list of programs. A program is a
conditionally run program that if a particular event occurs (a button
is pressed, a mouse enters or leaves a part) will trigger an action
that may affect other parts. In this way a part collection can be
"programmed" via its file as to hilight buttons when the mouse passes
over them or show hidden parts when a button is clicked somewhere etc.
The actions performed in changing from one state to another ar also
allowed to transition over a period of time, allowing animation.<br> <br>
This separation and simplistic event driven style of programming can
produce almost any look and feel one could want for basic visual
elements. Anything more complex is likely the domain of an application
or widget set that may use Edje as a conveneient way of being able to
configure parts of the display.</i>"</p><div style="margin-left: 40px;"><i>
</i>Both themes and
backgrounds use this format in E17. This also means that the EDJ binary
background files can, just like E17 themes, contain all kinds of
animations and effects (or just a simple static background that is
scaled to fit the screen).<br><br></div>The basic philosophy of Enlightenment makes too much sense to me, namely that with a small set of graphic elements and "simplistic" event-driven behavior, any look and feel and be reproduced. This keeps the programmers happy in terms of creating applications that have a consistent feel, and it also keep the graphically inclined happy because they can continuously tailor the look to suit whatever aesthetic norms rule the day.
<br><br>Either way, we would not need to resort to the kind of benign tryanny that is used to develop and maintain the Linux kernel (see Linus orvald), we can leverage the so-called "open source" community talent to create a complete UI that flows and whatnot. Notice that this balance is largely achieved because of the tools (for example Edje) being used as opposed to enforcing any specific UI guidelines, at least this is sorta how Enlightenment does it. It is my belief that in this regard Enlightenment is ahead of both KDE and Gnome (though KDE is catching up rapidly). We can learn from this.
<br><br><br>Regarding have "elected officials", I think we can style development a lot like how FreeBSD does things, with a set of core developers with armies of patch artists. The core developers maintain and develop the main OpenMoko tree or whatever. The patch artists (most likely us) break stuff and report the bugs preferably with debug traces and patches back to the core. In terms of who makes up the core, bah, who has the patience to hold elections hehehe. The core developers need to have a simple mandate, and their "membership" is recruited to fulfill that mandate. I guess this is where the elections could be...anyways, I haven't really thought much about this, and I think I might be raving so its time for a coffee break. Let me know what you think.
<br><span class="sg"><br>Gervais</span></blockquote></div><br>Gervais,<br><br>I think you have hit the nail on the head so to speak. Looking closer at Enlightenment and even OSX they both keep the continuous flow to their UI not solely because they have a dictator to say what is used and what is not, but because they have a great common framework that everyone uses for the UI. Having a good base framework would not only make developing applications with a common UI easier, it would also make enhancements such as themes and other decorations much easier to create allowing for more people who may not be expert coders to get involved and more innovation.
<br>