Summary:
Using edc script, there is no way to know evas object is set on swallow part or not.
So, to know that, some elm widget send signal and save some information to edc variables when object is set on swallow part.
I think it is helpful to make better edc script.
@feature
Reviewers: herb, cedric, raster, id213sin, jpeg
Reviewed By: jpeg
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4176
- convert methods to property setter/getter
- remove "values" block when getter returns read_only value
- fit the type of params of eo funcs to those of legacy APIs
The new event info being an eo object, it needs to be properly
cleaned. I believe this memleak would not show up much in massif
or other checking tools, as it's a stringshare leak. Also, most
of those event objects will in fact be reused and never deleted.
@fix (backported as c58e293d34)
it serems some changes broke our buffer age querying - we were using
the wrong symbol... the EXT or ARGB onenot the core one which does
work. use that first. then we get buffer age.
@fix
Summary:
Main trouble in handle click and double click event.
If user hold Esc and do double click on genlist item,
it still highlighted but not selected, because between
click and double click genlist process a key down event.
This patch add check the item state on mouse up, check
a item state - if item highlighted but not selected,
unhighlight it.
@fix
Fixes T3986
Test Plan:
1. run elementary_test Genlist
2. hold ESC
3. double-click on few genlist items
Reviewers: raster, cedric, NikaWhite
Subscribers: seoz, jpeg
Maniphest Tasks: T3986
Differential Revision: https://phab.enlightenment.org/D4222
handle smart member add if the object is invalid withotu crashing.
also don't abort and crash with other invalid states like of smart
object or child is to be deleted, has no layer etc. - continue on
safely without a crash.
@fix
thsi fixes invalid memory access to already freed memory in a parent
call where a child freed it by reference counting the struct to
ensuire it stays alive in the parent func using it.
@fix
so ... Edje_Calc_Params was huge ... like about 200 bytes. every part
in every live edje object got one of these in addtion to real part
struct info etc. ... so really every part was probably consuming
300-500 bytes or so... crazy. so i made a lot of the data now optional
so only the minimum required is allocated now which cuts down about 110
or even 120 bytes per part, depending. 100 bytes was needed for 3d
node parts even though almsot no parts are 3d node parts... the image
and text data was 30-40 bytes so we consumed 100 even if we only used
30-40... so this cuts that done and puts in polace calc param cleanup
funcs everywhere they are needed to clean up this extra allocated data.
i also reduced this even more by maping pointers to req_drag, map and
physics and clip_to fields in another extension struct cutting
down another 28/52 bytes on most parts (in return for an added
4/8 bytes - on 32/64bit accordingly).
in elementary_test this saves about ~300kb of ram for just having the
etst run and displaying (peak memory measuremment). so massif says
10.6M -> 10.3M.
@optimize
fill spread and angle have never been used - resevred intitially for
gradient objects, but never put into use, so remove to get rid of
junk/memory footprint etc.
@optimize
edje was keeping every edje object created in an eina list so it could
access them later. not really great when every list node contains at
least 4 pointers (data, next, prev and accounting, possibly magic
too). also ever time an edje object is deleted it has to remove from
this list which means... walking the list to where the obj is... not
great. replace with an inlist which is just 3 ptrs, no extra pressure
on list pool and removal os O(1) too.
@optimize
Jinyong Park
Jean-Philippe Andre
Jee-Yong Um
Carsten Haitzler
Thiep Ha
Sungmin Kwak
Felipe Magno de Almeida
Daniel Kolesa
Tom Hacohen
Vyacheslav Reutskiy
Jean Guyomarc'h