On Fri, 31 Aug 2012 16:39:34 -0300 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> 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. 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. > 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. 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 > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
