Commit Graph

2 Commits

Author SHA1 Message Date
Daniel Kolesa fcae7cab27 eolian gen: enable constness generation on property getter impls
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.

Ref T6859.
2018-04-17 20:31:55 +02:00
Carsten Haitzler 5dd52fd09b ecore - begin moving data into the efl loop data in the object
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
2017-12-15 14:16:53 +09:00