This fixes compatibility with legacy themes (ie. every single
theme in existence beyond the default one, for now), by checking
where to swallow the menu widget. If a legacy theme is used,
the legacy swallow should be used, and it will all look correct.
Moving forward I hope to get rid of the internal edje object
entirely, except for compatibility reasons.
This simplifies the cases by adding a border edje on all
windows except fake (damn fake windows). Shadows and borders
are always disabled on such windows (but we could easily change
that in the future).
The idea is to not have resize object in a stack anymore,
but a couple of swallows in the frame and if the stack of
resize objects is wanted, then the user can still explicitely
create it.
All windows, except for fake, inline & socket images,
should have a frame object to handle all the new APIs and
slots (background, content, indicator, etc...).
The theme will need to handle various modes:
- full CSD
- solid CSD without shadows
- server-side decoration (borderless without shadows)
- borderless with shadows
This means that the default theme must be used for windows,
so that the required edc parts exist. Apart from the standard
background, it is very unlikely that a theme will have changed
anything in win.edc, conformant.edc or border.edc.
This might prove a controversial move, but the alternative would
be to have increasingly complex code handling new themes with
a single edje object and older themes by swallowing tons of
components magically.
Eventually, the win edje object should also not be used anymore.
By default, windows should not have CSD enabled, except on Wayland.
This patch does not handle frame_obj with server-side decorations
yet.
Use Efl.Part for window to manipulate the background.
Two part names are used in EDC:
- elm.rect.background
- elm.swallow.background
For apps the part name is only "background".
To set a solid color background (alpha is ok):
efl_gfx_color_set(efl_part(win, "background"), r, g, b, a);
To set an image:
efl_file_set(efl_part(win, "background"), "image.jpg", NULL);
To set an object:
efl_content_set(efl_part(win, "background"), subobj);
The solid bg is invisible by default, will become visible and use
COPY render mode if a color is set. Standard window uses the
swallow part.
@feature
This is for client-side decorations on Xorg.
Mouse-based move and resize of the window now work fine, but
there are still a few glitches:
1- GL resize is awful (nothing much we can do)
2- Move/resize requests trigger a focus out event,
this in turn changes the style of the window from focussed to
unfocussed. This is thus different from what we see in Wayland
(no focus state change at all) and in usual X11 (focus changes,
but the frame keeps its focussed style).
To counteract this effect, we prevent the frame from changing
style on focus,out if we know we are moving or resizing. But
we don't know that if the compositor moves/resizes (eg. with
Alt key); The focus event happens too early, before the move
or resize events. At least in E.
The result of this API can only guarantee that the request has been forwared to the server,
In fact, there is no guarantee that the request can be processed by the server.
In order to use this API correctly, avoid the following conditions.
(The following situations will return a failure)
1. Calling a function in the absence of a touch(mouse) down event.
2. Calling the function twice more than once before the touch(mouse) up event.
3. Calling the function when the elm win already resizing or moving the window.
4. Calling the function using a combination of unsupported modes.
Right usage
1. touch(mouse) down event
2. efl_ui_win_move_resize_start only once using the supported mode combination.
3. touch(mouse) up event
If a touch(mouse) up event occurs after calling the function, it automatically ends the window move and resize operation.
Since there are some non-exclusive modes, you can use a combination of modes.(ELM_WIN_MOVE_RESIZE_MOVE is exclusive with others)
However, Some combination of mode is limited for technical reasons.
At present, only the following nine combinations are allowed.
For more information, see the Elm.Win.Move_Resize_Mode.
1. EFL_UI_WIN_MOVE_RESIZE_MOVE
2. EFL_UI_WIN_MOVE_RESIZE_TOP
3. EFL_UI_WIN_MOVE_RESIZE_BOTTOM
4. EFL_UI_WIN_MOVE_RESIZE_LEFT
5. EFL_UI_WIN_MOVE_RESIZE_RIGHT
6. EFL_UI_WIN_MOVE_RESIZE_TOP | EFL_UI_WIN_MOVE_RESIZE_LEFT
7. EFL_UI_WIN_MOVE_RESIZE_TOP | EFL_UI_WIN_MOVE_RESIZE_RIGHT
8. EFL_UI_WIN_MOVE_RESIZE_BOTTOM | EFL_UI_WIN_MOVE_RESIZE_LEFT
9. EFL_UI_WIN_MOVE_RESIZE_BOTTOM | EFL_UI_WIN_MOVE_RESIZE_RIGHT
During window deletion, decreasing modality depends on
the window visibility.
Because the visibility was set to false before treating the
modality, it was never decreased, leading to never have still
existing windows being reachable.
Now, we check window visibility before it is modified.
@fix
After a few patches trying to fix clipping of frame or
non-frame objects the icon finally ended up invisible. Even
if the elm_icon was marked as is_frame, its internal evas
object image would not have the flag set, thus it would be
clipped out.
Solution: Propagate the is_frame flag to all smart children,
not only when setting it but also when adding new members.
A hack with the API indicates that the frame edje is a very
special object that does not propagate the flag.
See also:
7ce79be1a10f6c33eff19c9c8809a7ac5ca9281c
Summary:
The accessible name is char*, this could confuse API user.
If we provide user callback to get description, an user would return allocated string.
The usage of elm_interface_atspi_description_get/set should be same with elm_interface_atspi_name_get/set
Reviewers: lukasz.stanislawski, cedric, raster
Reviewed By: raster
Subscribers: stanluk, jpeg
Differential Revision: https://phab.enlightenment.org/D4378
There seem to be an issue with the ecore_evas_wayland_egl engine when
using them for cursors. The issue is that a black square shows up
behind the mouse pointer. This does not happen with the wayland_shm
engine so use wayland_shm engine for mouse pointers (for now) until
this can be sorted out.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Add an internal elm function we can call from withint els_cursor.c so
that we can set window cursor/pointer images based on what is supplied
by els_cursor.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This fixes an issue where build would be broken if not building with
Wayland support.
Fixes T4778
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As most (if not all) compositors will draw their own "move" cursor
when moving windows around, there's no real need to set this one
client side.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we only want to show our custom EFL cursors when the mouse is
actually inside the window, use the _elm_win_mouse_in/out functions to
control pointer visibility.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we don't need a pointer or pointer canvas for
ELM_WIN_INLINED_IMAGE, add missing type check and skip creating
pointer canvas there.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As under the drm engine a softcursor will be created, but not a
pointer canvas, we need to use separate if checks in certain places
like showing, hiding the mouse pointer/canvas.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we are running Wayland clients which create their own mouse
pointers, then we need to remove the mouse pointer ecore_evas when the
window is deleted else we get crashes because the mouse pointer is
still trying to render. This fixes the issue of internal Enlightenment
windows causing crashes when closed.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch implements support for EFL Wayland applications to be able
to use EFL mouse pointers instead of ugly X cursors inside a Wayland
compositor. This does Not use Softcursor so the mouse pointer becomes
it's own surface which is then sent to wl_pointer.
NB: Some small hiccups when using wayland_shm such as dropped frames.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we are using softcursor mode during intercept show, then we should
check that the pointer is actually in the canvas before showing it
else we end up with mouse pointers drawn on the canvas even when the
mouse itself is nowhere near a window.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we don't have the sd->pointer.obj here, then there is no need to
try and set the edje theme for it.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This commit allows EFL wayland client applications to make use of EFL
mouse pointers instead of the wayland-cursor provided ones.
NB: There are still some minor hiccups with this (move pointer does
not change, mouse pointer getting clipped off when on the lower
border, etc) but those will get sorted out soon.
Feature request by the old man ;)
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This is an override of efl_gfx_size_set. Same as before, the
order of operations matter so it is possible that a corner
case will break. In particular, legacy code was:
- intercept
- smart resize (do stuff), super, super, super
- evas object resize
The new code is more like:
- intercept
- super, super, super, evas object resize
- do stuff
But unfortunately this broke elm_widget (read: all widgets) as
the internal resize was done before the object resize. So,
inside the resize event cb, the resize_obj size would not match
the smart object size. >_<
This is an override of efl_gfx_position_set.
As for the other patches, I hope I didn't break anything.
A problem likely to happen is that the super call was inserted
too early or too late in the call flow. For instance:
_myclass_position_set(obj, x, y) {
position_set(super(obj), x, y);
position_get(obj, &prevx, &prevy);
do_something_with_delta_xy();
}
The above code flow is obvisouly wrong, but may have crept in this
patch (such a bug sneaked in inside smart object, breaking
everything at first).
These should be just overrides of Efl.Gfx.visible.set. Many
widgets were handling smart show() and hide() manually, which
means this patch is quite large.
Hopefully this doesn't break anything, obviously. But here are
some widgets known to be problematic, as the old code flow was
really strange (sometimes not calling the efl_super function):
- window
- notify
It has been discussed on the ML (thread: "[RFC] rename efl_self") and
IRC, and has been decided we should rename it to this in order to avoid
confusion with the already established meaning of self which is very
similar to what we were using it for, but didn't have complete overlap.
Kudos to Marcel Hollerbach for initiating the discussion and
fighting for it until he convinced a significant mass. :)
This commit breaks API, and depending on compiler potentially ABI.
@feature
This combines evas canvas functions to list and query
touch points into a single iterator:
- evas_touch_point_list_count
- evas_touch_point_list_nth_xy_get
- evas_touch_point_list_nth_id_get
- evas_touch_point_list_nth_state_get
This also fixes a number of issues related to feeding fake
input events.
Note: I wanted to add delta x,y information as well but it's
in fact not really possible outside the event callback itself,
as the previous x,y position will not be updated unless there's
an event.
@feature
Those two properties aren't related to a "drawing" canvas
but to the current state of input.
Note: both Efl.Input.Pointer (pointer input event data) and
Efl.Input.Interface (common interface for input handling objects)
expose a pointer position API. Not sure what to do about that.
enventor exhibits this issue, where the focus target is
NULL in some cases. The ERR message was harmless, but it's
good to avoid it and be explicit that the object should be
non NULL when adding event callbacks.
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
pointer.
Create the method Efl.Object.event_callback_legacy_call to inherit the old
behavior from Efl.Object.event_callback_call, calling both Efl.Object events
and legacy smart callbacks.
Update all other files accordingly in order to still supply legacy
callbacks while they are necessary.
This simply avoids calling functions on NULL objects, since
the previous patch would ERR out rather than silently ignore
the problem.
I just add explicit NULL checks before calling the functions,
so it's clear the object could be NULL (in the widget).
This removes:
Efl.Event interface
And renames:
Efl.Event.Input -> Efl.Input.Event
Efl.Event -> Efl.Input.Event (merged)
Efl.Event.Pointer -> Efl.Input.Pointer
Efl.Event.Key -> Efl.Input.Key
Efl.Event.Hold -> Efl.Input.Hold
This also moves some interfaces from efl/ to evas/ where they
belong better.
This allows renaming Eo_Event to Efl_Event.
Jean-Philippe Andre
Ji-Youn Park
Daniel Zaoui
Shinwoo Kim
Chris Michael
Carsten Haitzler
Cedric Bail
Marcel Hollerbach
Guilherme Iscaro
Tom Hacohen
Vitor Sousa