On Mon, Sep 20, 2010 at 12:51 PM, pieterg <[email protected]> wrote: > On Monday 20 September 2010 16:26:03 Gustavo Sverzut Barbieri wrote: >> On Mon, Sep 20, 2010 at 11:02 AM, pieterg <[email protected]> wrote: >> > I have an application which implements the complete userinterface in >> > edje. The userinterface contains a scroll list, which I implemented >> > using an esmart container, in an edje SWALLOW part. >> > >> > However, esmart seems to be deprecated for a while now, so I would like >> > to get rid of the esmart container. >> > >> > But I cannot find a nice replacement, which allows me to implement >> > scrolling. >> > Except for elementary perhaps, which looks very convenient, both for my >> > scrolllist, but also for my text entry fields (which I had to implement >> > hard way as well). >> > >> > But, from the examples and howtos I've found so far, it looks like >> > using elementary would mean rewriting the whole application, and use >> > elementary for the complete gui. >> > (and moving most of the gui/layout stuff out of the edc into the >> > application, in the process) >> > >> > Is that the only way to use elementary? Or would there be way to use a >> > single elementary object, and swallow it in an edje group? >> > (elm_layout seems to get close, but still it needs an elm_win parent) >> > >> > Or is there another way, which allows me to replacy just my esmart >> > container scroll list, without having to rewrite the complete >> > userinterface? >> >> You should use elementary, it's the recommended way so far. >> >> To use edje objects there, just use the elm_layout helper... it >> provides the edje object for you to use and hooks into elementary >> stuff, also provides elm_layout_content_set() that automatically >> adapts/recalculates the size when child modifies and deletes children >> when elm_layout dies. Other than this, I'd recommend using elm_win to >> get some benefits like focus and others working. > > Thanks for your reply. > I guess this is the other way around, using elementary and putting edje > objects in it, instead of using edje and putting a custom list object in > it, as I was doing now with esmart_container?
yes and no. not a hard requirement, but it is advisable to use elm_win instead of ecore_evas. Other stuff can remain as-is. >> Last but not least, if you have a full edje layout, you may consider >> using the new type: EXTERNAL infrastructure! it's super cool as it >> makes SWALLOW usage easier. Elementary and Emotion are external-ready >> and you can use them right now. > > That would then allow 'putting a custom list object in an edje layout' > again? > I'll have a look at this, it sounds like this might mean I can start > replacing individual gui parts by elementary objects, instead of having to > rewrite everything from scratch. sure! the edje external allows "automatic swallow", just define a couple of objects in your code, then expose them using Edje's External API... in your theme you go and "use" them. As I said we already provide elementary and emotion, but you should also export your own app things there. as for avoiding the rewrite, elementary is a set of evas_object meant to play well with other objects, so you can mix them, and you can apply radically different visuals to your application just setting elm overlay or extension + styles. so yes, you can avoid rewrite and still have a very custom look and feel. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
