Because we were forcing EWAPI in this macro, one couldn't create a class
that is "static" or even just private or the module. The symbol was
always exposed.
Since in C the attributes of a function are set based on the first
declaration, we don't need to specify any attributes in this macro and
we can just rely on them being specified in the declaration. So for
example, for class "foo":
foo.h:
EWAPI const Eo_Class *foo_class_get(...);
foo.c:
const Eo_Class *foo_class_get(...);
Would give the desired results, a class would be EWAPI. This is already
done automatically for all of the classes using Eolian. Because of the
lack of specifiers, the default visibility will now be the default
visibility based on compiler flags and settings.
Thanks to JP for reporting this issue.
This can potentially (but very unlikely) break things.
If we do drag & drop and then do copy & paste, both _wl_selection_receive
and _wl_dnd_receive are called for one action (dnd or cnp). It is reduntdant.
We only need one data received callback to handle two cases dnd and cnp.
We have copy & paste and drag & drop selection types, but we cannot
distinguish between these two types when requesters receive data
from data ready event.
This patch adds a new enum to help selection requesters distinguish
between two selection types and have suitable actions for each type.
If we do drag & drop and then do copy & paste, both _wl_selection_send
and _wl_dnd_send are called for one action (dnd or cnp). It is reduntdant.
We only need one callback to handle two cases dnd and cnp.
we support different types for DnD, but there is no converters.
This patch adds converters for types, so that we can send
different data for different types.
When these changes got it with 0c76f82a31
they used the non existing symbols ecore_promise_value_get and
ecore_promise_then (most likely due to an unfinished refactoring)
Make sure we actually use the correct eina_promise_ symbols and add NULL
for the error callback which is now needed.
partially reverts e4d815dc48
this caused efreetd to crash almost immediately due to non-stringshared
strings being used in a stringshare-only hash data descriptor
This reverts commit b8860c88f5.
i wouldn't call this full of CVE's:
http://www.cvedetails.com/product/3881/Libtiff-Libtiff.html?vendor_id=2224
i do notice various CVE's on libtiff's mailing list have had patches
committed. the CVE db doesn't track if the CVE has been fixed by
upstream (in an easy to find way) and in which version or on what date so
the CVE db simply is all CVE's since the dawn of time that were ever filed.
fixes the following warnings:
/usr/local/include/efl-1/Efl_Model_Common.h:14:30: warning: redefinition of typedef 'Eina_Promise' is a
C11 feature [-Wtypedef-redefinition]
typedef struct _Eina_Promise Eina_Promise;
^
/usr/local/include/eina-1/eina/eina_promise.h:10:30: note: previous definition is here
typedef struct _Eina_Promise Eina_Promise;
To remove the typedef i had to cleanup the includes of header in
evas_canvas3d_eet.c.
this really needs a better solution since it results in a blank genlist
item space, with the item itself typically located somewhere offscreen due
to caching
the parent/group item is located after its child items in the list of items,
so if an item is appended to the parent's list of items then it must be
prepended to the parent or else it will end up being in the wrong group
@fix
more fixes for the comically unreviewed revision from elm which continues
to cause bugs months after it was pushed
ref 4c86a66f28876b68e92a90c8f741eed1130dd034 (elm)
ref e88423e994
Efl - efl_model_base changed to use eina_promise
Eio - eio_model use efl_model_base with promise
Eldbus - elddbus models use promise now
Elementary - elm_view_list and elm_view_form use new models with promise
updated all related examples and tests
This code is an absolute mess. This is the first step towards fixing that.
This cleanup let me find a bug that would have printed errors when using
Eina_Value so I fixed that too.
"elm.swallow.icon" and "elm.swallow.end" of group_index item were not
squrares. So change those swallow parts to be squares like default
item's swallow parts.
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.
This fixes the segfault reported by Jack.
The problem was that the object was being reparented and thus
removed from the composition and never added back.
The hicolor fallback requirement is handled by efreet
and the usage of fdo is user specified now not by code.
This means the only (theoretical) way this could be a
problem is if the user removes a theme.
This seems like a good tradeoff to remove the overhead
and enable the apps to switch icons based on config change.
Allow to delete set if it is not used by any part
Function to check if set is used by any part is:
edje_edit_set_usage_list_get
Since it uses same struct as image_used_list_get function, it
can be freed by edje_edit_image_usage_list_free.
get list of images of set (edje_edit_image_set_images_list_get)
add image to set (edje_edit_image_set_image_add)
delete image from set by it's place (edje_edit_image_set_image_del)