At Fri, 14 Mar 2014 09:26:19 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> > On Thu, 13 Mar 2014 10:29:12 -0400 Robert Heller <[email protected]> said: > > > At Thu, 13 Mar 2014 12:17:22 +0900 Carsten Haitzler (The Rasterman) > > <[email protected]> wrote: > > > > > > > > On Wed, 12 Mar 2014 21:14:17 -0400 Robert Heller <[email protected]> > > > said: > > > > > > > At Thu, 13 Mar 2014 09:22:59 +0900 Carsten Haitzler (The Rasterman) > > > > <[email protected]> wrote: > > > > > > > > > > > > > > On Wed, 12 Mar 2014 12:20:43 -0400 Robert Heller <[email protected]> > > > > > said: > > > > > > > > > > > With code like this: > > > > > > > > > > > > Evas_Object *o; > > > > > > > > > > > > o = edje_object_add(e_comp_get(m->zone)->evas); > > > > > > evas_object_name_set(o, "menu->sw_bg_object"); > > > > > > evas_object_data_set(o, "e_menu", m); > > > > > > e_theme_edje_object_set(o, "base/theme/menus", > > > > > > "e/widgets/menu/default/background"); > > > > > > m->sw_bg_object = o; > > > > > > sm_object = e_start_menu_realize_inwindow(m,m->sw_bg_object); > > > > > > edje_object_part_swallow > > > > > > (m->sw_bg_object,"e.swallow.content",sm_object); m->cur.w = 350; > > > > > > m->cur.h = 420; > > > > > > m->cur.x = 0; > > > > > > m->cur.y = 0; > > > > > > > > > > > > And later (in the idle handler): > > > > > > > > > > > > evas_object_move(m->sw_bg_object,m->cur.x,m->cur.y); > > > > > > evas_object_resize(m->sw_bg_object,m->cur.w,m->cur.h); > > > > > > E_LAYER_SET(m->sw_bg_object,E_COMP_CANVAS_LAYER_MENU); > > > > > > E_LAYER_SET(m->container_object,E_COMP_CANVAS_LAYER_MENU); > > > > > > evas_object_show(m->sw_bg_object); > > > > > > > > > > > > e_start_menu_realize_inwindow() contains: > > > > > > > > > > > > Evas_Object *o; > > > > > > > > > > > > /* Create the menu container, an Elm Table widget. */ > > > > > > o = elm_table_add(canvas); > > > > > > m->container_object = o; > > > > > > elm_table_homogeneous_set(o, EINA_FALSE); > > > > > > elm_table_padding_set(m->container_object, 5, 5); > > > > > > evas_object_size_hint_weight_set(o, EVAS_HINT_EXPAND, > > > > > > EVAS_HINT_EXPAND); evas_object_size_hint_align_set(o, > > > > > > EVAS_HINT_FILL, > > > > > > EVAS_HINT_FILL); evas_object_name_set(o, "menu->container_object"); > > > > > > evas_object_intercept_move_callback_add > > > > > > (o,_e_intercept_container_move,m); > > > > > > evas_object_intercept_resize_callback_add > > > > > > (o,_e_intercept_container_resize,m); elm_object_focus_allow_set > > > > > > (m->container_object, EINA_TRUE); elm_object_focus_set > > > > > > ( m->container_object, EINA_TRUE); > > > > > > > > > > > > /* e_start_menu_realize_inwindow() then populates > > > > > > m->container_object > > > > > > * -- eg create more elm widgets and pack them with > > > > > > * elm_table_pack(m->container_object, ...) calls -- standard > > > > > > stuff > > > > > > * straight out of the elementary docs. > > > > > > */ > > > > > > > > > > > > /* Finally: */ > > > > > > /* Return the container. */ > > > > > > return m->container_object; > > > > > > > > > > > > This code works, but the widgets in m->container_object have a > > > > > > *transparent* background, that is, for some reason 'm->sw_bg_object' > > > > > > is ending up as transparent, even though > > > > > > "e/widgets/menu/default/background" isn't defined as transparent (as > > > > > > far as my understanding of the menu.edc file in the theme goes). I > > > > > > don't want that. What do I need to do to NOT have a transparent > > > > > > background? Should I be using a *different* theme group? Am I > > > > > > missing a edje_object<mumble> function call somewhere? > > > > > > > > > > you're missing some information here. or confused. yes - normally menu > > > > > items we have in e are transparent (widgets IN m->container_object... > > > > > ie > > > > > inside of it, not the container itself or the bg object which is a > > > > > parent). this is what is designed and wanted so the menu background > > > > > (bg > > > > > object) shows through, UNTIL a menu item is selected, then it becomes > > > > > "solid" (dark black with some gradients, shadowing etc.). that's the > > > > > way it's designed, but then later you're talking about the menu > > > > > background being transparent... which it is not by default. for sure. > > > > > > > > > > so is it that your menu background is transparent .. and that's your > > > > > problem, or that the items themselves are transparent and you see > > > > > through to the menu background? > > > > > > > > The background is transparent. The populated items in the 'menu' are > > > > opaque. The table contains several genlist objects, not all of which > > > > fill > > > > all of the available space and the 'unused' space is transparent. I'll > > > > take a screen short and post it tomorrow. > > > > > > well i need to see what you're seeing, but what you are saying doesn't > > > make > > > sense given the default theme, that menus already work that way and are > > > opaque etc. - i am unsure what is wrong there at this stage. > > > > I uploaded a screenshot: > > > > http://www.deepsoft.com/wp-content/uploads/2014/03/transparent_start_menu.png > > wow! wtf? mwm? or fvwm? wow! with fixed font! i feel like i'm back in 1994! :) Yes, I run fvwm is mwm mode on my host system. Predates 1994. More like mid 1980s -- back in the days of DECWindows (DECWindows = rebranded Motif) under VMS on VAXStations (then under Ultrix on DECStations, then fvwm on Linux on various PCs). I *liked* DECWindows. > anyway... i don't see any evidence of the background at all. i do notice the > table is visible and no call to show the table object exists... so there is > other code that messes with that table that is not in this email... somehow > it's being unparented by some other code. and there is simply no sign of the > bg > object at all. - why , i don't know. Well, the setting the size / position of the sw_bg_object does affect the table, so the swallow works. In the line: o = elm_table_add(canvas); 'canvas' is the second argument to e_start_menu_realize_inwindow(), that is the background object. Maybe that is wrong? What is the correct way to get a Evas_Object pointer to use as the 'canvas' for creating elm widgets on? Somehow I need to get from the Evas pointer to the something to create elm widgets on. > > > > > > i do have some q's - why do you set move/resize intercepts on the > > > > > table? you want the emnu bg to swallow your table and control it... > > > > > why > > > > > not just let it do that? also be aware using elm objects in e's canvas > > > > > like this will mean certain things are going to be iffy - like focus > > > > > handling, so i'd suggest skipping that for not (elm_object_focus_* > > > > > calls - just going to clutter up your code at the moment). also > > > > > setting > > > > > padding manually - i don't suggest that. it won't scale based on dpi > > > > > or > > > > > scaling factors, or finger size etc. i'd suggest not having any > > > > > padding,a dn any spacing around items, do that in the theme, not in > > > > > code (ie in edc). also you set the name of the container object.. you > > > > > know if you have submenus or other menus, with the same name, there > > > > > can > > > > > be a clash. i generally avoid setting object names because they do > > > > > share a flat namespace. beware. also tables are not homogeneous by > > > > > default. no need to set that to false as that's how they come. > > > > > > > > The intercepts are mostly for debugging and for capturing the size and > > > > location information. > > > > > > you are probably better off using resize and move event callbacks. they > > > don't interfere. intercepts do. > > > > OK. I copy-and-pasted (more or less) some of the code from other E18 source > > code and was not sure what was needed. I can get rid of unnecessary code. > > > > > > > > > Even though tables are not homogeneous by default, I figure setting that > > > > explicitly documents that they are not homogeneous in the code. And API > > > > defaults sometimes change -- in any case it does not hurt anything. > > > > > > defaults like this never change. it'd break abi. if they do change.. it's > > > a > > > bug. > > > > > > > Still, the explicit setting to be not homogeneous does serve to document > > that > > the table is in fact not homogeneous. In any case it is harmless as well as > > a good way to document the fact. > > well not totally harmless. it does cost extra cycles and does expand the > binary > size by a few bytes... :) but ok - if you want. me - i find reading through > clutter HURTS readability of a codebase. if i have to read pages of "useless > code" to find the bits that actually do something... sure it's just one call. > just trying to help. I am somewhat the opposite -- NOT seeing this sort of 'clutter' means I have to go dig into the documentation to find out what the default is, so having it explicitly set makes is clear right there without having to check. > -- Robert Heller -- 978-544-6933 / [email protected] Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
