setenv and unsetenv are not portable. i explained to you at fosdem
there are issues and it's why i used putenv in the original
implementation and even though it's a pain (the string tou pass to
putenv is a pointer used literallt from there on in and you get it
from getenv, thus making ownership a pain -this is a libc issue we
can't readily solve). use putenv like the original code. then put it
back in. vtorri now has windows porting issues with the setenv use. i
knew there was a reason that still existed...
in addition your in_sync stuff is broken. psuedocode:
// assuming BLAGH env is not set to anything here
c = efl_core_env_get(global_env, "BLAH");
...
putenv("BLAH=10");
...
c = efl_core_env_Get(global_env, "BLAH");
i will get NULL in both cases for c ... but i should get "10" for the
2nd in reality. reality is lots of code across application code and
libraries will at times mess with the environment. it has to work with
this. the prior implementation did work with this.
Revert "ecore: here comes a env object"
This reverts commit 2373d5db5b.
Revert "efl_task: remove env from this object"
This reverts commit c3d69f66a6.
Revert "ecore: get rid of commands in efl_task."
This reverts commit 616381e9cf.
Revert "ecore: here comes a command line object"
This reverts commit 48e5684b3c.
1. this is broken:
EOLIAN static const char*
_efl_core_command_line_command_get(const Eo *obj EINA_UNUSED, Efl_Core_Command_Line_Data *pd)
{
return eina_strdup(pd->string_command);
}
it returns a const char * BUT it duplicates it on return. no. a big
fat honking NO. return a char * or don't duplicate. pick.
2. _efl_core_command_line_command_array_set() is broken by design. it
accepts an array of strings, but the strings are owned by the caller
who creates the array (requiring they free them up themselves after
this call) but the array becomes owned by the callee. the code here frees the
incoming array but doesn't care about the string content of it. it's
leak heaven waiting to happen (or bugs when someone wants to access
the array they create to walk it to free the strings they put into it
after it is set).
i brought this up and it was dismissed. now exactly he issue i brought
up is there with mixed ownership and the added complexity as well as
transfer of some ownership but not others.
go back and think about this so it isn't broken by design.
the mixin for now can carry a command, which can be setted as an string.
The string is then parsed again, this is done in order to make sure that
everything that needs escaping really is escaped or parsed correctly.
Differential Revision: https://phab.enlightenment.org/D7516
the env object can be used to alter and edit the content of environment
variables. Additionally, the class efl.core.env can be used to to setup
a not applied set of environment variables, which then can be applied
later (in the future) to set it directly to a spawned process for
example, or as a general key/data storage. A efl.core.env object can
also be forked off, which makes it easy to customize predefined objects.
ref T7514
Differential Revision: https://phab.enlightenment.org/D7510
We missed the include path to the tests folder where the generated
ecore_audio_ou_test files are located. Found by our relentless TravisCI
cron job.
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7877
Summary:
As the result of discussion in T7458,
we need to rename all efl_model based classes with efl_XXX_Model sequence.
I've run few vote for this, see V42, V43
few classes are totally renamed as our consideration of misnaming.
| Efl.Model_Loop | Efl.Loop_Model |
| Efl.Model_Item | Efl.Generic_Model |
| Efl.Model_Container | Efl.Container_Model |
| Efl.Model_Container_Item | Efl.Container_Model_Item |
| Efl.Model_Composite | Efl.Composite_Model |
| Efl.Model_Composite_Boolean | Efl.Boolean_Model |
| Efl.Model_Composite_Boolean_Chlidren | Efl.Boolean_Model_Item |
| Efl.Model_Composite_Selection | Efl.Select_Model |
| Efl.Model_Composite_Selection_Chlidren | Efl.Select_Model_Item |
| Efl.Model_View | Efl.View_Model |
| Eio.Model | Efl.Io.Model |
| Efl.Ui.Model_State | Efl.Ui.State_Model |
| Efl.Ui.Model_Size | Efl.Ui.Size_Model |
| Efl.Ui.Model_Exact | Efl.Ui.Exact_Model |
| Efl.Ui.Model_Average | Efl.Ui.Average_Model |
| Efl.Ui.Model_Homogeneous | Efl.Ui.Homogeneous_Model |
I worried about Efl.Io.Model changes, cause it is widely used,
but as I tested, there is no issue found yet.
Eldbus.Model also may can changed Efl.Dbus.Model,
but I cannot found any class who using Efl.Dbus namespace,
so I left it future work.
Test Plan:
Run the Make Test,
it works well except Efl test about selection.
there are class inheritance problem exist in select_model,
I reported it and will fix it in another patch.
Reviewers: cedric, felipealmeida, woohyun, Hermet
Reviewed By: cedric
Subscribers: lauromoura
Tags: #efl, #do_not_merge
Differential Revision: https://phab.enlightenment.org/D7533
This will enable inheriting class to not have to implement as much code. This patch
fix also all class that use Efl.Model_Composite and its test.
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7654
ecore_audio does define format and source, those are then used in some
leave classes, ecore_audio is only used in the tests, and should not be
used externally. Therefore make it abstract.
The other missing implementations are in the leave classes,
They are resolved with providing empty implementations, since no format
switching is supported.
ref T5719
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7782
With the advancement of our MVVM interfaces, we realize that it could be made easier,
especially for bindings, to write an Efl.Model that proxy another one without having to
necessarily implement the entire logic of propagating event and checking if the property
we are getting request for is actually handle by our own Efl.Model. To simplify this,
I introduce this class that allow to set new callback for each property you want to handle
on your object.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7487
Fix type error while getting boolean property from Efl.Model_Composite_Boolean.
Fix properties_get methods for all composite models.
Now properly call property.changed events when it is needed.
Use EINA_VALUE_TYPE_BOOL instead of EINA_VALUE_TYPE_UCHAR.
Remove some memory leaks.
Since Efl.Interpolator's subclasses are used as interpolator class,
Efl.Interpolator class is changed to be an interface.
This change allows Efl.Canvas.Animation to have Efl.Interpolator as its
property in efl_canvas_animation.eo.
Summary:
This reverts commit 4917910b49.
4917910b break backward compatibility.
Reproduction:
void pipe_handler(...);
pipe = ecore_pipe_add(pipe_handler, NULL);
ecore_pipe_write(pipe, NULL, 0);
Because of the null check condition, pipe_handler isn't called after 4917910b.
Some apps behavior which is written to expected to call pipe_handler was broken.
also, this patch fixed segfault during build on Windows
Test Plan: make on Windows
Reviewers: raster, zmike, vtorri
Reviewed By: zmike, vtorri
Subscribers: woohyun, cedric, #reviewers, #committers, zmike, vtorri
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6824
Summary:
this needs to be consistent so that it can be used reliably across suites
also these build flags really need to be consolidated into a single variable
that can be reused
Depends on D6666
Reviewers: devilhorns, bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #committers
Tags: #efl_build
Differential Revision: https://phab.enlightenment.org/D6731
Summary:
As Lua bindings don't work right now, it is pointless to waste
build time generating them. Elua itself on the other hand is
useful and should stay enabled.
This also does some preparation work for separate configure
switch for bindings after release, but for now keep configure
switches as they are.
Reviewers: zmike, stefan_schmidt
Subscribers: cedric, bu5hm4n, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6721
somehow ecore-x explicitly pulls in ${libdir}/libX11.so at link-time,
which causes libtool to add ${libdir} to the rpath executable wrappers
before the remainder of the in-tree efl paths. this causes binaries run
from these wrappers (e.g., tests, built-time tools such as codegens) to
use system libraries instead of in-tree libraries
@fix
Differential Revision: https://phab.enlightenment.org/D6635
Summary:
this caused DSO linker issues when enabled and was only testing
init+shutdown for a deprecated component which has not been actively developed
in some time
Reviewers: devilhorns, ManMower, bu5hm4n
Reviewed By: devilhorns, ManMower
Subscribers: bu5hm4n, ManMower, cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6539
Summary:
A few classes were added in the wrong place in the makefile, rendering them
neither public nor legacy, and unaccessible to bindings.
Test Plan:
The Efl.Model_Item class is now accessible to C#, and previously it wasn't.
This class is used in the EO tutorials, which would have needed a rewrite.
make check, examples & distcheck still work.
Reviewers: bu5hm4n, zmike, devilhorns
Reviewed By: zmike, devilhorns
Subscribers: cedric, felipealmeida, lauromoura, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6507
this adds a simple indata and outdata void ptr to begin that you can
set on efl.thread objects (set the indata) and get the outdata too to
get results. then on the efl.appthread side the indata is set on the
efl.appthread before it runs and on quit the thresad can set the
outdata on the appthread, and this appears back on the efl.thread
object in the parent thread.
so you can basically share pointers to anything in and out this way on
start/exit in addition to string args etc.
the reason i made it an extra class (mixin actually) is for future
expansion. sharing more complex data - eina values maybe or objects as
long as they are shared objects, and perhaps acting as an interface
for calling a function at the other end like ecore_thread_async_call
etc.
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
this moves existing tests out of the ecore suite and into a new one,
adds some checks to verify loop object parenting, and verifies compile
for Efl_Core.h and Efl_Net.h using EFL_NOLEGACY_API_SUPPORT
this is astart of the work for having a common task class/interface
between loops, threads ane exe's so the i/o is all symmetric and works
the same way between all of them as well as similarly for launching
and knowing when the exit etc. etc.
this is not final and not perfect, but it's a start. comments of
course welcome
also eina_procmis was not threadsafe so cannto use loops in different
threads at all until this was made safe. needed to disable the old
ecore_event using code in for ecore futures and create a new efl loop
message future and handler instead ... but now a quick experiment with
multiple loops in 10 threads plus mainloop have timers at least work.
i need to test more like fd handlers etc etc. but it's a step.
we really should have data inside the loop object, so begin moving it
one small thing at a time. this is the basics that will allow multiple
efl loops. make an eo efl object and class for fd handlers that is efl loop
bound make fd handlers really bound to their parent loop and not global as
well as have a nice class/obj. create an message queue per loop and
put legacy ecore events on top of it... and a lot more.
this is not 100% done, but it's a lot of the core and groundwork.
various ecore_timer_add(), ecore_diler_add() etc. need changes.
The following still need doing:
ecore_timer (internal usage for sure)
ecore_idler (internal usage for sure)
ecore_idle_enterer
ecore_idle_exiter
ecore_pollers? (is the new efl loop stuff ok?)
ecore_exe (fork/spawn from any thread and track exe from that thread?)
ecore_signal code
ecore_throttle (should we have a single global too? we have per loop)
ecore_app ? (should every loop be given its own argv/argc?)
Lots of internal ecore code uses/calls these legacy calls and we
should have efl loop replacements and/or use the ones we have
The following will bedifferently designed for loop to loop
control/messaging/ipc:
ecore_thread
ecore_pipe
This make EFL_MAIN available and working with just Ecore. For simplicity
it is available with Efl_Core.h. Ideally it should also work with Efl_Net.h
alone and finally with an Efl_Ui.h.
T6262
Efl.Interpolator class is to interpolate a value.
Efl.Interpolator class has the following interpolation function classes
as its subclasses.
Efl.Interpolator.Linear
Efl.Interpolator.Accelerate
Efl.Interpolator.Decelerate
Efl.Interpolator.Sinusoidal
Efl.Interpolator.Divisor
Efl.Interpolator.Bounce
Efl.Interpolator.Spring
Efl.Interpolator.Cubic_Bezier
In commit df9f2e0772 this new header file
was introduced but it was missing from this list and thus never made it
into the dist.
I have to say I look forward to a future where a git based dist
handling, like meson does, replaces the tiresome approach of keeping the
list up to date.
Marcel Hollerbach
Carsten Haitzler
Stefan Schmidt
SangHyeon Jade Lee
Cedric BAIL
Cedric BAIL
Vitor Sousa
Jaehyun Cho
Yeongjong Lee
Mike Blumenkrantz
Daniel Kolesa
Xavi Artigas
Mike Blumenkrantz
Marcel Hollerbach
Felipe Magno de Almeida
Stefan Schmidt