On Wed, 14 May 2014 11:23:04 +0200 Pierre Couderc <pie...@couderc.eu> said:
> > On 05/14/2014 09:59 AM, Carsten Haitzler (The Rasterman) wrote: > > On Wed, 14 May 2014 09:37:04 +0200 Pierre Couderc <pie...@couderc.eu> said: > > > >> On 05/11/2014 01:43 AM, Carsten Haitzler (The Rasterman) wrote: > >>> On Sat, 03 May 2014 12:27:38 +0200 Pierre Couderc <pie...@couderc.eu> > >>> said: > >>> > >>>> I have 2 desktop files vmware-player-XP.desktop and > >>>> vmware-player-W8.desktop > >>>> > >>>> They appear without problem in the iBar,each one with its own icon. > >>>> I start vmware-player-W8.desktop, iconize it, and it appears in the ibox > >>>> but with the icon of vmware-player-XP.desktop. (instead of > >>>> vmware-player-W8.png). > >>>> > >>>> I do not understand what may occur. > >>> because icons are not provided by the app but are matched. matched by a > >>> seies of guesses, each one getting less accurate as you fall back. the > >>> mo9st accurate is via netwm startup id, and this is an env var set when > >>> app is launched. it is the job of the app to set the string content pf > >>> that env var as a property on the window. my bet is vmware doesnt do > >>> this, so e is falling back to matching commandline executable (vmware) > >>> which is ambiguous. it may match class name too. so... may a copy or > >>> symlink and use a different executable or complain to vmware about netwm > >>> startup id. > >>> > >>> to check the startup id: > >>> > >>> $ xprop | grep ID > >>> _NET_STARTUP_ID(UTF8_STRING) = "E_START|133" > >>> > >>> (and click on the window you want to check - notice efl apps do this). > >>> > >>> > >> I see. In my case, it should be easy as the application is started from > >> the iBar, it would be logical to take the icon from .desktop file..? > > it doesn't quite work that way. application is launched but a window > > created is just a new window event from x. there is no link between the > > window appearing and the process running, UNLESS the process provides that > > link. the most accurate is the startup id as above as a property. the next > > best is the netwm PID property giving pid - that ASSUMES the pid that was > > launched by e in ibar is the same pid that creates the window and sets the > > pid property on it - for firefox and chromium this is not the case and > > unless they support the startup id property (last i checked chromium does > > not), then this can't/doesn't work. we cant figure out which icon you > > clicked on that launched the window that you see. if we can figure it out - > > we match them up. > > > > > > > I see, so maybe, there is a solution by modifying the .desktop file > which could start a bash file that will provide some ID then start the > application..? you can't. well you could do it with an ld_preload and trap the window create and then force a property to be added - but no such ld_preload has been written and it wont work for setuid apps. e already provides the id in an environment variable as per freedesktop.org specs - some apps support it. efl always supports it as its done in the toolkit if the app likes it or not. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
