Summary:
On window rotation send bounds changed signal to inform ATSPI client
about the orientation of window
Test Plan:
In ATSPI mode, when orientation of efl window is changed, ATSPI client should
get notification
Reviewers: kimcinoo
Subscribers: cedric, govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D5469
Note: this is C only, not legacy only.
The problem is that bindings will hold a strong reference to the window,
which will then die "under the rug" if autodel is enabled. This then
leads to at least ERR if not crashes.
Note:
elm_policy needs to support autodel and quit on last del only for C
applications. Bindings will require some other mechanism that doesn't
break all assumptions wrt. references.
This will be used to solve issues around style_set:
if the widget is legacy or pure eo we may need to select a different
style. So in the constructor we need to know whether we are legacy or
eo. Note that calling style_set in finalize only is too late as we would
lose information such as efl_text_set() called inside efl_add().
This isn't meant to be installed. The canvas API in EO is based around
the interfaces Efl.Canvas and the widget Efl.Ui.Win. Anything else is
not EO (eg: ecore_evas, evas, ...)
Note: evas_canvas3d is the last remaining thing that is installed along
EO files, but those are all beta APIs.
OMG... I do not like this patch.
See T6148, two key down events are received when a key grab is installed
on a Win object. This is because all input events are propagated from
ecore all the way up to win and can be listened on. Unfortunately this
breaks existing applications that use the key grab API properly to
listen to key events.
Another side effect is that ALL key events are received by the window,
which means it's not limited to what the application expected (from its
list of grabs).
Solution (ugly): block propagation of key down/up events if the window
is a legacy window. This means that no key grab is required for EO
windows, but key grabs are still required for legacy windows.
Fixes T6148
@fix
thats just a little helper, where the logic to find and fetch the
provider is bound to the position in the widget tree, this means that
for example gengrid could change the way the logical parent is
evalulated. (For example to map the logical parent to a item)
Simply pass in the strbuf and don't expect the callee to own it. This
makes things simpler and safer (it'll crash only if the callee frees
said strbuf, and shouldn't leak). efl_ebug_name is new in the upcoming
release, EFL 1.21.
Realised this after talking with Amitesh. Thanks.
See 999dbd9764
And c4769ff898
I kept the safety error message for easier debugging.
Test scenario:
elementary_test -to "Window Inline"
Click on an entry. Press Shift+Tab.
Ping @bu5hm4n
the count ?: 1 check is pointless as count is already checked above.
make it clearer that it's > 0 and remove the ? check. silence for
coverity CID 1380542
Summary:
elm_bg was supposed to be used only in legacy,
but since we need a common object to be used as a background of widgets,
it is now renamed as efl_ui_bg and supports EO APIs.
Reviewers: cedric, jpeg, woohyun
Differential Revision: https://phab.enlightenment.org/D5147
This moves the API entry points from Widget to Layout parts. I don't
think the other widgets support translation, but that is easy to fix.
The actual code implementation remains in elm_widget.c.
Legacy-only widgets are covered by Part_Legacy, while all EO widgets
that have text inherit from Layout (except Win but I don't think the
window title was translatable in legacy).
This removes 2/3 remaining part APIs from Widget.
Ref T5363
This will be used to replace the part translation API in Elm.Widget. It
should work for both parts and non-parts (ie. the main text of a button,
for instance).
For now I'm taking the following approach:
- All efl_text_set/get strings are untranslatable, i.e. get() returns
the visible string, set replaces and can not be translated.
- translatable_text_set/get needs to be used to enable automatic
translation, which in turns calls efl_text_set to modify the visible
string. Thus, translatable applications will have to use
efl_ui_translatable_text_set a lot more than efl_text_set, unless
they translate strings application-side.
Note that some other frameworks take a simpler approach equivalent to
calling efl_text_set() with an already translated text. This prevents
runtime language changes of the application, unless the application
handles them specifically.
pause event means that the window is not visible anymore to any user.
resume is triggered when the window became visible again or just
became visible again.
This means that ALL part handles inherit from the base part class
Efl.Ui.Widget.Part. Layout is the only exception where Efl.Part is
specially overridden.
This is a first step towards generic part APIs, including background in
all widgets.
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
In Edje and Elementary, we have part objects, which are what is returned
by the interface efl_part(). Those objects can't be of an opaque type as
this doesn't work nicely with strongly typed languages such as C++ or
C#. In JS, Lua, C the types are weak and mostly runtime-based so it
doesn't matter much.
As a consequence, the documentation and the types need to look nice in
this EO API. Thus, we remove the abusive term "internal" and explicitly
call all those classes "part" something.
Eventually we want the types to be declared in the EO file so bindings
(C#, C++, ...) can generate the proper access methods, returning the
best possible types.
Note that right now a few of those part types are used in the legacy API
but don't actually need to be exposed externally.
This is kind of a mega commit that does all the renaming at once, but
it's really just a big sed operation. The power of good IDEs :)
Ref T5315
Ref T5306
We needed to do this to prevent burning cpu with animated cursors
before we did frame callback based animating.
Now the compositor will stop our frame callbacks when our cursor
is implicitly visible when the pointer isn't over our window,
so we don't have to use window hides for it.
Note: The distinction is made on how the window was created, not on
which API is used (evas_object_lower or efl_gfx_stack_lower or
elm_win_lower).
Ref T5322
Note: elm_test "Focus Style" can be used to test this API. The test case
is a bit broken (overly complex EDC?) but if you're patient you can see
the difference between "glow" and "glow_effect".
Ref T5363
Ref T5322
This removes the special code in the legacy API for
elm_widget_focus_mouse_up_handle. Add an internal helper to find the
first widget parent. And mark as protected.
Apparently this functions is still required for the new focus manager.
Ref T5363
It's not beta. It's about to die.
Also, move #define ELM_WIDGET_BETA to the common header file, as it is
consequently required by ALL widgets. :(
Ping @bu5hm4n :)
Ref T5363
it turns out that we should also repsect logical elements that are
having a redirect_manager, since they are more at the "end" then a
potential regular node.
The user now needs to handle the logical_end call on this manager, or
handle at all what he wants to do with this information.
efl_ui_win now handles it in the way that it just focuses that logical
node, (which results in the redirect manager beeing set, then calling
again logical_end on that manager. Repeating this until we have finally
found a regular node that does fit out needs.
Renamed to on_disabled_update.
Also passed in the new state of disabled. It's more convenient this way,
than having the subclasses call disabled_get.
Also simplify some code...
Ref T5363
Renamed to on_orientation_update
This internal / virtual function is in fact not overridden anywhere. Not
sure it is necessary to expose it in EO API?
Ref T5363
This backend has received no patch and maintenance from anyone who could
actually test it over the last few years. After talking with KaKaRoTo it
is best to remove it. If anyone want to take over its maintenance, you
are welcome to revert this patch.
Fake: This should never have had the fake_canvas_set API. It already can
not work after efl_finalize. And Ecore_Evas isn't part of EO API so it
doesn't make sense at this point to try to expose the fake window as
part of EO API.
Socket: This is the only type of window that implements socket_listen.
So we can just move this function to a new subclass.
NOTE: Socket & plug are currently broken, even in 1.20 (at least for me)!
Ref T5322
This factorizes the code and makes most widgets handle key down events
in the same way:
- check that the object is not disabled, event is not on hold
- figure out the key binding based on the class name
- mark event as on hold
The class name is usually MY_CLASS_NAME but in some cases it was
MY_CLASS_NAME_LEGACY which may be different from the EO class name (eg.
elm_win vs. Efl.Ui.Win). In that case the key bindings are broken.
This breaks key bindings for the following widgets:
- Win (focus)
- Image ("clicked")
- Video (move, play)
This fixes key bindings for the following widgets:
- Nstate
Some widgets remain broken:
- Photocam / Efl.Ui.Image.Zoomable
A patch will be applied to restore the key bindings for the above
breaks.
This is an internal function that should probably become an overridable
protected method, as it's required for proper event handling in widgets.
Next step: use eo_event_info in the widgets implementations. Then remove
legacy event struct.
Ref T5363
After any complex call on the window, a foreign evas/efl callback may be
triggered that could delete the window object. This leads to crashes in
queued jobs or even immediately after said callback (right now EO
prevents immediate memory free using eina_freeq or eina_trash so the
effects aren't immediate).
Funnily enough, this was a known issue according to some comments, but
no one bothered fixing it...
In this particular instance, a focus_out job was crashing while trying
to access now-invalid sd data.
I believe some uses of ELM_WIN_DATA_GET() may still be slightly unsafe
but most look like they should be the result of an EO call on the object
(eg. a call to efl_event_callback_call), which ensures the object is
alive.
Fixes T5869
it turns out to be very handy to have a interface for the moving and
border elements, that is unconnected to the way of how widgets are
registering themself.
This for example enables us to get a simple focus manager that just
redirects the call into a internal 2 dimensional data struct
forcing a full eval here is unnecessary and broken since such an eval could
either change geometry in unexpected ways or fail to accurately change
the underlying canvas geometry
@fix
Summary:
Implement efl_provider_find function for efl_ui_win class.
This will support to search window class by efl_provider_find function.
Reviewers: jpeg, cedric, Jaehyun_Cho, thiepha, woohyun, Blackmole
Reviewed By: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D5045
This is really only a demonstration of what kind of information
we can print with efl_debug_name_get(). Hopefully this can help
debugging with printf/ERR logs and even help with live debugging
inside gdb.
This shouldn't be used for other purposes than debugging, as the
exact string format is not defined.
@feature
csd attempts to create sw cursors if the pointer surface doesn't exist,
so create the pointer surface before the csd to avoid duplicate cursors
#TheDisappointer
this should be unmapped so edje stops trying to render to it, though
at some point it could be optimized to not hide and just reuse the buffer
when showing again
#IGot99TicketsBut1x1AintOne
On OSX the framespace and CSD (Client-Side Decorations) are not
supported at all... I am not able to test this case. This patch
restores the main menu functionality based on pre 1.19 themes,
where it was located inside win.edc (app content) and not in
border.edc (framespace).
Note that the initial size of a window may be wrong, eg as in
elementary_test -to "Main Menu"
Fixes T5734 (hopefully!)
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.
Cedric Bail
Marcel Hollerbach
Shilpa Singh
Jean-Philippe Andre
Carsten Haitzler
Mike Blumenkrantz
Lukasz Stanislawski
Marcel Hollerbach
Sungtaek Hong
Lukasz Stanislawski
Derek Foreman
Taehyub Kim
Jiyoun Park
Amitesh Singh
Vincent Torri
Bryce Harrington
Shinwoo Kim
Chris Michael
Jee-Yong Um
Stefan Schmidt
Jean Guyomarc'h
