:( Thank you :) On 05/14/2014 01:11 PM, Carsten Haitzler (The Rasterman) wrote: > On Wed, 14 May 2014 11:23:04 +0200 Pierre Couderc <[email protected]> said: > >> On 05/14/2014 09:59 AM, Carsten Haitzler (The Rasterman) wrote: >>> On Wed, 14 May 2014 09:37:04 +0200 Pierre Couderc <[email protected]> said: >>> >>>> On 05/11/2014 01:43 AM, Carsten Haitzler (The Rasterman) wrote: >>>>> On Sat, 03 May 2014 12:27:38 +0200 Pierre Couderc <[email protected]> >>>>> 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. > >
------------------------------------------------------------------------------ "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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
