what is the difference between openMoko and windows mobile based phones

Fri Jan 19 15:05:59 CET 2007

>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

On 1/19/07, Jacob Peterson <jacobp at iastate.edu> wrote:
>
> Hank,
>
>  I want to thank you for stimulating such a great discussion.
>
>  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 enlightenment
> project <http://enlightenment.org> seems to be a great example of this
> along with the more recent versions of gnome<http://www.gnome.org/start/2.16/>.
> 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.
>
> --Jacob
>
> On 1/18/07, hank williams < hank777 at gmail.com> wrote:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Regards,
> > Hank
> >
> > 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.
> >
> > On 1/18/07, Richard Franks < spontificus at gmail.com> wrote:
> > >
> > > On 1/18/07, hank williams <hank777 at gmail.com> wrote:
> > > > I believe too many cooks spoil the stew, which is often a
> > > > problem in open source, in my opinion. Its also often also a problem
> > > inside
> > > > corporate development efforts. When there is no clear and absolute
> > > > leadership, product design suffers. This is of course my opinion,
> > > based on
> > > > my 30 years of software development. It is, nevertheless an opinion.
> > > Your
> > > > mileage may vary.
> > >
> > > I see this being true for monolithic projects such as a kernel, or an
> > > office productivity suite.. I would say that it's debatable whether
> > > the same holds true for the types of micro-application which are going
> > >
> > > to be created using the OpenMoko API (which as a foundation does
> > > appear to have clear leadership).
> > >
> > > Monolithic product design I believe arose from distribution and OS
> > > layer limitations - when you simply couldn't download weekly updates
> > > or patches, the product had to get it right the first time. It didn't
> > > always happen that way of course, but there was no real alternative as
> > > the network infrastructure hadn't been built up yet.
> > >
> > > Communication accelerates standardisation, and standardisation paves
> > > the way for smaller tighter applications. Given the diversity of
> > > interests shown on this list, I don't think we'll run into the
> > > too-many-cooks issue any time soon.
> > >
> > > Out of interest, which Open Source projects have fallen victim to the
> > > too-many-cooks problem?
> > >
> > > Richard
> > >
> > > _______________________________________________
> > > OpenMoko community mailing list
> > > community at lists.openmoko.org
> > > https://lists.openmoko.org/mailman/listinfo/community
> > >
> >
> >
> > _______________________________________________
> > OpenMoko community mailing list
> > community at lists.openmoko.org
> > https://lists.openmoko.org/mailman/listinfo/community
> >
> >
> >
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/community
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070119/8dbc414e/attachment.htm 