On Wed, 24 Jun 2015 12:57:11 +1000 David Seikel <onef...@gmail.com> said:
> On Wed, 24 Jun 2015 11:46:55 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > On Wed, 24 Jun 2015 12:23:43 +1000 David Seikel <onef...@gmail.com> > > said: > > > > > On Wed, 24 Jun 2015 11:01:22 +0900 Carsten Haitzler (The Rasterman) > > > <ras...@rasterman.com> wrote: > > > > > > > On Tue, 23 Jun 2015 12:18:10 -0400 Mike Blumenkrantz > > > > <michael.blumenkra...@gmail.com> said: > > > > > > > > > I'm fine with this solution, though my preference would have > > > > > been to revert it after the internal changes had gone in so > > > > > that the errors would be gone for the interim. > > > > > > > > i think that at this moment those errors are actually correct and > > > > useful. they are saying that the library is broken. it can't > > > > adapt to updates on the system and issue events for these etc. > > > > without being able to talk to the daemon these features are > > > > broken. in fact if its a fresh user then the library will even > > > > have no desktop file/icon info because this requires a cache > > > > build to be triggered by the daemon. if nothing can talk to the > > > > daemon ... then efreet is broken (same for ethumb). > > > > > > > > so i see silencing the errors is hiding an issue. when efreet > > > > inits its job is to ensure it can see valid efreet related data > > > > (desktop files, icons, mime types etc.) > > > > > > > > the solution imho is to make sure such errors happen far less > > > > often. if we require a dbus session bus then errors will happen a > > > > lot outside of a debus session environment. if we move to lower > > > > level ipc (ecore_con/ipc) and auto-launching the daemon on demand > > > > by the first process that needs it, then these errors will only > > > > happen if the daemon is not installed or cannot execute for some > > > > reason (an error) or there is a permission etc. issue when it > > > > comes to sockets/ipc - also an error. > > > > > > Random errors from random programs pop up on dbus all the time, > > > invariably crashing dbus itself to the point where you need to log > > > out and log in again. > > > > what? i have never seen dbus itself crash. ever. in fact if > > dbus-launch crashed enlightenment would go as child processes would > > go with it. > > > > > Personally I'd go with the "lower level ipc (ecore_con/ipc) and > > > auto-launching the daemon on demand by the first process that needs > > > it" method. It's what I used for such things in my own projects. > > > > that is what i am going to get to. i don't buy the dbus instability > > thing - never seen this on any distro, but it does add complexity and > > far more scenarios which don't work without "active effort". > > Well, I've seen dbus being crashy / unstable / stopping other software > from working, but not actually crashing Enlightenment itself. Lots of > times under Ubuntu LTS. Dbus is probably one the most unstable things I > regularly run here, wish I could just get rid of it. never seen it. and this is the first time i hear anyone saying dbus is crashy. i have never seen dbus-launch or dbus-daemon crash - ever. > > > > :) > > > > > > > > > On Mon, Jun 22, 2015 at 10:11 PM, Carsten Haitzler > > > > > <ras...@rasterman.com> wrote: > > > > > > > > > > > On Mon, 22 Jun 2015 18:00:38 -0400 Michael Blumenkrantz > > > > > > <michael.blumenkra...@gmail.com> said: > > > > > > > > > > > > > On Mon, 22 Jun 2015 21:12:09 +0100 > > > > > > > Daniel Kolesa <dan...@octaforge.org> wrote: > > > > > > > > > > > > > > > On Mon, Jun 22, 2015 at 7:55 PM, Mike Blumenkrantz > > > > > > > > <zm...@osg.samsung.com> wrote: > > > > > > > > > discomfitor pushed a commit to branch master. > > > > > > > > > > > > > > > > > > > > > > > > http://git.enlightenment.org/core/efl.git/commit/?id=1edb35fff3fe54ac7eea1ba2c26e509284b4e470 > > > > > > > > > > > > > > > > > > commit 1edb35fff3fe54ac7eea1ba2c26e509284b4e470 > > > > > > > > > Author: Mike Blumenkrantz <zm...@osg.samsung.com> > > > > > > > > > Date: Mon Jun 22 14:53:13 2015 -0400 > > > > > > > > > > > > > > > > > > edje: unset efreet cache update flag to prevent dbus > > > > > > > > > connections > > > > > > > > > > > > > > > > > > efreet_init began to be called with the addition of > > > > > > > > > translatable strings, but allowing dbus connections in > > > > > > > > > edje (and thus edje-derived tools) will result in > > > > > > > > > errors when edje_init is called without a dbus > > > > > > > > > connection available --- > > > > > > > > > src/lib/edje/edje_main.c | 2 ++ > > > > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > > > > > > > diff --git a/src/lib/edje/edje_main.c > > > > > > > > > b/src/lib/edje/edje_main.c index 03c46ea..a891ec5 100644 > > > > > > > > > --- a/src/lib/edje/edje_main.c > > > > > > > > > +++ b/src/lib/edje/edje_main.c > > > > > > > > > @@ -1,5 +1,6 @@ > > > > > > > > > #include "edje_private.h" > > > > > > > > > > > > > > > > > > +extern int efreet_cache_update; > > > > > > > > > > > > > > > > I believe doing this kind of stuff is a very bad idea... > > > > > > > > I'd look for a different solution. Arbitrarily externing > > > > > > > > symbols like this is something we should never do. > > > > > > > > > > > > > > > > D5 > > > > > > > > > > > > > > > > > > > > > > I'm open to suggestions. > > > > > > > > > > > > i think the solution is to make efreet not complain so > > > > > > loudly if it can't find > > > > > > dbus services. > > > > > > > > > > > > actually efreet as well as thumb imho create way too much > > > > > > trouble using dbus > > > > > > services as an INTERNAL library communication mechanism > > > > > > (between daemons and > > > > > > library clients). just having to deal with the .service files > > > > > > creates a lot of > > > > > > user friction - esp those that compile as these files are > > > > > > installed in PREFIX > > > > > > and dbus isn't looking there. it ALSO means these libraries > > > > > > are only partially > > > > > > working outside of a dbus session. that makes efreet and > > > > > > ethumb useless on systems without dbus or where they may be > > > > > > used on a system daemon. > > > > > > > > > > > > imho for now live with this noise (revert this) and i'll look > > > > > > at fixing efreet > > > > > > and thumb up to not depend on dbus. debus makes sense when > > > > > > you are creating a > > > > > > PUBLIC service you expect others to connect to and talk to. > > > > > > for an internal feature it makes much less sense given the > > > > > > pain points. > > > > > > > > > > > > -- > > > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > > > > > -------------- The Rasterman (Carsten Haitzler) > > > > > > ras...@rasterman.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > A big old stinking pile of genius that no one wants > > > coz there are too many silver coated monkeys in the world. > > > > > > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
