FSO milestone3 my view (ON gta01)

[Tilman Baumann]

Guillaume Chereau wrote:
> Hello Tilman. I will just comment on the tichy part of your email, since
> I am the main author.
> 
> On Fri, 2008-09-12 at 12:24 +0200, Tilman Baumann wrote:
>> I like the Tichy concept of having pythons apps running as plugins in 
>> one python runtime.
>> I always expected it to be something like a app launcher that
>> executes 
>> python modules rather than calling stand allonw apps.
> But it is exactly what it does.
> I think you misunderstood tichy. But still I want to defend my approach
> (that you seem to recommend so I am confused).
> Tichy is a python app. I can't afford to start a new python interpreter
> every time we open an application. I don't want to have too many python
> interpreters running at the same time either. My solution is to use a
> cooperative event based system for all the basics applications (dialer,
> messages, etc) They all run in the same interpreter, and share the same
> mainloop. That is what i refer to tichy as a "python applets manager".

Yea, the concept is great for me it was more a look and feel mishap.

>> Combining all apps into one screen does 
>> not help, we have window management.
> Do you mean we should use one X window per applet in tichy ? Well that
> is possible. In fact I have a backend for gtk+ and etk/evas (still
> experimental). Both of them use one window per applet.

Well, you just have defended Tichy well.
I was just not happy with that everything happens in one window, and 
only one applet at the time approach.

The gui is kludgy at the time. But as it is work in progress i have no 
problem seeing that change.

> So here is how it works :
> When you write an application for tichy, you use as few gui objects as
> possible. Instead, you define 'Items' with properties and possible
> actions.
> Then tichy will request for a plugin that offers the 'Design' service
> and ask this plugin to create the user interface for the application.
> the design plugin is free to create any interface, as long as it shows
> the proper items and provides a way to trigger the proper actions on
> those items (not unlike edje works)
> That is why I can create backends for almost any graphic library you can
> imagine, without changing the code of the applications.

Edje scrips come to my mind. :)
Sounds great.

>> The all in one concept is just wrong in my eyes. Great idea, but done
>> wrong.
> The concept is wrong or the idea is great but done wrong ?
> 
> For me the all in one concept is important, at least for all the basics
> phone applications. There is just too much communication between them.
> It is not only a matter of sharing data (the framework is there for
> this), but also being able to lauch one app from an other, and to share
> the screen space in a clever way. Also the time to launch an external
> application is too slow.

Yes and now.
The experience with the standallone gtk apps from 20082 was not too bad.
The only app that was a bit critical was the dialer.

I'm not sure what works better. Native single apps or python applets.
Native would at least be more interoperable.
And a applet like way would work too for native code...

>> And i would say it is time for some gui guidelines for new world etk, 
>> efl apps.
>> We have a great looking environment, now let's define how apps should 
>> look. And pleas don't make them look like qtopia, Zhone or tichy.
>> I have some ideas for that too. But i whink we need some
>> experimenting 
>> first...
>> Is there already some movement into finding the new way to interact
>> with 
>> the UI?
> Well, what about the idea I talked about : You define a set of minimal
> necessary information needed to construct the gui for many kinds of
> applications (most of the time an application is just trying to show
> some objects and let the user trigger actions on it). Then you use a
> plugin to actually construct the gui. 
> 
> I guess Raster was a visionary on this idea. In fact he is the one who
> gave me this idea once on irc, the next week I started implementing it
> in tichy :P
> But even the applications we have that do use edge don't do it the
> perfect optimal way. If your application's code use -let's say- a
> scrollbox, then you are already deciding that you want to show your
> items in a scrolled view, so what if the user want to show them in a
> table, or in a fancy 3d view like we start to see on a few closed source
> mobile phone ? Then you have to modify the application code.
> In tichy you would first create a list of items, and then ask the design
> service to create a view of that list. That view may be a scrollbox, but
> it may as well be anything else. You can actually play with this in
> tichy : application conf->design>grid/default/wheel

The right way. Besides, i would say the app should decide what category 
of look it wants and the user (framework) how it really looks.

I see some basic app schemes. Tabs, scroll-lists, hirarchical lists 
(scrollable) (like the tree columns finder fiew), tables.

How they react to clicks or if they slide or fade or or how many items 
are seen or whatever could be set globally.

I think we should steal some ideas from the iphone. They are by far not 
universal but they had some great ideas to steal. (Address book as 
hirachical list for example and how you can navigate there)

Or lists of items where the item expands to near fullscren for a detail 
view if you tap it...

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.