Thanks to Daniel Willmann pointing them out to me. Actually I wonder
why we need all this define and undef for ENGINE_COMPARE. Will dig a
bit deeper into that and see if we may can go with a single one.
SVN revision: 72144
strncmp() really does not like that. So we should not be lazy and check for it. Say thanks to
scan-build which reported these to me.
SVN revision: 72142
* Move X related window items into their own substruct of
_Elm_Win_Smart_Data to allow grouping based on engine.
* Move X related cursor items into their own substruct of Elm_Cursor
to make supporting cursors on other platforms cleaner.
* Add support for setting the cursor under Wayland:
* Introduce a configure option and #define to as per other engines
* Add always-built API function to allow identification of running
under Wayland (like for X11)
* Call into Ecore to set the cursor when the mouse enters the desired
widget.
SVN revision: 71754
window representation.
The attached change to Elementary makes a small refactor to use
existing code that was already conditional on the Elm engine to
retrieve the underlying window - thus allowing elm_win_xwindow_get to
return 0 in the case when called on a Wayland based Elm window.
Patches have been tested against X11 and Wayland built together by
running elementary_test.
SVN revision: 71455
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
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
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
Subject: [E-devel] [Patch] Ecore, Elementary: Supporting indicator
opacity mode
This is Myoungwoon Roy Kim.
This patches are for supporting the indicator's opacity mode and made by
Jeonhoon Park(jh1979.park@samsung.com) who is responsible for Indicator
application.
Requirements:
- In mobile device, Indicator area should be displayed as Opacity,
Transparency, or sometimes Translucency according to the UX
requirements.
This requirement can be applied in case of fullscreen based menu and
fullscreen applications like video player etc.
Functional requirements:
1. User can set indicator's opacity mode as opacity, transparency, and
translucency
2. User can get the current indicator's opacity mode.
Currently there are no APIs for supporting the upper functional
requirements.
Thus, he added support for indicator's opacity mode.
It is designed for EFL developers easily to set the indicator's opacity
like the existing indicator's mode.
He added a Elm_Win_Indicator_Opacity_Mode structure variable into
Elm_Win
structure.
Meanwhile, new two APIs are implemented independently from the existing
source code.
Anybody please review this and apply it to upstream code.
SVN revision: 68959
Subject: [E-devel] [Patch][elm_win] elm_win_title_set(); can make a
crash with NULL
Have ever try to call elm_win_title_set(win, NULL)? Then try... :-] It
makes "Segmentation Fault".
Yeah, we can add patch in the Ecore side, but we can prevent the
segmentation fault before go inside.
Please check the patch and give any feedbacks. Thanks a lot.
SVN revision: 68154
Carsten Haitzler
Stefan Schmidt
Christopher Michael
Gustavo Lima Chaves
Daniel Juyung Seo
Jihoon Kim
WooHyun Jung
ChunEon Park
Vincent Torri
Jiyoun Park
myoungwoon kim
Daniel Juyung Seo
Doyoun Kang
Cedric BAIL
cnook