Nick Hughart wrote: > On Wed, 16 Dec 2009 00:43:51 -0500 > Jose Gonzalez <jose_...@juno.com> wrote: > > >> Gustavo Sverzut Barbieri wrote: >> >> >>> On Tue, Dec 15, 2009 at 3:28 PM, Carlo Ascani >>> <carlo.r...@gmail.com> wrote: >>> >>>> Hi guys, >>>> i want to make a layout like this in my elm app: >>>> http://gnufunk.org/~carloratm/tmp/layout.png >>>> >>>> So this is what i've reached: >>>> http://gnufunk.org/~carloratm/tmp/scrot.png >>>> >>>> >>> First of all, this is not gtk/qt, so you're not forced to do layout >>> like that. If you have a known number of widgets (maybe you don't), >>> then it's better to use elm_layout and define positions in edje. >>> >>> >>> >>> >>>> The Question is: >>>> How could i make the slider takes up all the free space? >>>> I think i must use evas_object_size_hint_weight_set, but in wich >>>> way? This is part of my code: >>>> http://codepad.org/aJAYmWVV >>>> >>>> >>> You need to make the vertical slider to expand, this is done with >>> weight.y > 0.0 and align.y = -1.0: >>> >>> evas_object_size_hint_weight_set(pan[i], 0.0, EVAS_HINT_EXPAND); >>> evas_object_size_hint_align_set(pan[i], 0.0, EVAS_HINT_FILL); >>> >>> also note you're mixing these constants in weight, see the >>> documentation in Evas.h! (ok, it is confusing...) >>> >>> >> It's confusing indeed, even for those with a fair amount >> of familiarity with the 'core' efl. The main problem for new >> devs of elm apps will be the various namespaces, the various >> libs and api calls, how/when to use or not use this or that >> call in this or that lib within an elm app context. >> >> This is likely why both ewl and etk tried to give a more >> comprehensive set of api funcs within their namespaces, so as >> to be more self-contained, providing relevant gui functionality >> within a single namespace and suitable contexts. >> >> Requiring most elm app developers to struggle with the large >> evas api and documentation, not to mention maybe also ecore_evas, >> edje, and whatnot, to learn when/where/how to use or not some api >> func in them for their elm app... is going to be a major 'issue'. >> >> Taking a look at say the simple elm example app in >> http://trac.enlightenment.org/e/wiki/Elementary >> and all uses of evas_object_* function calls, one finds that >> certain ones are used over an over again, in particular: >> >> evas_object_smart_callback_add(); >> evas_object_size_hint_weight_set(); >> evas_object_size_hint_align_set(); >> evas_object_show(); >> >> Likely many elm apps will find themselves using only a very >> limited set of evas api funcs over and over again. >> >> It would probably be a good idea to take these kinds of funcs >> and provide equivalents thereof within the "elm" namespace... >> Thus helping to minimize mental context changes, create a more >> coherent api, minimize potentially conflicting uses, simplify >> and speed-up elm app developer workflow and learning curve, etc. >> >> > > I agree 110%. I find myself quite lost when using elm since I have to > dig through 2-3 different sets of documentation from various libs just > to use it. Even when I do find the function I'm never sure it's going > to work heh. Having the functions which will do something to a > particular widget namespaced within that widget will go a long way to > making it easier to use imo. >
Indeed. Let me also remark that (as I tried to explain here long ago) there is absolutely no gain to exposing Evas/Evas_Object and apis in gui toolkits and a lot of confusion created instead. Everything that elementary + evas + edje can do could've been done within the context of ewl or etk (sans evas) if these were suitably modified and/or suitable widgets for them created. All arguments otherwise were absolutely bogus nonsense. If one wants a 'canvas' interface then it is trivial to add such an object type (one which allows for arbitrary positioning of its children), or to add as many 'gfx' object types as desired (for use anywhere with the toolkit), or to add further kinds of container/layout types, etc. This gives a much more contextual api for what you can do with things, far more coherent with fewer conflicts and yet allows you to have all the desired flexibility for both rich and not-so-rich gui app development. Gui toolkits like gtk and qt have problems and inefficiencies doing this since their widget instances correspond to display window instances and are thus now going thru hoops and contortions to do so. But ewl and etk did not have that problem and could've become excellent by now if many here had not ignored them, had realized what they could've become, and had being more supportive of their development towards such an end. Ecore/evas/edje are good low-level building blocks for creating higher-level gui libs. It is not necessary to directly expose them in those higher-level gui libs to obtain various functionality, and exposing them is mainly a source of confusion for app developers which use the higher-level gui libs. ____________________________________________________________ Stock Options Click to learn about options trading and get the latest information. http://thirdpartyoffers.juno.com/TGL2141/c?cp=4XQnpYyZAPQfs0o2pS7P0QAAJ1D4PmlFt_ntIuQZeUdWBkovAAYAAAAAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAAAAQlgAAAAA= ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
