wrong, and internally it didnt handle mime types properly. no one
really used/tested this much... because it wasnt available for use
really :). so fix up.
SVN revision: 84103
now if applying the orientation style is failed, it tries to apply the original style. if it fails again then default theme.
also it fixed a logic error when theme changed is happened.
It will try to apply the original style if the orientation style is invalid on theme changing.
SVN revision: 84082
let elm_wdg_orientation_set() have return value and call the elm_wdg_theme() inside.
since every widgets tend to do same task with smart_theme() when it's orient mode is changed.
SVN revision: 83981
Orientation Mode is used for widgets to change it's styles or to send signals
whenever it's window degree is changed. If the orientation mode is enabled
and the widget has different looks and styles for the window degree(0, 90,
180, 270), it will apply a style that is readied for the current degree,
otherwise, it will send signals to it's own edje to change it's any states if
the style doesn't be readied.
SVN revision: 83880
so new object would be highlighted if there is new object under the previous mouse(cursor) position.
to fix this issue, elm_access is using the mouse_event_enable flag. but it would cause a problem as
following case: 1. create input window in access module, 2. read something, 3. disable access module
this would be resolved by export api to set mouse_event_enable flag the other day.
SVN revision: 82933
- elm_access_object_item_register(); -> elm_object_item_access_register();
- elm_access_content_cb_set(); -> elm_access_info_cb_set(); The content would be considered as an evas object.
- elm_access_text_set(); -> elm_access_info_set();
SVN revision: 82791
+ elm_access_object_register();
+ elm_access_object_unregister();
+ elm_access_text_set();
+ elm_access_text_get();
+ elm_access_cb_set();
These APIs are to use edje part, evas object as an accessible object.
and do not create access object, because access object would be created at run time.
This is different with internal API _elm_access_object_register();
SVN revision: 81659
i would like to export an API which name is elm_access_external_info_set(Evas_Object *, const char*);
this will be using by application side to set additional accessibility information.
widget could have different information which could be different in another context.
for example: there would be an entry which is for user ID, and there would be another entry which is for password.
in this case, developer would like to add additional information for each entry as below.
entry for user id reads "entry (default information), this entry is for user id (additional information)"
entry for password reads "entry, this entry is for password"
for this reason, i have attached patch. please review the patch and give feedbacks.
SVN revision: 80339
1. _elm_access_item_register(); please use _elm_access_widget_item_register();
2. _elm_access_item_unregister(); please use _elm_access_widget_item_unregister();
3. Elm_Access_Info of Elm_Widget_Item, because Elm_Widget_Item uses elm_access object which has Elm_Access_Info.
SVN revision: 80063
The prefs widgets aims to aid with the implementation of
preference/configuration windows/UI elements in Elementary-based
applications (think of Enlightenment configuration dialogs,
elementary_config, etc).
Prefs is a widget that populates its view with widgets
bound to data types (following the instructions of a ".epb" file that
describes a set of items) and handles the storage/restoration of such
data on a configuration file automatically.
There's also the prefs_data handle, which is the one dealing with
user saved data for a given epb defaults set.
The documentation on the new widget is rich (we have examples and even
an EPC reference) and there's a new test entry for it.
I'm blogging about it soon, with screeshots and more details.
Enjoy.
ps.: This is a team work by Murilo Belluzzo, Ricardo de Almeida and me.
SVN revision: 79909
1. add access lines for ECORE_X_ATOM_E_ILLUME_ACCESS_ACTION_READ
2. add _elm_access_highlight_cycle(); becase there is a case that
highlight object would be different with focused object after
user moves finger to specific object which does not have focus
currently.
SVN revision: 79884
1. add smart_activate(); to access object.
2. add an API _elm_access_activate_callback_set();
- this callback is called when user wants to activate access object
which would represent widget item or edje part object.
3. add owner referece to the Elm_Access_Info for access object.
4. clock: use _elm_access_activate_callback_set();
SVN revision: 79199
Subject: [E-devel] [patch][elementary] access - activate widget
Subject: [E-devel] [Patch][elementary] scroller, slider - access
activate feature
the previous activate function just get object only. to activate scroller
or slider etc.. it needs more information. so the patch changed previous
activate(Evas_Object *obj) to activate(Evas_Object *obj, Elm_Activate act);
the Elm_Activate can be one of ELM_ACTIVATE_DEFAULT, UP, DOWN, RIGHT, and
LEFT.. you can add more if it is necessary.
I have attached two patches. one is for the slider and the other is for the
scoller.
this patch would support those who wants change value of slider or content
position of scroller on remote side.
this would be useful to the access side or voice control side also.
SVN revision: 76717
Subject: [E-devel] [patch][elementary] calendar - add access feature,
access - add _elm_access_edje_object_part_object_unregister();
the attachment has accessibility feature which is for the
elm_calendar. and
moreover..
it would be better to keep one more api for the access which name is
_elm_access_edje_object_part_object_unregister();
in the case of calendar item, its text part could be set with empty
value
in run time(dynamically), even though it had a value (1~31) previously.
so if there is an empty field(item), then previously registered item
should
be unregistered. the api would be useful not only this case but also
others.
then, please review the patch and give feedback. thanks.
SVN revision: 76502
Subject: [E-devel] [patch][elementary] access - add activate callback
till now, accessibility has used ecore_x_mouse_*_send(). the patch has
activate callback which takes place of the ecore_x_mouse_*_send() stuff.
if the access module is enabled and 'double tap' is detected, elm_win
will
receive ECORE_X_ATOM_E_ILLUME_ACCESS_CONTROL message with
ECORE_X_ATOME_E_ILLUME_ACCESS_ACTION_ACTIVATE and call the activate
callback for the accessibility. that's it.
SVN revision: 75978
hooks.
The former is now issued for all scrollables, with the behavior it had
before, and the latter is a new virtual base function, with a default
implementation leading to values matching the old case where one
didn't implement the hook.
Please help me test if everything is OK -- it seems so, here.
SVN revision: 75904
Subject: [E-devel] [patch][elementary] * access *
Series of of pathes from kim shinwoo. looked good to me - so in they
go, finishing off some more access mode to be more complete.
SVN revision: 75415
NOTE: This improve calendar performance quite a lot, but a better improvement
would be to populate the object when we really need it. I don't know how to
do that in current Elementary source code. Reason for another expected massive
improvement is that every time you set a property on an Elm_Calendar trigger
a populate and that one is costly (Around 6 populates call per Elm_Calendar in
our code example, meaning doing it could give us a 6 times boost...).
SVN revision: 74553
widgets.
Some of them have initting code using the parent ptr for some logic.
Now there's a new idiom on instantiating widgets which adresses
that. It'll be used for all widgets from now on.
SVN revision: 74147
Subject: Re: [E-devel] [Patch][layout] select layout in access mode
I revised the patch which has the way to get the state of
accessibility now. elm_layout_edje_object_can_access_set/get().
SVN revision: 73393
This is meant to be used for all widgets implementing scrolling views.
An Elementary interface adds a given behaviour to whichever widget,
from any class.
SVN revision: 73307
last to be evaluated.
Porting of the basic scrolling infra to an interface will happenfirst, as well as the scrolling widgets porting.
Patch by: Gustavo Lima Chaves <glima@profusion.mobi>
SVN revision: 73306
Subject: [E-devel] [Patch][elm_widget] access hook
Real time setting would be necessary in case of running applications
which
have elm_layout or elm_widget_item.
If the access mode does not care of this, running applications should
restart. The attached for this. Please review the patch and give any
feedbacks. Thanks.
SVN revision: 73229
Subject: [E-devel] [Patch][elementary] elm_access, use widget_item in
focus chain
It has been possible to use widget_item in access mode. The mouse-in
event
makes the widget_item speak.
But focus chain is not useful in access mode, because the widget_item
cannot get the focus as the edje object.
The accessibility highlight will move by keeping the attached patch
and you
can hear the sound of widget item information.
Please review the patch and give some feedbacks. There would be further
works such as dynamic setting focus next hook,
the previous _elm_access_list_register();, but please keep this first if
there is no big trouble. I'll do those also. Thanks.
SVN revision: 73074
The Makefile rule building that is commented out -- meant to be run
locally once in a while (when changes on overall widget tree happen)
and changed images commited.
SVN revision: 71721
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
Carsten Haitzler
ChunEon Park
Shinwoo Kim
Daniel Juyung Seo
Daniel Zaoui
Cedric BAIL
Gustavo Lima Chaves
Yakov Goldberg
Jiyoun Park
Gustavo Sverzut Barbieri
WooHyun Jung
Sanjeev BA
Hyoyoung Chang
Mike Blumenkrantz
Iván Briano
