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
Jean-Philippe Andre
Chris Michael
Stefan Schmidt
Carsten Haitzler
Jean Guyomarc'h
Ji-Youn Park
Daniel Zaoui
