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); > 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;
But you also loose control. How do you turn the events off? They should be default off no matter if you have the plugin and be on only if the app requested to watch for. Then I would agree with such an argument. Otherwise you will register for countless signals and wake up all EFL apps to do nothing when there's an event like this that most likely noone is interested. Particularly interesting is the battery-low event ;-) 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
