Hm, looks not that good with the event for cm activation. It would be the responsibility of the cm to send a client message that it acquired the cm selection. xcompmgr does not. also it's pretty much work as one has to listen to client messages, then remember the window which got the selection and finally listen for window destroy messages to see when the cm is gone. and also implement the event handling for shelves.. pretty much work for this little benefit. imo we could stick with how it is done now. if one wants to be sure that a compositing manager is running one can just check ecore_x_screen_is_composited each time when creating a window.
On Tue, Sep 22, 2009 at 8:40 PM, Viktor Kojouharov <[email protected]> wrote: > On Tue, 2009-09-22 at 19:27 +0200, [email protected] wrote: >> On Tue, Sep 22, 2009 at 1:26 PM, Viktor Kojouharov >> <[email protected]> wrote: >> > On Tue, 2009-09-22 at 10:57 +0200, Dave Andreoli wrote: >> >> >> >> >> >> 2009/9/22 Viktor Kojouharov <[email protected]> >> >> Chances arde small that 2 composite managers (one of tghem >> >> bling) will be running at the same time. And if you disable >> >> bling, then it will be preferrable if that config option is >> >> turned off. I can't think of a single use case where this will >> >> cause problems. On the other hand, at the least it will save >> >> the user some actions by toggling this on their behalf. >> >> >> >> indeed, but in this way you are disabling the use_composite on every >> >> shoutdown, not only when the user disable >> >> the module. >> >> On next E startup the use_compisite will be off until bling start, and >> >> some module (loaded before bling) can make some >> >> wrong assumption. >> >> btw, I tested the commit and dont' seems to cause problems here ;) >> > >> > >> > good point. thought I think any modules that only check once whether >> > composite is in use should be fixed. Right now only a few modules make >> > any use of composite. Everything checks it every time it needs to, and >> > works properly in this regard. My module drawer on the other hand >> > doesn't, but I will fix that :) >> >> shelves are also affected by use_composite option. so changing >> use_composite after shelves are loaded wont work. I think it would be >> good to modify the composite option to be off/automatic/always and to >> have an event for changing composite state. shelf could listen to this >> event and recreate its popup. we could keep use_composite as state >> variable and add composite_mode config option. >> In 'automatic' mode e would listen to changes of the cm atom selection >> and send an event for changes. I can look into making the event. in >> 'always' mode use_composite is always 1, this has the advantage to not >> need to recreate shelf and itask-ng when one knows that a compositing >> manager will be running. >> > > sounds good. we could also totally remove the use_composite option, > since now pretty much every composite manager has a corresponding cm > atom. e will just emit events whenever a composite manager > appears/leaves, and the rest should be handled automatically. >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> enlightenment-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
