On 1/19/07, Gervais Mulongoy <[EMAIL PROTECTED]> wrote:
>From Get-E <http://www1.get-e.org/E17_User_Guide/English/_pages/3.7.html>website: 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 http://www.enlightenment.sourceforge.net : *"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.* *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. 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.*" * *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). 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. 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. 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. Gervais
Gervais, 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.
_______________________________________________ OpenMoko community mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/community
