Yasufumi Haga wrote: > On Tue, 18 Jul 2006 23:58:08 +0200, > Kim Woelders <[EMAIL PROTECTED]> wrote: > > Thanks a lot for your explanation. > > | Yasufumi Haga wrote: > | > Hi all > | > > | > I'm trying to update ja.po file in e16.8.2, and I have an > | > uncertain entry in the file: > | > > | > #: src/backgrounds.c:2271 > | > msgid "Enable background transparency compatibility mode" > | > msgstr "" > | > > | > Does "compatibility mode" in this entry mean the > | > compatibility with clients before 0.16.8 ? > | > > | No. It has to do with the pseudotransparency (PT) hint (_XROOTPMAP_ID) > | used by apps that do PT stuff. > | > | When "background transparency compatibility mode" is disabled (default) > | there is no change wrt. earlier e16 versions. > | Most PT apps (Eterm afaik being the only exception) use the background > | pixmap reported on the root window (i.e. the first desk), regardless of > | virtual roots, i.e. PT apps use the wrong background image when not on > | the first desktop. > | There have been countless questions about this issue over time. > | > | When "background transparency compatibility mode" is enabled the > | background pixmap of the *current* desk is reported on the root window, > | which makes most PT apps seem to behave properly in most situations. The > | cost is unnecessary PT ops in apps that should not be affected when > | switching desks. > > Let me summarize it briefly :) > PT function used by usual apps except Eterm is always using the image > of the first desktop, and this means a wrong background (i.e. the image > of the fisrt desktop) would be shown when the app is placed in a desktop > other than the first desktop. > Correct so far.
> That's why "background transparency compatibility mode" is introduced > in e16 to fix this issue. If you enable this mode, PT apps use the image > of the desktop where they are placed NOW as a background. Well, not exactly - PT apps normally use the pixmap (_XROOTPMAP_ID) property set on the root window. We cannot change what apps do, but we can set the value of this property. So, when "background transparency compatibility mode" is enabled, e16 sets the root window property not to the pixmap corresponding to the background of the first desk, but to that of the current desk. The app still reads the root window property but now gets the current desk background image pixmap. So, technically the app (actually any PT app on any desk) will use the background for whatever e16 thinks is the current desk, which only is the same as where the app is placed if the app is placed on the current desk :D We normally only pay attention to what goes on on the current desk so all looks fine. > Even if they are in a differect desktop than the first, PT works normally > as expected with this mode. This also implies that even if you enable this > mode, you can't see the difference, or the effect of the mode unless you > are using a PT app except Eterm. > Yes. However, the downside is that the root window _XROOTPMAP_ID property now is changed every time the current desk is changed (assuming the desks have different backgrounds). All normal PT apps on any desk + Eterms on first desk will think that the background is changed and most likely redo their PT operations sooner or later although there were no real background changes. This may slow down desk switching and the general feel of the UI considerably even when there are only a few PT apps. "background transparency compatibility mode" is really a gross hack providing a partial workaround for bad application/toolkit implementations of a not well-defined standard (the _XROOTPMAP_ID, _XROOTCOLOR_PIXEL, and ESETROOT_PMAP_ID hints) in case of multiple desks and virtual roots. Sigh. Apps/toolkits should either use _NET_VIRTUAL_ROOTS[_NET_CURRENT_DESKTOP] to determine the virtual root holding the proper _XROOTPMAP_ID value or ascend the window stack, looking for a parent with _XROOTPMAP_ID set (Eterm does this). Or maybe _XROOTPMAP_ID should be an array of pixmaps, one for each desk, to also provide for multiple non-virtual root desks with different backgrounds? Ok, getting a bit technical and off-topic here... > I hope this is correct :) > > | The term "background transparency compatibility mode" is probably not > | very well chosen, suggestions for a better one are welcome :) > | The compatibility in question was in my mind compatibility with every PT > | app other than Eterm (which behaves properly in any case). > > What about "adjusted (pseudo)transparency mode", I mean the mode > adjusted to the PT function of apps so that it works correctly? > or,...well..."every-PT-app-get-happy mode" (sorry, just a joke) > Well.. correctly... hmm.. But things will not work properly (i.e. without excessive PT operations on desk switch) unless apps/toolkits are changed, although it may seem so at a first glance :( /Kim ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
