Summary:
Move opening for read/write/read-write and error message to internal method
Reuse eet file from Edje instead of opening it again in read-only mode
Add wrapper for eet_close to skip closing if internal file was used
Reviewers: NikaWhite
Subscribers: cedric, jpeg, #eflete
Differential Revision: https://phab.enlightenment.org/D4353
Extend edje edit deberate source API. Add two new API.
- edje_edit_object_color_class_list_get return a list of used color classes for
given object
- edje_edit_color_classes_source_generate is generate code for given
color classes list
This API is annex for edje_edit_object_source_generate. Together this
API's provide a mechanism for generate source for custom groups from
a edj file or more.
Lacking a proper internal tag, I'm using both protected (it is
in fact a protected access function) and beta (to mark as unstable,
not real API).
New smart objects based on EO only should rely on constructor,
finalize and destructor exclusively. In theory, this should be fine.
Unfortunately it may be impossible to inherit from the Efl.Ui.Win
class as it uses a really bad hack and calls super.constructor
inside the finalize method.
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.
Vyacheslav Reutskiy
Vitalii Vorobiov
Andrii Kroitor
Jean-Philippe Andre
junsu choi
Jaehwan Kim
Mykyta Biliavskyi
Carsten Haitzler
Tom Hacohen
Subhransu Mohanty
Jean Guyomarc'h