On Thu, Aug 15, 2013 at 3:19 PM, Gustavo Sverzut Barbieri <barbi...@gmail.com> wrote: > On Thu, Aug 15, 2013 at 2:11 PM, Lucas De Marchi > <lucas.demar...@profusion.mobi> wrote: >> On Thu, Aug 15, 2013 at 1:33 PM, Gustavo Sverzut Barbieri >> <barbi...@gmail.com> wrote: >>> On Thu, Aug 15, 2013 at 9:37 AM, Carsten Haitzler <ras...@rasterman.com> >>> wrote: >>>> On Thu, 15 Aug 2013 08:40:36 -0300 Gustavo Sverzut Barbieri >>>> <barbi...@gmail.com> said: >>>> >>>>> Raster, heads up here that you can use eldbus_proxy that will make your >>>>> life >>>>> easier writing these things. >>>>> >>>>> For instance you can manage all the pending call lifetime to the object >>>>> and >>>>> proxy, if you delete it (unref) it would do for all pending methods, >>>>> signal >>>>> handlers, etc >>>>> >>>>> It may be new to you, but check the examples or my code to upower/systemd >>>>> uses it as well. >>>> >>>> i saw some of the proxy use - i wasn't sure why i needed it actually. i >>>> didn't >>>> use any pending handles so it turned out for that bit of code, it's not >>>> needed. >>> >>> if will save you replicating those helpers you did... you don't need >>> to do anything with the pending call.. but you can use it to >>> explicitly cancel one. If you delete the object (unref) it will cancel >>> all pending automatically. >>> >>> your code would reduce to get object, then proxy, then call stuff like >>> CanPowerOff, no need to create the wrappers yourself. That's why we >>> added the proxy, to automate these wrappers we were doing over and >>> over again. >> >> Easier to change the code and show him than argumenting ;-) > > currently I'm not bothering, but indeed this would help more than talking. > > >>>> btw... i put this in e right now, BUT... i totally expect that ecore may >>>> get >>>> these features, so the code can be pasted in when we decie just how it will >>>> look like. i just wanted to do some work to support systemd etc. :) this >>>> was a >>>> simple/easy place/thing to do. :) >>> >>> some like inhibit suspend/power actions may be good, but I don't think >>> doing the suspend/reboot action (even if delegated) should come in >>> Ecore... after all there will be a single app doing that in most >>> cases, E itself. >>> >>> to block the suspend/power may be done by all apps, like during a >>> media playback or slideshow.. >> >> What's the point in adding those to ecore, wrapping the systemd >> functionality? >> >> Same question goes for the recently added events for sleep, hostname, >> etc... Why adding a wrapper instead of just let applications listen to >> the signals sent by systemd directly? > > 1 - because some systems don't have systemd, thus we have different > plugins (tizen for instance);
Yet the ones that matter (should) implement that interfaces. > 2 - because it's easier to listen for an ECORE_EVENT than do all the > dbus code, even if eldbus makes it simpler it's still hundreds of > lines of code; > > it's like why shouldn't we just inotify some files to know if locale > and time changed, using localed or timedated or hostnamed... because > it's easier with systemd :-) But it's already easy enough with systemd... and systemd as the init serves as a centralization point for this kind of information. For me those events just add an useless abstraction layer on top. Lucas De Marchi ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
