Omg this was a pain... The code is complete spaghetti and the
fact that the main menu is now in the framespace doesn't help
either. With this patch and the previous one (about ecore_evas_x)
Edi should be able to open correctly at the proper size and with
a visible menu.
This patch introduces a lot of changes so it'll need testing
before we accept it fully.
Fixes T5482
This should fix issues when the main menu is wider than the
window content. This assumes that the menu is horizontal and
aligned with the client content.
The theme should probably handle this case better but right
now I am lost in the spaghetti resizes happening between
edje, elm, evas and X...
I am not very happy with this patch, and I think border.edc
needs some love in order to make it more robust and simpler
to read.
Ref T5482
This affects the legacy content_set/get/unset part APIs. This
should avoid some unwanted ERR messages in case an elm_object_
API is used on an elm widget that doesn't implement said API.
What this does is request the widget for the name of the default
part if NULL was passed in. Since some widgets are not elm_layout,
they have to override the API themselves, which is why I made it
an internal EO API (rather than a series of efl_isa()).
In theory, part should never be NULL when reaching the internal
implementation code in the widgets, at least for content.
In EO, efl_part(obj, NULL) should be invalid.
Ref T5629
Summary:
An else statement was added in 5ebdf8f3 with no clause, resulting in the
bg_solid property becoming conditionalized such that it won't be set
correctly when HAVE_ELEMENTARY_WL2 is defined and there is no wayland
window in use.
Further, this also causes focus to be left undefined. Since there's no
window, presumably it should be turned off in this circumstance.
fix CID1375496, CID1375497
Reviewers: zmike
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4899
windows do not have pointers or cursors under wayland, seats do. due to
lack of multiseat support, most components simply use the "default" seat
with these functions, but this should make the corresponding code more
easily adaptable
the current (v6) xdg-shell spec reads as follows:
Client window decorations should be painted as if the window is
active. Do not assume this means that the window actually has
keyboard or pointer focus.
so this is not equivalent to receiving/losing input focus and should not
be propagated as such
@fix
All windows should be standard, really. Except when using legacy
elm_win_add() or if type_set() was called with a specific type.
I dislike type_set...
Ref T5322
This removes Evas.Modifier_Mask from EO.
This introduces two new types instead:
- Efl.Input.Modifier
- Efl.Input.Lock
Those are enums, not strings, containing all the known and
currently supported lock and modifier keys. The enums are
bit masks.
This effectively removes the ability for an application to
create and handle specific modifier or lock keys - with EO
API (legacy compatibility is unchanged, of course). I wonder
who ever required this?
Note: it seems the EAPI evas_touch_point_list_xy_get() was
lst at some point, as it doesn't appear in the headers anymore.
It looks like we fail to catch an ABI break! abi_checker didn't
catch this!?
Ref T5312
we haven't gotten replies yet on what our position or size should be,
so we should store them so centering works before show but after
resizing is evaluated (that also fixed by forcing an eval).
@fix
the api function requires this, but the unified handler for api+edje handler does
not, since edje singals are deferred and the button which triggered the move
may be released before the signal is processed
ref ea7bbfe47d
@fix
The efl_ui_win overrides _elm_interface_atspi_component_extents_get to give
correct value if screen_coord is EINA_FALSE which means relative position.
The efl_ui_win has given its object geometry value + ecore evas geometry value.
The object geometry value was equal to the ecore evas geometry value, so the
relative position was not correct(twice of ecore evas geometry value).
We have a tag for unstable API, use it. It'll be visible in the
doc and force users to add the macro before being able to compile
code.
This amends d8dd685966.
Small patch to reduce calls to setting opaque/input regions in
wayland. Basically, if the window is not shown then there is no point
in updating these regions until such time that the window is actually
visible and the regions will get committed.
ref T5226
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we are already resetting the pointer object theme when we make a
call to set the cursor, don't set it on window creation. This should
address the issue of animators getting created on window creation.
ref T5209
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Not sure how long this has been broken, but the variable name changed
in this routine to "is_gl_accel"..."is_hw_accel" is no longer used, so
change variable name here to fix compilation with SDL.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Also support both Evas.Image and EO Efl.Canvas.Image classes.
Add a test case in elm_test (under "Icon").
I'm not so happy about this patch... it shows that the API
barrier between legacy and EO implemented for images may not
be such a great idea after all :(
This makes the env var override and the elementary config
global override on accel preference work for not only "gl"
but also advanced configs such as "gl:msaa_high:depth:stencil"
This patch fixes an issue where the wrong wayland window would be
returned from elm_win_wl_window_get. When we lookup a window in
Enlightenment, this function would end up returning the parent window
(if existed) when what we want there is the actual window. This patch
puts the function more in line with the X11 equivalent.
Fixes T5142
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When we mouse_in on a window, the cursor hotspot may need updating for
the new pointer image, so utilize an existing function we already have
which will set the pointer image and calculate updated hotspot. This
patch also uses the same function call in _elm_win_frame_cb_move_stop
in order to reduce duplication.
ref T4987
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch fixes an issue where pointers would occasionally disappear
when running EFL apps in a Wayland compositor. This was occuring
because we would hide the pointer window on mouse_out (and thus attach a NULL
buffer to the pointer surface), but then when we mouse_in again on the
window, it still have a NULL buffer attached to that pointer surface.
This patch fixes the issue.
ref T4987
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As the pointer canvas will already be visible at this point, there is
no need to redo the wl_pointer_set_cursor call as we can just set the
pointer image we desire on the surface (_elm_theme_object_set) and
when the pointer canvas renders, it will have the proper cursor
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we create the pointer After the frame, then we end up setting
elm_object_cursor on the frame object which we do not need so this
patch just slightly modifies the order of things during finalize so
that _elm_win_frame_add does not end up calling
_elm_object_part_cursor_set on the frame object.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This small patch avoids resetting ecore_wl2_window_pointer (and thus
wl_pointer_set_cursor) if the actual pointer canvas is not visible.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we now support xdg_shell version 6 on the client-side, we need to
use the zxdg_toplevel_v6 function call to show window menus.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Elm.Widget.event_callback_add conflicts with Efl.Object.event_callback_add.
To solve this problem, "widget_" prefix is added to methods starting with
"event".
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4521
teamwork api in elm win (efl_ui_win) has a few issues:
1. it directly ddigs into ecore_wl2 and uses internal headers to use
zwp_* api's directly... which effectively tied elementary directly to
libwayland and thats not a good thing - thats why ecore_wl2 exists -
to act as a layer in between
2. the only thing that supports it is e and only wiht a module and
there is no fallback code in elm to work outside this environment, so
it's kind of broken by design and will not actually reliably work
3. from a stability and security point of view, and api and protocol
that allow a client to ask your wm/compositor to open ANY url - go
make a network request possibly to a hostile url/site is bad. needing
to handle so so so so many protocols, file types etc. etc. is going to
lead to issues that SHOULD at least be isolated in the app, but now it
spreads into your wm/compositor too. :(
4. there is ZERO benefit to asking the wm to do this. the app is
using efl already. it already has all the same abilities with the same
libraries to download/display etc. so why doesnt the app do it itself?
5. doesnt work in windows, osx, framebuffer (fbcon or drm)... only in
x11 and wayland. (and then only with e + module)
6. there is no way to detect if it's going to work and write your own
fallback (which shouldnt be needed/done anyway).
nice work and enthusiasm on making teamwork but it just isn't the right
thing - not in its current form and not by design (security reasons) :(
@deprecate
this adds the a stack of windows (view stack, something like naviframe
but using multiple windows instead) to elementary allowing windows to
be put into a stack and treated as one "application" when ijn such a
stack with the newest window on top being the active/focused one (or
should be). this allows for special show/hide animations as well as
possibly special sizing policies and placement policies.
@feature
The frame object requires a theme of version 119 or more. In fact
I think until we are totally happy with the window API (for EO) we
might want to bump that version regularly. That would indeed disallow
theme customization for border.edc until it's done.
This patch uses a pretty brute force way to set the theme file to
the default file from EFL installation. elm_config is not reliable
here.
This is very custom made and there may be a more generic way to force
a widget to use a minimum theme version. Yes that could mean ugly
widgets if we change the theme API but at least that would make them
work. Note that the border theme contains no visual elements, so the
colors of the background, etc... should all depend on the user
selected theme. But of course CSD (in Wayland) will have to use the
default theme -- and look grey.
Fixes D4976
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>
Mike Blumenkrantz
Jean-Philippe Andre
Vincent Torri
Marcel Hollerbach
Bryce Harrington
Carsten Haitzler
Cedric BAIL
Shinwoo Kim
Chris Michael
Jee-Yong Um
Stefan Schmidt
Jean Guyomarc'h
Ji-Youn Park
Daniel Zaoui
Guilherme Iscaro
Tom Hacohen
Vitor Sousa
