As we no longer destroy a window's wl_surface during hide requests, we
should not be setting pointer surface to NULL here.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
It appears that the 'black square' issue when using wayland_egl canvas
for mouse pointers is gone now, so re-enable the usage of gl pointers
for elementary windows.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Avoid calling the engine's size_min_set/size_max_set functions
while setting the hints on the window object itself (it would
cause min != max even though we intended min == max).
E has a habit of creating windows with a single content
that has no weight and/or no min size, but still expecting
those windows to size properly and be resizable. This amends
a previous sizing hack (but really it's the same) for logout
dialogs, and adds another hack for EFM windows (single edje
object with no weight, but window should be resizable).
What happens is that ecore_wl2 ignores calls to opaque_region_set
if the window has alpha. As a consequence the opaque_region is not
updated server-side and the previous window geometry is kept as
opaque region, even though the window should have alpha.
Thanks @raster for the report.
evas_object_size_hint_max() would not work on a window, unless
it somehow managed to not size itself (which would be another
issue). This patch allows apps to call size_hint_max_set() on
a window. A test case is provided in elm_test (Dialog).
@feature
E creates an edje object, sets it as resize_object, calls
restricted_calc and sets the resulting min size to the window.
But the window min size isn't taken into account when sizing
it, as the window sizes itself. I have no idea how this could
work before my changes.
E never actually requested the edje object to update its size
hints, so the window is left with an object of min size 0x0.
This patch is clearly a hack, but I can't really figure out
what would be the best or proper solution. Other elementary
widgets and containers seem to force edje object's update_hints.
Reproduction case: In E, menu, system, logout.
In Wayland, an opaque window can still have shadow borders, and
only needs to set the opaque_region appropriately. In X on the
other hand, a window needs to be flagged as alpha in order to be
properly blended (otherwise you'd get black borders).
Thanks Derek for the report!
This fixes c91360fcbd
After reverting 8a21384759, I figured out how to move
the main menu back to the border group. This time the menu is in the
framespace and its layout algos have been adapted to allow non-zero
root coordinates.
As Andy reported, the main menu geometry is not correct after
my recent changes, as the application contents slide underneath
the menu bar. In fact the menu bar is just floating above
everything else.
So I've tried to move the menu to the framespace (as it should
belong to the frame), but the sizing algos for both the window
and the menu make some assumptions that render this task quite
difficult. Eventually I would like to be able to swallow the
menu somewhere else inside the border... but not right now.
x11 updates trying to update x properties from image data when icon is
not an image is causing lots of error spam. fix this to check type
first before getting data.
My previous patches have broken E Wayland internal windows, as
the compositor wants to create Server-Side Decorations[1] but
based on some mysterious heuristics, E will decide to show or
not SSD. It seems the surface geometry, window geometry,
input region and maybe opaque region need to all match. There
was a pixel difference in the theme which broke everything,
also CSD shadows must be turned off in that case.
This also fixes inputs as for some reason a mismatching input
region vs window geometry would break pointer move/up/down in
those internal windows.
[1] I believe this is not a great idea and E should never draw
any server-side decorations in Wayland. Wayland was supposed
to mean only CSD, no more SSD.
E Wayland internal windows are a special beast. Somehow all their
events are intercepted by a special input_obj... but never get
propagated back to the elm_win.
Major side-effect: you get 2 window decorations. I believe there is
some dark magic inside E that tries to figure out when to show
a decoration and this conflicts with CSD.
But hey, it's late so I want to "fix" this and figure out the details
later.
For standard windows, we want to create an elm_bg object if
the theme is a legacy one. Otherwise the default theme
doesn't require an extra object, just a rectangle.
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.
EAPI elm_win_type_set
EAPI elm_win_name_set
Those two APIs should never have been part of the legacy API,
but they have been generated since at least 1.16. The commits
1aceb3bc19
and
41aa19447c
removed the legacy symbols generation. It seemed like a good
idea since the APIs shouldn't exist, but in fact this broke
ABI. I hate this. So sorry about it.
I'm adding them back in with no documentation and as
EINA_DEPRECATED.
This is an emergency commit before the 1.18.x release
announcement.
Fixes T4344
@fix
alpha
If we have a borderless alpha window, then make call to set opaque
region accordingly. This still avoids calling opaque_region_set twice,
yet maintains opaque region for the above mentioned case.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This removes some useless code in various places, where the
switch from eo_do() to standard function call was not properly
refactored.
This changes:
type ret = 0;
ret = my_eo_function();
return ret;
To:
return my_eo_function();
When we are calculating minimum size hints for the window object, we
should be adding framespace to maximum size, not subtracting it...
Honestly this just looks like a brain-dead typo.
Fixes T44225
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Previously, if the window had no frame object, then this could would
have been setting opaque region twice (for the alpha case). We can
avoid this if we move the alpha check to below the frame check.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This reverts commit fb24955782.
While this patch did fix the issue of toggling window Borderless state
in EFl-Wl client applications, it is "Enlightenment's" stance that it
will not change to match this fix, so this has to be reverted else
internal E dialogs show up with no border (due to them using SSD).
This is going to re-open T4092 sadly :( and now leave that bug with no
possible fix.
ref T4092
Fixes T4126
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Jean-Philippe Andre
Chris Michael
Stefan Schmidt
Carsten Haitzler
Jean Guyomarc'h
Ji-Youn Park
Daniel Zaoui
Shinwoo Kim
Cedric Bail
Marcel Hollerbach
Guilherme Iscaro
Tom Hacohen
Vitor Sousa
Mike Blumenkrantz
