It is not a special object anymore, and does not need special handling.
Just move it to the correct position, since the canvas 0,0 point now has
an offset.
1. Do not need to print the same error message from all the widget codes.
2. Even though elm_widget_sub_object_add() can be used internally, there should be no error message at all.
Elm devs should fix it beforehand.
So it looks ok to print the error message in elm_widget_sub_object_add() to force elm devs to fix it.
3. Got additional code cleanups.
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
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
This patch replaces the ELM_EXTERNAL_MENU environment variable for
ELM_DISABLE_EXTERNAL_MENU, so that the main menu bar always attemps
connecting via D-Bus, if possible.
Patch by: Henrique Dante de Almeida <hdante@profusion.mobi>
SVN revision: 83099
With this patch, the main menu now keeps listening for the app menu
registrar all the time. Whenever it's available, it tries to register
itself. If the registrar exits, the menu switches back to local mode.
Patch by: Henrique Dante de Almeida <hdante@profusion.mobi>
SVN revision: 83098
The layout has two parts, one for placing a menu bar on the window and
the other for placing the actual window contents. The content part is
an Evas box with a custom layout that mimics the standard widget
placement rules inside the window (adapted from resize_objects_eval
and resize_job)
Note: a custom layout was written here, because it's not possible to
use a common stacking layout, since applications do not follow the
stacking rules (they don't use EVAS_HINT_FILL and
evas_object_size_hint_align_set). Maybe, with time, applications
could be changed to use them, so the custom layout may be removed.
Patch by: Henrique Dante de Almeida <hdante@profusion.mobi>
SVN revision: 82957
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
Disabling frame calculation for now, because, in the code, a call
for getting the geometry might return the size with the frame
included, so adding it in the resize call would result in doubling
the frame size.
Patch by: Henrique Dante de Almeida <hdante@profusion.mobi>
SVN revision: 82643
need to run an engine compare before trying to get wayland specific
items (in this case, the ecore_evas window).
NB: Fixes ticket #1992
Signed-off-by: Christopher Michael <cp.michael@samsung.com>
SVN revision: 81369
Subject: Re: Re: Re: [E-devel] [RFC] Virtual desktop window profile
I've attached 4th patch. May the 4th be with you.
ecore patch has been merged with efl and all files are based on r80123.
Thanks & Regards,
Gwanglim
------- Original Message -------
Sender : Daniel Juyung Seo<seojuyung2@gmail.com>
Date : 2012-12-04 01:55 (GMT+09:00)
Title : Re: Re: [E-devel] [RFC] Virtual desktop window profile
It looks ok to me.
Sorry but can you re-generate the patch according to the recent ecore
merge to efl single tree?
Daniel Juyung Seo (SeoZ)
On Thu, Nov 29, 2012 at 12:29 AM, Gwanglim Lee <gl77.lee@samsung.com>
wrote:
Dear Raster and Daniel Juyung Seo,
I've attached 3rd patches and test_config according to your reviews.
These are based on r79782.
[elementary & ecore]
1. "profile,set" -> "profile,changed" - done
2. spaces after EINA_LIST_FOREACH - done
3. variable type - keep
4. author - done
5. removing deprecated marking in patch - done
6. add elm_win_available_profiles_get to test_config for the debugging
purpose - done
7. check whether a given profile is present in an available profiles.
otherwise window profile will be one of the item
in available profiles. - newly added thing to the elm_win
8. merge with EO - done. :(
Any comments would be appreciated.
SVN revision: 80215
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
Elementary based programs composed of widgets and containers. This means
that every widget will be inside a container, or will be the base
container, usually set as a resize object of the window.
Taking advantage of this structure, we can leave the frame area
calculation be done by elementary, not relying anymore on the framespace
available from Evas.
This commit fixes the problems related to the wayland framespace on
Elementary, while the final implementation of the said framespace is not
done yet on Ecore and Evas. Later it can be easily changed to use the
available infrastructure.
SVN revision: 79491
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] Add APIs for floating mode
I added APIs for supporting the floating mode -
elm_win_floating_mode_set, elm_win_floating_mode_get.
The floating mode will be used on mobile environment. For example, if
the video-player window set the floating mode, then e (enlightenment
window manager) changes it's geometry and handles it like a popup.
Please check these APIs and give an advice for me.
SVN revision: 76667
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
the wayland engines).
The focus handler which traps key events needs to listen for
ISO_Left_Tab also (which is what xkb reports for Shift+Tab).
SVN revision: 75618
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
the case of resetting the wayland cursor image. Fixes ticket #1293.
Increase the size of the event rects on the border theme to allow for
easier resizing.
SVN revision: 75313
Basically, we will remove the frame when going into fullscreen, and
readd when we leave fullscreen. When we remove the frame, then during
window redraw the appropriate fullscreen size will be calculated.
This allows proper fullscreening.
SVN revision: 75294
Delete requests where not being called when the frame close button was
pressed. I know this is not the 'ideal' fix (which is why I left
myself a FIXME here), HOWEVER the Ideal fix would mean breaking the
Feature Freeze (and potentially API), so I will wait until freeze is
over for that. For now, this fixes the 'bugger' in a non-instrusive way.
SVN revision: 74946
resizing.
Previously, we only changed the mouse cursor when the border frame was
actually clicked. Now we can change it when the mouse moves over the
border/frame areas (like in X11). This adds a callback from the edc to
know when and where the mouse moves (with respect to the frame border
only). (IE: When the user moves the mouse over the bottom portion of
the border, the edc will let us know and we can change pointer
accordingly).
SVN revision: 74925
Allows setting a trap in elm_win that intercepts calls to
ecore_evas. If there is a trap and the trap returns EINA_FALSE, then
the corresponding call is NOT issued. If it does not exist or returns
EINA_TRUE, then the call is executed.
Enlightenment window manager will set these traps and will call
e_border directly, allowing E17 to use Elementary! A major feature
given e_widgets painful usage.
This should also help integrating into Wayland or even debug.
SVN revision: 74156
Subject: [E-devel] [PATCH] Add frame size when calculating minimized
elm_win size
Hi,
I found frame size including width and height isn't counted in
_elm_win_resize_objects_eval() when calculating minimized elm_window
size.
It is OK for X engine because elementary only draw client area and X
provides widow frame. So both the width and height from
evas_output_framespace_get are 0.
But it cause bug for wayland engine because elementary need draw
window
frame by itself. So real client area size is smaller than window size.
If frame size isn't counted into minimized window size, there isn't
enough client area to layout widgets.
So it is bug for any engine in which elementary draws window frame by
itself. It is the reason of
http://trac.enlightenment.org/e/ticket/1064.
Could you please my attached patch for this issue?
Thanks.
SVN revision: 74049
ecore_evas_window_get with a replacement function that checks the
currently used engine first. This fixes a segfault when running elm
with the wayland engines.
SVN revision: 73568
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
application can use ecore extn socket easyily
by using elm_window_add with ELM_WIN_SOCKET_IMAGE style.
And new widget Elm plug is similar with Elm image.
it can show socket's image using connect API.
I add test code also(test_win_socket/plug).
SVN revision: 67245
Cedric Bail
Daniel Juyung Seo
Daniel Zaoui
Rafael Antognolli
Carsten Haitzler
Shinwoo Kim
Daniel Juyung Seo
Rafael Antognolli
WooHyun Jung
Tom Hacohen
ChunEon Park
ChunEon Park
Mike Blumenkrantz
Mike McCormack
U. Artie Eoff
Henrique Dante de Almeida
Shinwoo Kim
Flavio Vinicius Alvares Ceolin
Christopher Michael
Cedric BAIL
Gwanglim Lee
Stefan Schmidt
Yakov Goldberg
Rafael Antognolli
Jiyoun Park
Eduardo Lima (Etrunko)
Jihoon Kim
Doyoun Kang
Christopher Michael
Eduardo de Barros Lima
Gustavo Sverzut Barbieri
yan.wang
Gustavo Lima Chaves
WooHyun Jung
Vincent Torri
myoungwoon kim
Daniel Juyung Seo
cnook
Michael BOUCHAUD