it's important because some tweens of loaded edje group might use image sets
instead of images, so now making edje_edit API to work with them correctly
@fix
In edje_edit_group_copy() for case when save routine is failed
still returned EINA_TRUE. Now will be returned result of save routine.
@fix
CID: 1362727
so edje was allocating 32 pointers per collection. this is per
collection inside an edje file even if we just use one collection from
that edje file. it consumes 32 pointers. on 64bit thats 256 bytes...
just for pointers to mempools so we can "optimize" freeing and
allocation of parts. this was simply rediculous. i moved it to a
sub-struct allocated on demand (so now only for collections we
actually use) and this nuked 400k of "base memory usage youcant get
rid of).
note that our current default theme has something like 1100 or so
images, 1500 or so collections in it. as theme gorws, memory footprint
goes up if we dont allocation only on demand (when needed/used) and we
aren't careful about the size of our data structs and their content.
@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
unswallowing set swallowed_object to NULL inside of
_edje_real_part_swallow_clear
so it is impossible to delete object anymore.
And so, changing sources leaves fantoms and undeleted objects.
@fix
this fixes ordering to match everywhere else ANd usage of the get
func. this was broken already where top/bottom border would swap -
plese see coverity scan CID 1355590 for an example of problems this
created.
this will fix case when aliased group was changed and alias-group was loaded,
so then on saving alias-group WON'T rewrite all changed to aliased group
@fix
this should cut some memory used by edje by using smaller types like
shorts instead of ints where we just dont need a full int range and
short will do, and re-ordering in memory data soit packs better when
accoutning for alignment
Summary:
So currently having an issue related to clip_to function from
EdjeEdit API. I am not sure about how and why combobox use pointer grabbing
(just started to use it) but when setting NULL into clip_to of edje edit it
suddenly block entire screen away from mouse. Only when point is moved out of
window and back, only then it will be able to access widgets again.
Take a look at video and maybe try example to reproduce problem
I am not sure if deleting those functions from edje_edit is actually right
decision. But it will fix the problem of course.
Test Plan: See attached video and examples in attached files
Reviewers: NikaWhite, reutskiy.v.v, Hermet, cedric, raster
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4081
Evas.Common_Interface not only had a bad name, it also
wasn't in line with how we can get a loop object, for
instance.
Use eo_provider_find in each implementing class.
Cedric revert patch 6f7608befd same days
ago.
<quote Cedric>
Your patch 6f7608befd did break elemines
which does relly on the proper index to be given to it. I think
Edje_Edit should be fine and use the index if no name is provided (See
edje_load.c around L1180). In all case this was clearly an ABI break and
needed to be reverted.
</quote Cedric>
So now edje_cc not guarantee name for part items. This is bad, because
edje_edit use item name for access to item attributes. If item have not
name we cann't get it attributes, because edje_edit compare the given
name with part items name from edj-file, strcmp dislake NULL args.
For now I see one way mark all edje_edit_part_item* APIs as deprecated
and add new APIs for manage part items by index.
For clearly and history:
The eason for revert - https://phab.enlightenment.org/D3820
The proposed solution - https://phab.enlightenment.org/D3907
This reverts commit 546ff7bbba.
It seems that eo_del() is useful and removing it was creating bugs.
The issue is that the way we defined parents in eo, both the parent and
the programmer share a reference to the object. When we eo_unref() that
reference as the programmer, eo has no way to know it's this specific
reference we are freeing, and not a general one, so in some
circumstances, for example:
eo_ref(child);
eo_unref(child); // trying to delete here
eo_unref(container); // container is deleted here
eo_unref(child); // child already has 0 refs before this point.
We would have an issue with references and objects being freed too soon
and in general, issue with the references.
Having eo_del() solves that, because this one explicitly unparents if
there is a parent, meaning the reference ownership is explicitly taken
by the programmer.
eo_del() is essentially a convenience function around "check if has
parent, and if so unparent, otherwise, unref". Which should be used when
you want to delete an object although it has a parent, and is equivalent
to eo_unref() when it doesn't have one.
We used to have eo_del() as the mirrored action to eo_add(). No longer,
now you just always eo_unref() to delete an object. This change makes it
so the reference of the parent is shared with the reference the
programmer has. So eo_parent_set(obj, NULL) can free an object, and so
does eo_unref() (even if there is a parent).
This means Eo no longer complains if you have a parent during deletion.
Support inheritance for part states on the edc code generate time.
Only for general attributes are supported, except relative and
map blocks.
Added functions for calculation coefficient of similarity
between two different states of the same part.
Setters and getters like
edje_edit_state_proxy_source_clip_set
edje_edit_state_proxy_source_clip_get
edje_edit_state_proxy_source_visible_set
edje_edit_state_proxy_source_visible_get
Summary:
Writing copy directly to file.
Old way (adding directly to collection cache) leads to possible segfaults
on edje_collection_cache_flush.
Reviewers: reutskiy.v.v, cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3904
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
It is possible situation when SPACER structure has colors values.
For example:
group { name: "abc";
parts {
part { name: "rect"; type: RECT;
description { "default" 0.0;
color: 7 7 7 255;
}
}
}
}
group { name:"abc_2";
inherit: "abc";
parts {
part { name: "rect"; type: SPACER;
}
}
}
To avoid failing compilation of generated source code, need avoid
generate color source code for a SPACER part.