this is just causing errors and nothing usefull, upower is not available
on macos.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11652
A long story in a few words: sometimes on macos modules will be compiled
into .dylib, sometimes, into .so suffix. We did not set the suffix
everywhere in our meson build instructions, hence our suffixes have been
differently, which resulted in random load fails on different maschines.
With this commit, we ensure that we suffix all modules the same way.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11650
while tizen module is disabled and systemd is not build on Windows, upower is built and run
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9658
This build was never complete and also was not maintained probebly.
It is also dropped in favour of meson which is cool, merged, works & is fast.
Differential Revision: https://phab.enlightenment.org/D7010
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
This reverts commit 2cea85db38.
Their was a typo that I made during cleanup of the patch before pushing that I didn't
notice broke some stuff. But also you may have an old efl_general.h in your elementary
directory that is now being picked instead of the one provided by the tree.
Revert "elementary: currently double declare elm_init/shutdown."
This reverts commit 44bb0c1848.
Revert "elementary: fix efl_ui_multibutton installed headers."
This reverts commit 32a213dc72.
Revert "elementary: introduce Efl_Ui.h."
This reverts commit df3d3f7334.
Revert "ecore: do not display error message on cancel."
This reverts commit 99654b7cd2.
Revert "efl: and don't forget to install the new dependencies."
This reverts commit 814ffb9b6b.
Revert "ecore: remove EFL_OBJECT_BETA as Efl_Core.h is for Efl new inerfaces."
This reverts commit 619d0f3cff.
Revert "ecore: move EAPI_MAIN from elementary to ecore."
This reverts commit e5d84da864.
as such commit e5d84da864 starts the
breaking. enlightenment, terminologya and other apps can't compile
against that efl anymore. 619d0f3cff
then makes this even worse with even more header errors and undefined
types. on top of this df3d3f7334 then
starts making elementary_test segfault when it runs. it wont even
start up.
asu such of these 7 commits in the first 4 (that are then relied on
later) 3 of these first 4 cause serious breakage. this simply is a
complete lack of testing changes, so i've rolled fl back to before
these things so it builds and works again and you can build against it.
PLEASE test these things. this looks ot me to be obviously a lack of
any testing... :(
so ecore uses ecore system modules ... that use eldbus. eldbus inits
ecore. this is a vicious cycle. eldbus shouldnt init ecore. it's a
dependency but should be provided outside of initting eldbus. this all
led to hack-arounds on initting eldbus in these ecore modules that
just break things like shutting down eldbus when still in use.
this ensures any pending messages are canceled on ecore module shutdown.
this ensures every ecore module fully inits and shuts down eldbus as
they should so refcounting the inits works.
this stops eldbus from inittign ecore to avoid the circuluar dependency.
this stops lots of CRI/ERR complaints eg if you run elua with no
cmdline options.
this is just better.
@fix
eldbus initializes ecore that may then init eldbus again,
since one of the systemd modules is for eldbus.
eldbus_shutdown() is then no longer functional, as there are
two refs on eldbus.
This patch solves this problem by removing the extra ref on
eldbus from the module if it was already initialized.
This patch now introduces really bad issues since there are now
EO classes that fail to work after module load-unload-reload.
Summary:
From UPower 0.99.0, a property "OnLowBattery" was removed and
upower have recommended to use "WarningLevel" instead.
This revision provides "WarningLevel" using the property "DaemonVersion"
and it keeps dealing with "OnLowBattery" as well for old system.
Fixes T1909
Reviewers: gwanglim, barbieri, zmike, stefan_schmidt
Reviewed By: barbieri
Subscribers: zmike, stefan_schmidt, cedric
Differential Revision: https://phab.enlightenment.org/D1717
0.99.0 removed the OnLowBattery property and added the per-device WarningLevel property. this requires what will effectively be a full rewrite of the module to track all the power levels of all the attached batteries and set the ecore power level somehow based on a combination of their levels
since I have no desire to spend any more hours working on and debugging this module which is based on a known-unstable api, I'm making it disable itself if it detects a version >= 0.99.0. hopefully someone will decide to maintain both this and eldbus in the future so that we can more accurately track upstream when they make changes to these things
ref T1908
ref T1909
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
It's always enabled as it's a dbus module and links to nothing,
actually the daemon doesn't need to be running -- in that case it will
do nothing. In the case the daemon becomes active then it will get the
OnLowBattery property and keep it in sync.
NOTE: I couldn't test the property change as my laptop takes many
hours to get to that situation... let's hope it works :-)
Ecore will now load "system modules" on ecore_init(). The "systemd"
module will use DBus to monitor localed, hostnamed and timedated and
add system events related to those changes.
Marcel Hollerbach
Vincent Torri
Marcel Hollerbach
Mike Blumenkrantz
Cedric Bail
Carsten Haitzler
Gustavo Sverzut Barbieri
Jean-Philippe Andre
MinJeong Kim
Daniel Juyung Seo
José Roberto de Souza
Lucas De Marchi
Jihoon Kim
Gustavo Sverzut Barbieri
Iván Briano