Hi guys.
Here is my solution for #113 ticket request. This allows to transfer a
gadget to different locations. In short,
- any module can register arbitrary number of locations by invoking
e_gadcon_location_register().
- module is responsible to provide 2 functions, one for removing
particular gadget and one to add particular gadget class.
- module responsible to equip its gadcon(s) with reference to registered
location. If a gadcon contains non-NULL location reference, each gadget
contained by this gadcon can have submenu on its context menu. Template
function for constructing such submenu is provided
e_gadcon_client_add_location_menu. Gadgets can be moved from and to this
location by invoking menu items. Gadcons with NULL location reference
can accept transferred gadgets by module logic but can't send contained
gadgets to another module.
- module responsible to unregister location when gadcon is no more
available.
- menu items for context submenu is sorted by E_GADCON_SITE_XXX assigned
to that. Module can assign and change an icon for context menu item
corresponding to its location(s).
- Currently only shelves and gadman (desktop) used in gadget transfer
operations. I believe it is no trouble to ivolve any other
gadcon-capable module into the process. If you want to have that, please
just let me know.
Here the patch in attachmet. It even works, at least sometimes and at
least for me. Hope you'll find it useful.
SVN revision: 42121
Whitespace Removal.
Fetch the windows evas once instead of multiple calls to e_win_evas_get.
Use E_FREE to free the config dialog structure.
Make sure the window is centered when switching between Basic & Advanced.
SVN revision: 41931
- Hide eina_list internals by using eina macros
- Cleanup some duplicate code
Patches slightly modified for formatting & whitespace removal.
Use eina_list internal macros in some places that were missed.
SVN revision: 41518
This nasty bug was more evident with dialog reuse on configuration
Basic/Advanced toggle, on some resolutions like 1280x1024 it was
always reprodutible.
The problem spotted by Manio is that the dialog contents is resized
but the window is not. The bug follow is:
* window is at some given size (640x512)
* user toggles contents, calls e_dialog_show()
* bg_object (window contents) is resized to MIN (!!!)
* e_win_resize is called with MIN (so far, so good)
* something calls e_util_win_auto_resize_fill(), size is back to 640x512
* _e_border_eval() resizes to the last value 640x512, it's unchanged
so _ecore_evas_x_resize() checks for size being the same and ignore,
not even callking back fn_resize (user callback, _e_dialog_cb_resize).
* window is at 640x512, while bg_object is at MIN, BUG!
One solution is to never change bg_object from outside
_e_dialog_cb_resize, like it's after this patch. The other is to
always call fn_resize even if it did not changed, which could lead to
lots of useless work.
By: manio
Confirmed: barbieri
SVN revision: 41515
Use E_FREE for things created with E_NEW.
Add new function to clear the toolbar.
Add new function to return the number of the selected item.
SVN revision: 41501
We should just set E_CONF_PROFILE from command line option or e_config
startup if we did not had this set before. This is because
ecore_app_restart() will use the same parameters and profile will be
there yet.
SVN revision: 41500
Christopher Michael
victor
Iván Briano
Hannes Janetzek
Carsten Haitzler
Cedric BAIL
Gustavo Sverzut Barbieri