what is the difference between openMoko and windows mobile based phones

[Jacob Peterson]

On 1/19/07, Gervais Mulongoy <gervais.mulongoy at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070119/7b71e717/attachment.htm