On Fri, 16 Aug 2013 11:35:31 -0300 Lucas De Marchi <lucas.demar...@profusion.mobi> said:
> 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 nlo intention to ever turn them off. they are not high volume like input events, so it's moot. > 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. does it matter? we dont default to off for sigusr1 events or sigchld events or a whole mountain of.. other events... nothing new here. :) > 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 > ;-) that's an implementation issue. right now there is no way to know if there are any event handlers for a given type of event in ecore - we could add that. the moment someone adds a handler - they're interested. turn it on. but to date we haven't needed it even for much higher frequency events. > Lucas De Marchi > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
