On Monday, September 3, 2012, Carsten Haitzler wrote: > On Fri, 31 Aug 2012 16:39:34 -0300 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi <javascript:;>> said: > > > On Wed, Aug 29, 2012 at 11:26 PM, Karol Lewandowski < > > k.lewando...@samsung.com <javascript:;>> wrote: > > > > > On 08/30/2012 01:22 AM, Gustavo Sverzut Barbieri wrote: > > > > > > > I dislike this patch as the suggested approach by systemd is to get > the > > > > header and implementation of sd-daemon into your project. See other > > > > projects. This API is not changing and it's a thin layer to just > access > > > > some envvars to get fds and write back some messages. It should be > also > > > > always auto enabled, as the runtime detection is fast and should > work in > > > > BSD as well. > > > > > > > > If you consider this the patch would be 5 lines. > > > > > > > > > That's true, and that is easily fixed. > > > > > > > :-) > > > > > > > Last, is that all the integration we are doing? Come on, I'd expect at > > > > least the startup and shutdown applications to be handled by systemd > > > > --user. And our internal darmons (fm, thumbailer, cserve2, ...) > > > Ultimately > > > > e_exec of desktops could be managed by it (but I believe systemd > lacks > > > this > > > > > > > ATM). > > > > > > All I wanted to accomplish here is to have reliable startup > notification > > > of e17 "being ready". By being ready I understand "e17" being able to > > > process events. My very limited (and possibly flawed) understanding of > > > X11 suggests that should be "correct". (No, I don't care about modules > > > loading in background. I don't think I should, that is.) > > > > > > I can drop autoconf easily, real question is at which point of e17 > > > existence it should say "hi, I'm ready". My first attempt was > > > to just do it idle loop, but it was ugly and broken so badly > > > that I didn't really want to submit that. However, I didn't find > > > time to take a look at this for second time, and the patch starts > > > to age... > > > > > > > > Agreed this is the major problem, but likely it's not a problem! > > > > Yesterday I've talked to Lennart here at LPC, and what could be the > meaning > > of "WM ready" is void. You just don't need it. > > actually here i disagree. sure - it should run/work to launch apps before > the > wm... BUT you may want to defer launching to avoid "artifacts". this means > things like app windows appearing THEN disappearing and re-appearing as the > window manager then manages them. that is the big usefulness of this.
Then as I said, this could be a solution. But: if e17 starts and sets itself as composite manager, nothing would show at screen if it did not paint, right? Then the "ready" signal could go much earlier! My personal impression is that splash takes too long, I can start using e17 much sooner if I don't use splash > > > Unless you need something that relies on e17 to be ready, there is no > point > > in saying it's "ready". Just use a type=simple, that's it. > > > > Rationale: > > - if something depends on e17 EFM dbus api, they should wait for the > DBus > > to provide the BusName and interfaces > > - the X11 management is picked up at any time, so creating windows > before > > the WM exists is fine (*note later) > > - the other behavior of a WM should be dynamic, e17 is "able to be > > restarted" > > > > > > *note: if you just want to create windows after the WM window management > > modules (ie: tiling, comp...), then we'd need to have the Type=notify and > > READY=1 when these modules are done. Maybe we can do after every module > is > > loaded, maybe we better flag the modules in EET as "impacts WM ready", > then > > if there are such modules we wait them to be loaded and just after that > we > > reduce the global counter, that reaching 0 will notify READ=1. > > > > What do you think? Do you have more details on that? > > in this case then the right place to notify systemd is where e closes its > own > splash which is guaranteed to be after all of this. so in e_init.c. if all > this > is is getting some env vars, fd's and writing something out then there is > little point looking for systemd headers and instead just doing it > directly in > e's code at runtime. That's what I said in my first review. But i'd not recommend replicating the code from sd-daemon.c although we could. It serves as reference of what else we could use it. Say that in future we also want to have our support daemons to be activate able using systemd "socket activation", then e_fm, thumb and others could all use that file. > > so i see this as useful for avoiding flicker artifacts. of course if you > used e > to launch your apps as the session manager it'd start running them after > it's > managed the root window already so no artifacts will happen. :) > > > > You have to note that I'm low-level/embeeded integrator type of guy > > > who just wanted to use systemd notification instead of (believe me) > > > really ugly hacks that we have on our system. I can do some monkey > > > coding, but I do lack any kind of e17 knowledge. Thus, any advice > > > is really appreciated. > > > > > > > Ok, let's try to evaluate the case above... I know the hacks you're > trying > > to solve, are those from Tizen, right? You'll be praised... as that hack > is > > horrible and should die soon, thanks for your work :-) > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -------------------------------------- > > MSN: barbi...@gmail.com <javascript:;> > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net <javascript:;> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com <javascript:;> > > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
