On Thu, 15 Aug 2013 19:59:28 -0300 Lucas De Marchi <[email protected]> said:
> On Thu, Aug 15, 2013 at 3:19 PM, Gustavo Sverzut Barbieri > <[email protected]> wrote: > > On Thu, Aug 15, 2013 at 2:11 PM, Lucas De Marchi > > <[email protected]> wrote: > >> On Thu, Aug 15, 2013 at 1:33 PM, Gustavo Sverzut Barbieri > >> <[email protected]> wrote: > >>> On Thu, Aug 15, 2013 at 9:37 AM, Carsten Haitzler <[email protected]> > >>> wrote: > >>>> On Thu, 15 Aug 2013 08:40:36 -0300 Gustavo Sverzut Barbieri > >>>> <[email protected]> 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. one of those platforms... that efl is shipped on by default, doesnt use systemd for this (but it should), so abstracting is a must as we then already have 2 paths. we ALSO have upower... a bit older than systemd and some distros wont go "systemd"... and then think bsd. they may have their own things (i have no idea what they are), but it gives a point for them to plug in and abstract. > > 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. adding an ecore event handler is simpler than using eldbus. :) i dont need to get system bus conn and check for its return. i dont need to create a proxy (or wrappers) with 3 or 4 long strings i have to look up in docs somewhere (with no typechecks :( - thus since they are long they are typo-prone). it just makes it that little bit simpler. > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
