This reverts commit a57c7f7510.
I pretty much hate to just revert your revert, but you failed to read my
replies, and failed to understand what i was talking about.
And YES we talked at fosdem about the platform issue, and do you
remember my answer, that back in time this might be the case, today is
different freebsd suppoerts setenv, and for windows we have a setenv
implementation in evil. And yes, vtorri also created a issue how bad and
evil this commit is, however, i still fail to see the issue since setenv
unsetenv and clearenv usages are taken as needed. (T7693)
The ownership question is answered in
https://phab.enlightenment.org/D7516#137367.
Can we please get into a state of technical discussions, and not *oh
shit, i am going to revert this* this has been in review for a long
time, a lots of people have tested it, we discussed things on it, and
there was 3 weeks of no reply from you.
The issues that exist will be dealed with. Feel free to create tasks if
you want :)
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
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
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
This reverts commit 9b5155c9f1.
For now lets revert this, this breaks copy and paste, further more it
has the potential to break a lot more things, as eio_model tends to use
efl_loop_promise new, and then eina_promise_data_set, which is
explicitly forbidden.
This fixes crashing terminology instances.
I am not sure this is the right way to do it as binding would have to likely
to bind it manually.
Reviewed-by: Lauro Neto <Lauro Moura <lauromoura@expertisesolutions.com.br>>
Differential Revision: https://phab.enlightenment.org/D7492
This brings in the possibility to receive the app object from bindings.
With the app object you can listen to pause / args / terminate / resume
events.
fix T7509
Differential Revision: https://phab.enlightenment.org/D7480
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.
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 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
add efl_main_loop_steal() and efl_main_loop_release() for new efl
namespace versiosn of ecore_thread_main_loop_begin() and
ecore_thread_main_loop_end().
This reverts commit f910ba248e.
The scheduler is meant to be used only in C, not by bindings so there isn't really
a use for it in the loop class. Now this patch was triggered due to complexity in
using future/promise, so will do a follow up patch to improve that.
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
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
Function declared in a .eo are something that we want to allow people to inherit from
or use in a binding. I can't think of a situation where that would be the case for
this function and it solves at the same time problem of needing a shared interface
for both loop and loop_user.
Add Efl.Model.Composite.Boolean, a model for wrapping another Efl.Model and
adding boolean properties to its children.
Children of the given composite model will have the boolean properties
specified in Efl.Model.Composite.Boolean with the specified default value.
A call to Efl.Model.Property_set can change the property value for a child.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Efl.Model.Container and Efl.Model.Item to efl/interfaces are used
to create Efl.Model objects with predefined property values.
This is useful to any situation where we want an Efl.Model with
explicit defined property values.
Efl.Ui.View and Efl.Ui.Factory are used to connect Efl.Models with
Widgets, Elm.Layout and Efl.Ui.Image has changed to use news interfaces
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Since all other efl.io objects are low-level, the recommended approach
is to use an efl.io.copier. However when dealing with in-memory,
bi-directional comms like talking to a socket, we always end with 2
queues, 2 copiers and the annoying setup that is being replicated in
ecore_ipc, efl_debug and so on.
This class is the base to make it simpler. Other classes such as
Efl.Net.Socket.Simple, Efl.Net.Dialer.Simple and Efl.Net.Server.Simple
will use it to provide simpler code to users.
I guess we can call EFL+EO Java now?
Marcel Hollerbach
Carsten Haitzler
SangHyeon Jade Lee
Cedric BAIL
Cedric BAIL
Jaehyun Cho
Mike Blumenkrantz
Andy Williams
Felipe Magno de Almeida
Larry Jr
Gustavo Sverzut Barbieri