>From <a href="http://www1.get-e.org/E17_User_Guide/English/_pages/3.7.html">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/" target="_self" title="http://www.enlightenment.sourceforge.net">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><br>Gervais<br><br><div><span class="gmail_quote">On 1/19/07, <b class="gmail_sendername">Jacob Peterson</b> <<a href="mailto:jacobp@iastate.edu">jacobp@iastate.edu</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;">
Hank,<br><br> I want to thank you for stimulating such a great discussion. <br><br> I think I have an understanding of where your trying to go with this and I understand that having such a free and democratic process of creating an UI for a mobile platform would be very difficult. However, looking at other open source projects that I perceive as having decent UI's, from what I can tell it seems their success usually stems from the fact the project leaders are talented graphical designers along with programmers who can decide on a common graphical interface and build following that. The
<a href="http://enlightenment.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">enlightenment project</a> seems to be a great example of this along with the more recent versions of <a href="http://www.gnome.org/start/2.16/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
gnome</a>. Dare I suggest contacting people who are skilled at graphical design, and would be willing to donate time, to help led the development of the UI? They could be our "elected officials" to help moderate down all the different ideas and requests to make them fit into a common vision and hopefully a great UI.
<br><span class="sg"><br>--Jacob</span><div><span class="e" id="q_110398a18d1641b3_2"><br><br><div><span class="gmail_quote">On 1/18/07, <b class="gmail_sendername">hank williams</b> <<a href="mailto:hank777@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
hank777@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;">
I should clarify and say the issue that I am refering to specifically relates to UI/design. There are very few people that are good at it, so when those "good" people are not in absolute control and overly influnenced by committees, the design suffers. The good news about most open source products that have been successful is that they are more often API driven. Linux, the apache stuff, languages, etc, etc. Honestly, I havent yet seen an open source product whose UI I really like except firefox which is darned near commercial in the way that it is run.
<br><br>Graphics programs, Interface shells, video programs... I am not going to name names because then someone will either get upset or start misinterpreting. But I have yet to see something that I thought lived up to the best proprietary interface/UI designs. I cant say I have seen everything, but I have seen a lot. I think Open Source kills when it comes to creating high quality maintainable code. But I personally dont think the community process works as well for design and UI. I know people will disagree, and I really dont want to get into a back and forth with people getting upset and trying to prove me wrong. Its just my opinion. And of course there are always exceptions.
<br><br>Oh and by the way, I am not saying OpenMoko will have this problem. It specifically relates to the community process of development. But satisfying everyone's requests/demands in a UI is a sure sign of trouble and is much more prevalent in a more democratic process. Depending on how they manage the process and the form of the leadership it may not be an issue at all. They just have to be good designers themselves, and be willing to say "no" when warranted.
<br><br>Regards,<br><span>Hank<br></span><br>p.s. These are just my opinions. I have said it before, but many people have different perspectives on what it takes to make great products. I am not sure why anyone would care about my views on this subject.
<div><span><br><br><div><span class="gmail_quote">On 1/18/07, <b class="gmail_sendername">Richard Franks</b> <<a href="mailto:spontificus@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
spontificus@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;">
On 1/18/07, hank williams <<a href="mailto:hank777@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">hank777@gmail.com</a>> wrote:<br>> I believe too many cooks spoil the stew, which is often a
<br>> problem in open source, in my opinion. Its also often also a problem inside
<br>> corporate development efforts. When there is no clear and absolute<br>> leadership, product design suffers. This is of course my opinion, based on<br>> my 30 years of software development. It is, nevertheless an opinion. Your
<br>> mileage may vary.<br><br>I see this being true for monolithic projects such as a kernel, or an<br>office productivity suite.. I would say that it's debatable whether<br>the same holds true for the types of micro-application which are going
<br>to be created using the OpenMoko API (which as a foundation does<br>appear to have clear leadership).<br><br>Monolithic product design I believe arose from distribution and OS<br>layer limitations - when you simply couldn't download weekly updates
<br>or patches, the product had to get it right the first time. It didn't<br>always happen that way of course, but there was no real alternative as<br>the network infrastructure hadn't been built up yet.<br><br>Communication accelerates standardisation, and standardisation paves
<br>the way for smaller tighter applications. Given the diversity of<br>interests shown on this list, I don't think we'll run into the<br>too-many-cooks issue any time soon.<br><br>Out of interest, which Open Source projects have fallen victim to the
<br>too-many-cooks problem?<br><br>Richard<br><br>_______________________________________________<br>OpenMoko community mailing list<br><a href="mailto:community@lists.openmoko.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
community@lists.openmoko.org</a><br><a href="https://lists.openmoko.org/mailman/listinfo/community" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://lists.openmoko.org/mailman/listinfo/community</a><br></blockquote></div><br>
</span></div><br>_______________________________________________<br>OpenMoko community mailing list<br><a href="mailto:community@lists.openmoko.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
community@lists.openmoko.org
</a><br><a href="https://lists.openmoko.org/mailman/listinfo/community" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.openmoko.org/mailman/listinfo/community</a><br><br><br></blockquote>
</div><br>
</span></div><br>_______________________________________________<br>OpenMoko community mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:community@lists.openmoko.org">community@lists.openmoko.org
</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="https://lists.openmoko.org/mailman/listinfo/community" target="_blank">https://lists.openmoko.org/mailman/listinfo/community</a><br><br><br></blockquote>
</div><br>