| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
just like the commit before, this fixes duplicated api names
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This modifies the API so that global state removal is made
possible. It's still used internally for now but externally
the state is contained.
|
| |
|
|
|
| |
This will be necessary once the unit system is in (it will be used
to keep track of multiple references to objects across units).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Units now form an actual tree stored in their own hash. This will
later replace all global state of Eolian, by introducing a master
unit that you will pass around.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: make check
Reviewers: bu5hm4n, jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5588
|
| |
|
|
|
|
| |
Listing it here without guards will break for builds without c# enabled.
It was actually taken care of a few lines below where it gets included
with the right guards. This one was just around by accident I think.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
return -1 in a void function breaks the build for me (clang)
|
| | |
|
| |
|
|
|
|
| |
This API is meant to be used by parts only, and by bindings dealing with
part objects. This patch fixes make check which got broken in the after
the previous one (cxx).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This resolves a few issues and brings back the experimental features.
Also, disable some of the ugliest experiments:
- manual function overrides,
- define APIs only in eo_cxx namespace
Some APIs are generated behind EFL_CXXPERIMENT (eg. event_name_cb_add or
some weak pointer stuff). I believe they are useful but would like to
make sure there are no serious drawbacks with generating those.
|
| |
|
|
| |
This is useful if the types refer to the current class.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is really just calling efl_del() and detaching the internal pointer
from the C++ object. This will not affect other references, which means
after del the object may still be alive, probably without a parent.
|
| |
|
|
|
|
| |
This prevents generation of del().
I also removed constructor, finalize and destructor as I believe this
requires special work with eo_inherit (where did this work go??).
|
| |
|
|
|
| |
Good for IDE's. Not extremely useful considering how unreadable those
files are.
|
| |
|
|
|
|
|
| |
This will be used for things like efl_del
efl_part was a lucky case where the entire class was to be implemented
manually, thus the global header guard was sufficient.
|
| |
|
|
|
|
|
|
| |
This should give a ref to obj in the following scenario:
auto obj = other.function();
Where obj is an eo object.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is for bindings. I wish I could actually distinguish the use case
more (between efl_add() from C and instantiation from C++).
|
| |
|
|
|
|
|
|
|
|
| |
This generates methods like this:
Part_Class part_name() const;
Which can then be used like:
slider.indicator().format_string_set("%1.1f");
|
| |
|
|
|
|
|
| |
The c++ header was checking the wrong header guard. Fixing that would
break the compilation test, as it was doing the wrong thing. Also I
think config.h should not be included for compilation tests. This should
make things slightly better.
|
| |
|
|
| |
One uses the Bg widget and the other one uses the part.
|
| |
|
|
|
|
| |
It's VERY hacky, but works as expected: no leak, no extra unref. This is
a lucky case of simply overriding efl_part() implementation in C++,
without having to modify the declaration.
|
| |
|
|
|
| |
Those are included headers after all, even if they're only included once
from Elementary.hh (or whatever Efl_Header.hh).
|
| |
|
|
| |
This affects the generated headers.
|
| |
|
|
|
| |
This avoids duplication. Not very important as there are FWD_GUARD
macros anyway.
|
| |
|
|
|
| |
Shadow variables, 0 used as nullptr.
clang still complains that usage() is not declared as noreturn.
|
| |
|
|
|
|
|
| |
This is part of the experimental stuff.
Allows calling C functions without using ._eo_ptr() explicitly. Probably
not super useful, assuming the interfaces are done :)
|
| |
|
|
|
|
|
|
|
|
| |
Add an experimental (disabled) macro to only generate functions inside
the eo_cxx equivalent of a class, instead of inside both the eo_cxx and
the normal class definition.
I guess the duplicated definition had something to do with doxygen, but
I'm not sure this is quite necessary as doc will be generated with
custom scripts.
|
| |
|
|
|
| |
Only regular classes can be instantiated, this should be reflected in
the C++ binding as well.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I'll hide some controversial features behind this, until we come to an
agreement with @felipealmeida and people who actually know C++ (iow: not
just me^^).
Features protected:
- easy wref (using -> without locking)
- xxx_event_cb_add() functions in object classes
- instantiate(obj) to create a new object
- add as a synonym for instantiate (both in efl::eo)
|
| |
|
|
| |
This is just a work-in-progress example.
|
| |
|
|
| |
This was tested on the function pointer Efl.Ui.Format_Func_Cb
|
| | |
|
| |
|
|
|
|
|
| |
I think some concepts are not handled properly in this set of classes.
I'll do some more experiments to see if I can find a working solution,
but I think we need 3 variants of eina_value, instead of just the two
provided.
|
| | |
|
| |
|
|
| |
Refers to Eina_Strbuf*
|
| |
|
|
|
|
| |
Comes in two fashions:
- strbuf_view (read-only)
- strbuf (read/write)
|
