widget hierarchy.
Win inherits directly from Elm_Widget_Smart_Class, while inwin is now
an elm layout.
Note that elm_widget_sub_object_list_get(), which was an unecessary
hack only used on win, was killed.
SVN revision: 70717
properly by real widgets.
I'm also creating a *compatibility* class on top of it, which extends
the old (unique) one to its old components, so that everything goes
unnoticed for the widgets.
Next, we'll be accessing class functions for widget hooks *on the base
class*, which will be proxied back to the instance ones.
Then, one by one the widgets will be translated to a proper
hierarchical smart class parentage, making extensibility and reuse
much better.
Last, but not least, since we'll be moving these hooks to the class,
where (almost) everything is a function, let's adapt to the future --
take away the "_func" suffix from them.
NB: there is ONE hook and associated data which was kept on the base,
for now: "show_region" stuff. I did that because scrollers need that
in order to work, right now. Keep in mind, though, the scrollers will
be reworked, so that fields ought to be changed soon, too.
SVN revision: 70704
using elm_widget_focus_direction_go function, focus will be moved from
the current focused object to the near object in one direction.
Direction can be set by degree(for easy usability). Degree changes
clockwise, i.e. 0 means UP, 90 means RIGHT, 180 means DOWN, and 270
means LEFT. You can select any direction by changing this degree.
SVN revision: 70681
widget hierarchy.
Win inherits directly from Elm_Widget_Smart_Class, while inwin is now
an elm layout.
Note that elm_widget_sub_object_list_get(), which was an unecessary
hack only used on win, was killed.
SVN revision: 70640
properly by real widgets.
I'm also creating a *compatibility* class on top of it, which extends
the old (unique) one to its old components, so that everything goes
unnoticed for the widgets.
Next, we'll be accessing class functions for widget hooks *on the base
class*, which will be proxied back to the instance ones.
Then, one by one the widgets will be translated to a proper
hierarchical smart class parentage, making extensibility and reuse
much better.
Last, but not least, since we'll be moving these hooks to the class,
where (almost) everything is a function, let's adapt to the future --
take away the "_func" suffix from them.
NB: there is ONE hook and associated data which was kept on the base,
for now: "show_region" stuff. I did that because scrollers need that
in order to work, right now. Keep in mind, though, the scrollers will
be reworked, so that fields ought to be changed soon, too.
SVN revision: 70627
Current Issue:
Currently when we add a widget to window as a sub-object, e.g.
elm_notify_add(win) which internally calls elm_widget_sub_object_add
then the focus chain using <TAB> includes only
the first focusable subitem of the widget, not all.
Whereas with elm_win_resize_object_add, it works fine and cycles to
all focusable sub-items of the widget.
Reason:
The reason is that we are appending sub-object to the list in
elm_win which is used for focus chain, only in case of
elm_win_resize_object_add.
Change Description:
Added a new API: EAPI Eina_List
*elm_widget_sub_object_list_get(const Evas_Object *obj);
This API returns the list of sub-objects of an elementary widget
(sd->subobjs) where sd is Smart_Data pointer obtainted using
elm_widget_smart_data_get(obj).
We have used this API in elm_win for focus_next_hook implementation.
Signed-Off-By: RAJEEV RANJAN<rajeev.r>@samsumg.com>
SVN revision: 69943
Now it returns the bool value to free the widget item.
Some widget items(i,e genlist) should not be deleted directly when elm_object_item_del is called.
So, if the pre_hook function returns EINA_FALSE, then the widget item will not be deleted.
SVN revision: 67565
auto-formatting scripts and i just spent a long time fixing the
results of one. the actual value of these macros is minimal at best
SVN revision: 66680
Subject: [E-devel] [patch] elm_cnp_helper - make some cnp apis as
public EAPI
As I suggested, I made a patch for some cnp apis.
I think copying and pasting APIs are pretty mature to be public
Those are elm_selection_set, elm_selection_clear, elm_selection_get.
And adding cnp prefix for distinction from word, or char selections.
elm_selection_set --> elm_cnp_selection_set
elm_selection_clear --> elm_cnp_selection_clear
elm_selection_get --> elm_cnp_selection_get
And drag and drop APIs should be remained as private.
It has many flaws.
SVN revision: 66505
Subject: [E-devel] [patch] elm_cnp_helper - bugfix mixing with ecore selection set apis
Date: Tue, 20 Dec 2011 18:57:25 +0900
Dear all
When ecore selection set apis(such as ecore_x_selection_clipboard_set)
used in elementary,
Some data is not pasted to elementary widgets.
It's due to mix ecore selection with elementary selection apis.
Data which by ecore doesn't have TARGETS information,
so elementary make it up with TARGETS Information for copying & pasting.
Thank you.
SVN revision: 66407
Subject: [E-devel] [patch] elm_cnp_helper - add type checking for non-elm cnp datas
Date: Fri, 16 Dec 2011 17:09:37 +0900
Dear developers
elm_cnp_helper supports rich types for copying & pasting.
but it doesn't extend like x11 way.
this patch introduces to reduce mismatch for checking selection type format.
now elm can live in harmony with non-elm cnp datas
Thanks
SVN revision: 66367
First things first, I'm not sure I'm setting the right variable on
the setlocale() call, so someone more knowledgeable can look at it and fix it.
How this works, you say? Just like elm_object_text_part_set(), except now it
will pass the string given through dgettext() with the given domain (NULL
means it uses whatever the app set with textdomain()), and when changing
language with elm_language_set(), it will re-set the strings with a new
translation.
SVN revision: 64179
Gustavo Lima Chaves
WooHyun Jung
Carsten Haitzler
Daniel Juyung Seo
ChunEon Park
Sanjeev BA
Hyoyoung Chang
Mike Blumenkrantz
Iván Briano
Cedric BAIL
Tom Hacohen