The interface efl_part_get should not be directly called from C, but the efl_part
wrapper should. It rely on efl_noref to properly destroy the object. Binding can
control the lifecycle of the reference the way they want by either calling the
wrapper or efl_part_get directly. It also means that the ugly ___efl_auto_unref_set
doesn't need to be exposed outside of EFL anymore.
Differential Revision: https://phab.enlightenment.org/D6098
Summary:
ensure that a resize eval occurs after the frame edje has been thawed
so that sizing will be correct in engines which either still have
broken size handling (D6019) or have sub-optimal size handling (D6145)
Reviewers: bu5hm4n, cedric
Reviewed By: bu5hm4n
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6165
Summary:
The mixin encapsulates the correct
- creation
- composition attaching
- Lifecycle handling
of the focus managers that are assosiated with the object.
This fixes error messages on shutdown, and additionally lifetime issues
where the composite_attached object was deleted before the object was
deleted.
Reviewers: cedric, zmike
Reviewed By: zmike
Subscribers: segfaultxavi, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6108
Summary:
In wayland we need to know which seat initiated the CSD compositor move
request to properly handle input.
Depends on D6124
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6125
Summary:
These ecore_evas_wayland things seem like they shouldn't exist. The
ecore_wl2 api is better and still in beta so it can be fixed when it's
shown to be broken/wrong as the ecore_evas_wayland ones are. :(
The move API is stuck with x, y co-ordinates that can never make sense,
and neither API is capable of passing seat info.
Depends on D6123
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6124
Summary:
This is only fired to trigger a cursor set under wayland, but that cursor
set should be done unconditionally on mouse in.
However, mouse in was being discarded because mouse out was being deferred
when the window was "grabbed" for moving.
If instead we just let the mouse out occur as it should, the cursor
is properly updated on mouse in.
Depends on D6118
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6119
Summary:
in many cases, a 0x0 size is found here as a result of various quirks at
different states of window initialization. passing 0x0 will clamp the size
to 1x1 and, for some engines, create a race condition during initial
sizing which causes the window not to render
ref T6907
Reviewers: cedric, ManMower, vtorri
Reviewed By: vtorri
Subscribers: raster, stefan_schmidt
Tags: #efl
Maniphest Tasks: T6907
Differential Revision: https://phab.enlightenment.org/D6016
Summary: remove the elm legacy name of efl ui theme
Test Plan: run elementary_test and test efl ui widget cases
Reviewers: Jaehyun_Cho, woohyun, cedric, raster, jpeg
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5934
Summary:
the win has no theme set, so this would always return null
Depends on D5956
Reviewers: cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D5957
there were some cases where frame geometry was being calculated/applied
strangely as a result of moving all of the layout calcs to pre-render.
enforcing a frame calc+resize resolves these issues
Differential Revision: https://phab.enlightenment.org/D5961
this should just be handled in the pre-render callback where the rest
of the calc for the window is done
also removes an unnecessary smart calc
Differential Revision: https://phab.enlightenment.org/D5960
this avoids a substantial number of unnecessary recalcs and halves the calltime
for elm_win_add
ref T6884
Differential Revision: https://phab.enlightenment.org/D5944
This only really makes sense on X11 and can lead to some seriously
confusing cases on other engines (*cough* wayland) when elm's idea
of iconified state doesn't match the compositor's.
While currently only X11 is whitelisted, other backends can be
added, though I suspect most are more like wayland where it makes
no sense at all.
ref T6834
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
Summary:
Win is root of focus manager. it means Win is logical node and "focused" and
"unfocused" signals in Win aren't handled by focus manager.
Win needs to emit the signals itself.
Reported by eagleeye, jsuya
Test Plan:
1. elementary_test -to 'window states'
2. Check that "WIN FOCUS: focused" and "WIN FOCUS: unfocused" printed.
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: jsuya, cedric, eagleeye
Differential Revision: https://phab.enlightenment.org/D5931
When changing cursors under wayland sometimes we'll see the old cursor
moved to the new hotspot briefly before the cursor changes. This makes
that suck less often.
A proper fix would involve creating a new wayland surface for every
cursor change (actual change, not just a new frame of an animated
cursor). Given the current internals this is invasive. Do the
easy thing for now.
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
also implement Efl_Canvas.objects_at_xy_get
note that any function which returns an iterator cannot be @const since
it's necessary to wref the object to ensure the iterator's lifetime
Cedric BAIL
Mike Blumenkrantz
Marcel Hollerbach
Derek Foreman
Chris Michael
Jaehyun Cho
Taehyub Kim
Xavi Artigas
Daniel Kolesa
YeongJong Lee
Carsten Haitzler