This releases offers the gnutls_certificate_set_x509_trust_dir() API we use in
ecore_con. This gnutls version was release in July 2014 which gave it enough
time to be picked up by distributions.
Thanks a lot to llelectronics for reporting and tracking down the problem.
ref T5437
@fix
We have a report where the use of epoll breaks such systems. Disabling it for
now to make them work again. A deeper analysis is underway to understand this
better and maybe have epoll support later.
Not sure _ecore_fd_valid() is all that useful anymore, as the
commit that introduced it said it would be removed "before release"
a long time ago - it's a debug assist that probably doesn't need
to be in release builds.
(I'm counting syscalls on rpi3 - still, calling this an optimization
seems like a bit of a stretch.)
This reverts commit 25792d6416.
100 patches later the build output is still noisy with all these warnings.
I'm happy to see this warnings added to the default CFLAGS once the current
warnings have been dealt with.
Enable this warning in the local CFLAGS, get the current warnings fixed,
add it to the efl default flags to make the warning prominent for newly added
code.
Windows time_t is not a long, but long-long, then stick with int64_t
so it works everywhere (converts to time_t internally).
And there is no gmtime_r(), then use the gmtime() if not detected.
Since connman is specific to linux, on other platforms just compile a
dummy "none" backend that will always report online and no other
details. This will be used in Windows, MacOS and other platforms that
still lack a proper backend.
The compile-time infrastructure also allows for networkmanager to be
added with ease, simply copy "efl_net*-none.c" or "efl_net*-connman.c"
to be a starting point and then add its specifics, adapting
configure.ac and Makefile_Ecore_Con.am
This reverts commit dc7806e685.
NO. python does it out6 of the box by default. fix the error if you
have one and stop just "turning off the noise". the point of
having this is so that a REAL "why" can be provided by a user by
putting it through eina_btlog and you can see HOW the error happened
at least as a backtrace. turning it off "unless you sety environment
vars" is STUPID. especially for users of e who will likely be unable
to do this a they jusr use a display manager to launch e and cant just
"change environment vars" because they dont know how. you have just
made things worse for getting information fromt he people LEAST
capable of providing information which is where we need automated ways
of doing this "the most".
i use this backtrace all the time. every week or so i identify an
issue just by this built in trace so i know HOW we called that func
because the err complaint was utterly useless as it didnt tell me the
caller etc. which i needed to know "why". this also solves a valid
complain that if you are developibng with efl and e.g. use a legacy
func and pass in an invalid ob you need to know what CALLED the legacy
func. often the issue is several levels up. its the silent masses who
appreciate the feature and use it or then DONT complain. this allows
them to know what the SOURCE of the error is and notjust where it ends
up and this should be done by default out of the box regardless of it
being long because providing more informations is always better than
less. do you propose that kernel oopses should cease dumping all
registers and half a screen worth of junk because "well just set a
kernel boot param to turn it on next time". no. go propose that python
turn off their backtraces by default unless you set and env var. get
these groups to agree to do this, then i'll believe you that this is
TRULYU annoying and not useful and should be off.
you do this just because a few peolpe complain about an error happening
that "SHOULD NOT BE THERE". then FIX THE ERROR. the bt if provided should
nicely provde complete info on how you got there. just making the
error a 1 liner (and those lines are super long and for me 90% of the
time wrap 2 or 3 lines in a terminal) is just sticking your head in
the sand. if its not an error then dont use an eina ERROR use debug or
warn or something else...
User get bitten with this more than they benefit from it. Every use of Eina_Log
will trigger backtrace which clutter the output, confuse and scare users when
they are not suffering anything serious. It is also very trivial for user to turn
it on selectively with EINA_LOG_BACKTRACE when reporting a bug. So let's fallback
to a saner approach. The alternate logical solution would be for application to
just give up on Eina_Log, which is not really acceptable.
As we are moving to runtime dlsym for libdrm, we don't need to link
against libdrm anymore for Ecore_Drm2
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Software drm requires elput in order to function. As gl-drm also uses
ecore_drm2 it should require elput too.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
These are objects to allow control of networking devices
(efl_net_control) as well as an application to request for
connectivity (efl_net_session).
They are loosely based on ConnMan.org, which we already use in
Enlightenment Window Manager via DBus access with Eldbus. However they
do not map 1:1 as the goal was to expose a viable subset of controls
but in a simple and general way, thus nome strings were converted to
enums, some arrays of strings were converted to bitwise flags, some
names were made more general, such as "service" was turned into
"access point" so it doesn't generate confusion with other "network
services" (ie: http server), or "favorite" that was renamed to
"remembered". Some behavior are slightly different (yet able to be
implemented on top), such as "Service.MoveBefore" and "MoveAfter" were
converted to a numeric "priority", calculated from service's list
index, changing the priority will reoder the list and thus generate
the MoveBefore and MoveAfter DBus commands.
ConnMan was chosen not only because we already use it, but because its
DBus API is sane and simple, with the server doing almost all that we
need. This is visible in the efl_net_session, which is completely done
in the server and do not require any extra work on our side -- aside
from talking DBus and converting to Eo, which is a major work :-D
NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as
Properties and ObjectManager, thus we cannot use
eldbus_model_object.
There are two examples added:
- efl_net_session_example: monitors the connection available for an
application and try to connect. You need a connman compiled with
session_policy_local and a configuration file explained in
https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt
to get a connection if nothing is connected. Otherwise it will just
monitor the connectivity state.
- efl_net_control_example: monitors, plays the agent and configure
the network details. It can enable/disable technologies, connect to
access points (services) and configure them. It's quite extensive
as allows testing all of ConnMan's DBus API except P2P (Peers).
as per mailing list discussion about dropping xcb support now. it
hasn't been complete for a long time, thus not recommented for being
turned on. as we are moving to a wayland world xcbmakes even less
sense. as agreed, time to clean up a bit and remove a distraction as
well as not well tested code. this also updates po's too.
@feature
These engines are incredibly similar - by sharing the same engine info
structure we'll be able to simplify the wayland ecore_evas bits and
make them much more maintainable.
Systemd support has now been enabled by default on all capable
platforms. By explicitely providing --disable-systemd, one can disable
its integration to EFL.
When I litterally write that I don't want systemd support, please
don't tell me to enable it. It's almost a passive aggression there ;)
CoreAudio support was initially introduced by commit
62e29b39f4 as an experimental feature.
It played basic sounds, but suffered from drawbacks: it was controlling
the master channel, and therefore any sound played by ecore_audio would
shut down a previous sound (e.g. background music) for the time of the
sound being played. So that wasn't exactly great... Also, after some
time, some hangs have been reported when playing a sound on input. Most
of the time, it translated as a pause in the main loop (see T3797).
More recently (several months ago), ecore_audio with CoreAudio stopped
working during 1.19 development...
So... CoreAudio support on macOS has never been great. And now it's fully
broken. Instead of trying to revive the thing, let just use PulseAudio.
PulseAudio can be installed without any trouble on macOS thanks to
package managers such as Homebrew. Actually, the efl package provided by
Homebrew already provides PulseAudio as a dependency. And it actually
just works very fine. Dropping CoreAudio seems therefore a nice option:
removes unmaintained code, fixes bugs, and add features.
Summary:
This change removes the necessity to link EFL against the libvncserver
Please ignore the first three commits, they're being reviewed here:
https://phab.enlightenment.org/D4323
Reviewers: bdilly, cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4338
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
prctl allows us on some platforms to request a thread be woken up more
agressively e.g. due to a timeout bu setting timerslack. since we use
a dedicated thread just for vsync events, this is a very good idea to
ask the kernel to be as exact as possible for this thread as it only
wakes up once per frame (or should only) and accuracy is important. so
use this.
also improve prctl checks to be more explicit in configure.ac and use
these ifdefs in ecore exe too where prctl is used as well.
@feature
This splits up the definitions from the buildtool into a seperated file
called Elementary_Options.h.
Reason for that is, that every single time when someone adds or changes
something in Elementary.h.in you need to rerun configure, to get the new
up to date Elementary.h file. With this commit you have a static none
generated Elementary.h file and the Elementary_Options.h file, which
will be regenerated when platform things are changing.
The version of elementary is now defined as the version of efl, since
they are always the same. So we dont need to generate a seperated
version field.
This commit essentially removes the ability to use wl_cursor for EFL
Wayland Client Applications. This is a request from "some old man" ;)
for efl wayland applications to use EFL pointers, not X/FDO pointers.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Like existing ecore_con code, this does not use SOCKSv5 UDP
proxy. It's kinda cumbersome to add since requires a keep alive TCP
connection to the server, a second UDP channel and framing around the
original UDP frame.
Added UDP_CORK (if present) to match TCP_UDP present in TCP sockets,
this allows one to execute multiple write() calls that will result in
a single datagram, generated when CORK becomes FALSE again.
The efl_io_copier_example.c now accepts this as output. There is no
input UDP as there is no way to notify the server of a connection
(since such thing doesn't exit), usually servers react after a
datagram is received, replying to the source.
This has been in the making for a very long time. Thanks to Marcel for
reminding me to do it.
What is it?
This is a tool to help application developers debug their apps with
everything Eo. Eo is strict, but not as strict as it can be. Many strict
tests and debug are very expensive to implement, and we have so many
hot-paths that even basic "ifs" to check if debugging is enabled will
add significant overhead to normal running applications. This is why I
created this library. All the expensive tests and bookkeeping should be
wrapped around with "#ifdef EO_DEBUG". With this change, libeo.so is
compiled twice, once normally, and once with this define set (as
libeo_dbg.so). This means that normal eo code will not be affected, but
if you decide to debug your application, all you need to do is:
LD_PRELOAD=/path/to/libeo_dbg.so ./app
Or use the convenient wrapper:
eo_debug ./app
Which will load the debug heavy version.
What's currently there: at the moment, EO_DEBUG enables xref and
data_xref and stricter tests when fetching object data.
In the future, I also plan introducing "zombie objects", which
essentially mean that objects are never really deleted, so you can query
them long after they are gone to get more information on what they were.
So if for example you have an object id that you want to query after the
object has been deleted, you can.
I also plan on having a way to disable/enable certain debug mode
features via env vars, and maybe make the test suite link against this
one instead of the normal one, and possibly add more internal hooks for
the test suite to better inspect internal state?
P.S: The amount of errors spewed out when running it on elementary_test
makes me wish I wrote this earlier. :(
@feature
libproxy allows various means to configure a proxy, will load from
gnome and kde configuration settings, envvars, macos and even windows
registry.
curl still doesn't use it, but we can make that later.
Stefan Schmidt
Vincent Torri
Carsten Haitzler
Derek Foreman
Marcel Hollerbach
Gustavo Sverzut Barbieri
Daniel Kolesa
Mike Blumenkrantz
Jean Guyomarc'h
Cedric BAIL
Chris Michael
Guilherme Iscaro
Subhransu Mohanty
Bruno Dilly
Amitesh Singh
Tom Hacohen