On Wed, 24 Jun 2015 13:07:09 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> 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. Well, obviously I have. Doesn't matter, we both agree that dbus doesn't belong in efreet. > > > > > :) > > > > > > > > > > > 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. > > -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
