path: root/src/lib/eo (follow)
AgeCommit message (Collapse)Author
2015-06-11Eo: Add Null checkThiep Ha
Summary: Add Null checking when allocate memory. Reviewers: cedric, tasn Reviewed By: tasn Subscribers: cedric Differential Revision:
2015-06-05eo: move some eo files to new doc syntaxDaniel Kolesa
2015-06-01Efl File: Add Eina.File eolian type and use it.Tom Hacohen
2015-06-01Eo types: Fix Eina.Rectangle's namespace.Tom Hacohen
2015-06-01Eo types: Fix Eina.Stringshare's namespace.Tom Hacohen
2015-05-29Efl gfx shape: Use correct class names in .eo file.Tom Hacohen
2015-05-29eolian: "generic_value" builtin typeDaniel Kolesa
2015-05-29Eo: Add eina_types.eot for general types.Tom Hacohen
2015-05-29Eo base: move type definitions into eo_base.eo.Tom Hacohen
2015-05-28Eo base: Remove the free_func parameter from key_data_set.Tom Hacohen
This was not really useful and against the Eolian guidelines. While I promised I won't break things until the 27th, I was ill (still am), so I'm giving myself a 1 day pass. :P
2015-05-28Eo base: Fix Eolian files to use Eo.Base instead of Eo.Tom Hacohen
Eo is not a known Eolian type, we should only be using the class names.
2015-05-28Eo: rename conflicting internal Eo_Base to Eo_HeaderTom Hacohen
This name conflicts with the class Eo.Base and should have been called Eo_Header from the start anyway.
2015-05-21Eo: Fix typo in error message.Tom Hacohen
Thanjs to q66 for reporting.
2015-05-20Eo: Better handle object cleanup on failure.Tom Hacohen
While unrefing twice works, it's cleaner to unref the ref we have and delete normally. It will handle parnet detachments in a nicer way, and is just more correct.
2015-05-20Eo: Remove eo_error_set() and clean up finalizer()Tom Hacohen
This is another cleanup in perparation for the Eo stable release. This is no longer needed thanks to the proper error reporting with eo_constructor()'s new return value. The finalizer change cleans it up a bit so it catches more cases/issues. This also means that the finalizer cleans up the object in all cases, and not only some. @feature.
2015-05-20Eo base: Correct comment regarding the finalizer.Tom Hacohen
2015-05-20Eo: Add a return value to eo_constructor().Tom Hacohen
From now on, constructors should return a value, usually the object being worked on, or NULL (if the constructor failed). This can also be used for implementing singletons, by just always returning the same object from the constructor. This is one of the final steps towards stabilizing Eo. @feature
2015-05-18eolian: new syntax for params/values/keysDaniel Kolesa
Instead of "@in type name;" we now use "@in name: type;". This change is done because of consistency with the rest of Eolian; pretty much every other part of Eolian syntax uses the latter form. This is a big breaking change in the .eo format, so please update your .eo files accordingly and compile Elementary together with the EFL. @feature
2015-05-11eolian: fix doc comments across the treeDaniel Kolesa
2015-05-08Eo: Mark composite APIs as beta.Tom Hacohen
Until now we used @protected, but now we can finally properly use @beta.
2015-05-07eolian: change all EFL .eo files to use new syntax for propertiesDaniel Kolesa
2015-05-07eo: remove the need to order the header correctly for Windows.Cedric BAIL
2015-05-06Eo: Add eo_do_part.Tom Hacohen
This is a convenience macro to be used by the common pattern of getting a part and then immediately calling functions on it. For example, without this macro, you'd have to write code like: Eo *part; eo_do(obj, part = efl_part_name_get("partname")); eo_do(part, a_set(7)); while using the helper function trims it to: eo_do_part(obj, efl_part_name_get("partname"), a_set(7)); @feature
2015-05-06Eo base: Reorder the eolian file to be in a sensible order.Tom Hacohen
2015-05-06Eo base: Fix eo_constructor's declaration.Tom Hacohen
Remove it from the constructors section. This was wrong. This place is for functions that are allowed to be passed to eo_add() and should be used by bindings to create constructors. This is wrong for both cases, as this should always be called, not optional. Also remove the redundant legacy: null.
2015-05-06Eo: Improve documentation.Tom Hacohen
2015-05-06Eo: Take eo out of beta.Tom Hacohen
This is following a last review and a discussion on IRC. Eo has been stable (apart of a decision a few months ago to support more compilers) for a long while. Developers are already using it for a while, and it's stupid to break it for them anyway, so we might as well make this promise now. There are no plans to change it anymore, and it's been heavily used and tested throughout the EFL for a few releases now. I'm tagging it as a feature, although it's not, I'm doing it for the automatic changelog generation. :) @feature.
2015-05-06Eo base: mark composite API as not ready.Tom Hacohen
2015-04-15Revert "eo: add eo_error_get"Tom Hacohen
As discussed on IRC and ML. We are in a feature freeze phase, and this patch is not essential. Furthermore, this patch was never discussed. This reverts commit 537c7fe9e3a72242c386b8851dd450fdc6312171.
2015-04-15eo: add eo_error_getJaehwan Kim
This is pair of eo_error_set.
2015-04-03eo: internal variable should not have that much chance to conflict prefix ↵Cedric BAIL
them with ___.
2015-03-06eo: updated documentation of eo_add and eo_ref_add.Srivardhan Hebbar
Summary: Had a chat with raster to understand the behavior of these two functions in the IRC. Thought it might be helpful if added in the documentation itself. So updated it accordingly. Reviewers: cedric Subscribers: cedric Differential Revision: Signed-off-by: Cedric BAIL <>
2015-02-24Eo: Add eo_do_super_ret.Tom Hacohen
This is the equivalent of eo_do_ret for super calls.
2015-02-23Eo: Remove GCCism and make it more portable.Tom Hacohen
This affects eo_do() and eo_add() that used to use the ({}) GCCism. Following a discussion with Peter de Ridder after my talk at FOSDEM, we've decided to reopen the GCCism (works with other gcc compatible compilers like clang and intelc) discussion, and after a bit of back and forth it was decided to make things more portable, at the cost of ease of use. For example: if (eo_do(obj, visible_get())) is no longer allowed, the portable alternative Eina_Bool tmp; if (eo_do_ret(obj, tmp, visible_get())) is to be used instead. However: eo_do(obj, a = a_get(), b = b_get(), bool_set(!bool_get)) are still allowed and OK. eo_do(obj, if (a_get()) return;); is no longer allowed, but: eo_do(obj, if (a_get()) something()); is still allowed. For clarity, this commit only incorporates the Eo changes, and not the EFL changes to make the efl conform with this change. Thanks again to Peter de Ridder for triggering this important discussion which led to this change.
2015-01-23Eo add: beef up error reporting.Tom Hacohen
In some cases object ceration would fail without an error, this is bad and should not happen. Thanks to cedric for reporting.
2015-01-12Eo: use int for _eo_init_count intsead of Eina_BoolNicolas Aguirre
2015-01-12Eo base class: Fix compliation.Tom Hacohen
@inout also used to affect the type generated. Compile check even the simplest changes.
2015-01-12Eo base: Remove @inout usage.Tom Hacohen
First step towards deprecation of @inout.
2015-01-11Eo: add function name to the eo_do pre and post hooks.Daniel Zaoui
This is useful to determine the Eolian class/function.
2015-01-08eo: Fix bad addressing in _eo_classes arrayAvi Levin
The was masked before using it as index in the _eo_classes array and was not unmasked when used. It hasn't caused segfault (by sheer luck) but was wrong. @fix
2014-12-05Eo: fix error handling when too many deletions invocations occur.Daniel Zaoui
Before this fix, when a deletion was invoked twice on an object, a wrong message ("...You wrongly call eo_unref() within a destructor...") was printed. This was caused by the del_triggered flag that was not resetted when the destruction finished. This patch fixes this behavior by printing the right message on a double deletion.
2014-11-18Eo: protect against recursive object destruction calls, fixes T1741Jérémy Zurcher
Summary: Eo: semantic obj->del replaced by obj->destructed Eo: protect against recursive object destruction calls Eo: add tests for bfada4b Reviewers: JackDanielZ, tasn Reviewed By: tasn Subscribers: cedric Maniphest Tasks: T1741 Differential Revision: Fixes T1741 @fix
2014-10-28Eo comp: Remove dead code following the composite fix.Tom Hacohen
This removes dead code resulting from Cedric's fix: 3550c3808085175cf322670b290bf0c4a70a2fa7.
2014-10-27eo: fix composite to actually work.Cedric BAIL
So I don't really understand why the code was not there before, but it resulted in my experiment of making a combobox for elementary just impossible. Now it work at least.
2014-10-22Eo id: Fix id security checks for invalid objects.Tom Hacohen
In some cases, invalid object ids (e.g 0x1) would pass validation and represent completely different objects (0x80...01). This happened because we weren't properly checking a given object id is actually an object id. @fix.
2014-10-21Eo composite: Fix composite object functions to be eo functions.Tom Hacohen
For some reason, they were normal functions instead of eo functions, which makes them harder to bind, less safe, and just wrong. This commit fixes that.
2014-10-10Revert "Revert "Eo: Move eo_add_ref logic inside the library.""Tom Hacohen
This reverts commit 11da9421842c439474ea08b346cdb1ee986db361. Can't reproduce with the non-existent bug report, thus have no choice but consider it as working.
2014-10-09Revert "Eo: Move eo_add_ref logic inside the library."Mike Blumenkrantz
This reverts commit 8d16d8eb5711d246509e44bf0ce5366f65fd9aea. this broke child object deletion in all the cases that I tested and regular object deletion in some cases as well
2014-10-02Eo: Move eo_add_ref logic inside the library.Tom Hacohen
It was a stupid lazy decision to leave it outside. Having it inside is safer and cleaner.
2014-09-30Eo: Better define the relationship of eo_add/del/ref/unref.Tom Hacohen
Now it's more clear and consistent. This commit complements the previous eo_add commit (a7560dbc61953c3652780f232e38adbd2d711972). Now eo_add should be matched with eo_del eo_ref with eo_unref eo_add_ref with eo_unref + eo_del Essentially, the change is that if you have the ref to an object, you need to unref it. Thus making ref/unref unneeded for most people who use things (carefully) in c. If however, you would like to delete an object previously created by you, you should eo_del (counter-part to eo_add). It's still recommended you ref/unref when dealing with objects in scopes, as you can't know when an object might just get deleted as a by-product of another call. This fixes an issue found by JackDanielZ.