On 09/03/2012 03:29 PM, Carsten Haitzler (The Rasterman) wrote:
> 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:
>> 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.
Well, that seems to be the case here. I have been told that problem
comes from application trying to set its alpha mask. If it's started
before e17 comes up it would fail to do that and application wouldn't
be visible at all.
>> 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.
You seem to be right on the money here as "setting alpha mask" has to
have something to do with compositing, methinks.
>> 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. :)
Hmm, I've tried to add this pesky application to
.e/e/applications/startup/.order and it _seems_ to work. Although it's
hard to guarantee
anything as the problem used to show up once in 20-50 tries...
>>> 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 :-)
Right, it's this Tizen thing. Actually, it's, cough, system("touch
/tmp/.wm_ready") when, well, e17 seems to be ready. I could have
added call to sd_notify() here, but that wouldn't be much better.
I would really like to kill wmready module entirely, so sending
systemd-or-not ready signal from there doesn't look right either...
Regards,
--
Karol Lewandowski | Samsung Poland R&D Center | Linux/Platform
------------------------------------------------------------------------------
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
