My idea is to have 1 edje group by window. The application create the
window, load the group and get the objects needed (buttons, list ...).
With this method in the theme you have a complete controls: you can use 5
panels or 2, display 3 list or 3 buttons to display one of the three list
...
With generic interface we will have a way to have a theme for bif screen
with a list and a second for small screen with a hoversel. But this part is
not my priority, this is a big job.
This is what I try to do with Enki. Then I will write a theme for small
screen like phone.
My first problem will be to retrieve the content of a elementary object. The
first object in the current enki theme is a elm_panels. I will add the
possibility to do this.
2010/7/19 Dave Andreoli <d...@gurumeditation.it>
> 2010/7/18 Gustavo Sverzut Barbieri <barbi...@profusion.mobi>:
> > On Sat, Jul 17, 2010 at 8:08 AM, Atton Jonathan
> > <jonathan.at...@gmail.com> wrote:
> >> Hello,
> >>
> >> I am writting this messages to give a list of what is needed in edje
> >> external. I am rewriting the layout of enki and I see some limitations.
> >>
> >>
> >> - We can't access to the content of a elementary widget (the content
> of
> >> elm_notify for example). With a evas box we can use "box[item_name]",
> we
> >> need the same tips with a external widget "notify[content]" or
> >> "panes["left"].
> >
> > As said at IRC, this is a problem harder to solve in Elementary than
> > in Edje/Externals API. We could just add a sub_object_get(name) to the
> > externals API, but we have no standard way to get them from
> > Elementary. If we need to implement it per-widget, it will be a major
> > pain to keep in sync.
> >
> >
> >> - a program which is in a group can't access to a sub-group. Simple
> >> example : I have a part in a item of a box, a program can't have this
> item
> >> as target "target:box[item]:part". If my program send a signal which
> should
> >> set the state of this rectangle, I can't :(
> >
> > I recall Cedric and Sachiel doing something related to it these days.
> > It should work with box and table at least.
> >
> >
> >> - We can set the target of a elementary widget. For example, I have a
> >> hoversel, I can't set his target. I have patched the hoversel, now the
> >> default target is the edje group but we can't set a part as target.
> >
> > Again, this is highly specific of the Elementary's EXTERNAL
> > implementation. You could do this today by exposing a property target
> > with a string property that internally retrieves the object by name
> > and calls the C function with it.
> >
> >
> >> - Currently a program can't listen a smart event from a elementary
> >> object. For example I can't have a program which listen the signal
> "clicked"
> >> of a elementary button.
> >
> > Well, it should be possible! Isn't it working? I did the initial
> > implementation in external_signals_proxy(). It will use the
> > introspection to listen to widget signals and proxy them to Edje, most
> > of the objects exposed already have that, but if some are missing you
> > can extend them just grep for Evas_Smart_Cb_Description in src/lib/,
> > usually you find some code like elm_button.c:
> >
> > static const Evas_Smart_Cb_Description _signals[] = {
> > {SIG_CLICKED, ""},
> > {SIG_REPEATED, ""},
> > {SIG_UNPRESSED, ""},
> > {NULL, NULL}
> > };
> >
> > ...
> >
> > evas_object_smart_callbacks_descriptions_set(obj, _signals);
> >
> >
> > If the part that contains the button is called "bt" you should receive
> > a "bt" "clicked" signal in Edje.
> >
> >
> >> - we need generic interface for list/genlist/hoversel ... then in the
> >> theme we can use other widegts (a list instead of a hoversel ...).
> This part
> >> is a big job.
> >
> > The sub-object management is not there, the problem is to define how
> > to interact with it without being too specific to some lib. For
> > instance, should we handle sub_object_get(name) (as above) and
> > sub_object_set(name, value), choosing inside name if we want to
> > append, prepend, insert or replace? Or should we create an extensive
> > API, with replication in Embryo and Lua and probably
> > edje_object_part_external with all possible sub-object management like
> > append/prepend/insert/remove/replace? Of course we have
> > middle-ground, with set, insert with key values such as -1 for end,
> > remove... without replace/append/prepend variants.
> >
> > Anyway, the api is easy to extend, however if we're doing it, better
> > do it sooner than later.
> >
> > But I'd like to see some real world use cases. In real world use
> > cases, one often populate things like boxes from C... often those uses
> > that you try to use them from Edje are wrong-usage, which you should
> > just have many parts in the same object, or use Edje's native
> > BOX/TABLE objects, or going even further, if you want your app to
> > provide specific hoversel to some items, you create your specialized
> > hoversel EXTERNAL in your app, register it to be used by Edje and have
> > fun.
> >
> > One of the bad points of abusing these interfaces is that in a way or
> > another, these are slower than plain C access. If you have to populate
> > a huge genlist, for instance, for each item you'd have to call a
> > function, resolve some text->object, then resolve text->function, then
> > do some strcmp(), then call the final function.... but if you just get
> > your edje_object_part_external_object_get(), you have the maximum
> > speed, with all the required interface, checks and clear API usage.
> >
> > IOW, I don't want to introduce some option of bad habits just to make
> > some demos simpler :-)
> >
> I totally agree with your position :)
> We need to NOT abuse edje, edje files should just describe your interface,
> don't make themes 'another program'
>
> DaveMDS
>
> >
> > --
> > Gustavo Sverzut Barbieri
> > http://profusion.mobi embedded systems
> > --------------------------------------
> > MSN: barbi...@gmail.com
> > Skype: gsbarbieri
> > Mobile: +55 (19) 9225-2202
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
--
Regards.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
