On Wed, Aug 29, 2012 at 11:26 PM, Karol Lewandowski < k.lewando...@samsung.com> 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. 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? > 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 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
