Re: [E-devel] .desktop files in .local dir are very bad managed IMHO
On Fri, 4 Sep 2009 09:36:13 +1000 Jochen Schroeder cycoma...@gmail.com said: On 09/03/09 11:04, Carsten Haitzler wrote: On Mon, 31 Aug 2009 21:50:32 -0500 Nick Hughart mek...@mekius.net said: On Mon, 31 Aug 2009 17:16:52 -0400 Atton Jonathan jonathan.at...@gmail.com wrote: new test made with liferea. I have drag and drop the icon from the window's border into the ibar. A new .desktop file has been created in ~/.local/sare/applications. Now I have 2 files! /usr/share/applications/liferea.desktop ~/.local/share/applications/liferea-bin.desktop Maybe the window was not link to a valid .desktop, that's why the ibar has created a new one. See, the both files name are different. The systeam file use the binarie liferea and the local use liferea-bin. Yes, this is most likely why it did this. There was no way for E to match the original .desktop to the window as the exec doesn't match and there is probably not StartupWMClass in the original .desktop. E does some tracking on apps if they've been started via the .desktop, but this info is lost if you restart IIRC. unfortunately there isn't much to be done if e can't find a matching .desktop. of course this can be improved to it finds them more easily and keeps them (done already), but there are cases where it will fail. in these cases e is creating the .desktop for u from the wm_command as as far as it can figure out no .desktop file exists for this app. the only other choice is disabling that kind of feature entirely. Should there maybe be a dialog asking if you want to select an existing desktop file as basis? that can be done. if making a new .desktop - pop up a dialog with the info on the new app and that it can't find an existing .desktop - should it create it. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] .desktop files in .local dir are very bad managed IMHO
When a new .desktop is created a popup is already display. 2009/9/3 Carsten Haitzler ras...@rasterman.com On Fri, 4 Sep 2009 09:36:13 +1000 Jochen Schroeder cycoma...@gmail.com said: On 09/03/09 11:04, Carsten Haitzler wrote: On Mon, 31 Aug 2009 21:50:32 -0500 Nick Hughart mek...@mekius.net said: On Mon, 31 Aug 2009 17:16:52 -0400 Atton Jonathan jonathan.at...@gmail.com wrote: new test made with liferea. I have drag and drop the icon from the window's border into the ibar. A new .desktop file has been created in ~/.local/sare/applications. Now I have 2 files! /usr/share/applications/liferea.desktop ~/.local/share/applications/liferea-bin.desktop Maybe the window was not link to a valid .desktop, that's why the ibar has created a new one. See, the both files name are different. The systeam file use the binarie liferea and the local use liferea-bin. Yes, this is most likely why it did this. There was no way for E to match the original .desktop to the window as the exec doesn't match and there is probably not StartupWMClass in the original .desktop. E does some tracking on apps if they've been started via the .desktop, but this info is lost if you restart IIRC. unfortunately there isn't much to be done if e can't find a matching .desktop. of course this can be improved to it finds them more easily and keeps them (done already), but there are cases where it will fail. in these cases e is creating the .desktop for u from the wm_command as as far as it can figure out no .desktop file exists for this app. the only other choice is disabling that kind of feature entirely. Should there maybe be a dialog asking if you want to select an existing desktop file as basis? that can be done. if making a new .desktop - pop up a dialog with the info on the new app and that it can't find an existing .desktop - should it create it. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] .desktop files in .local dir are very bad managed IMHO
On Fri, 4 Sep 2009 12:56:16 -0400 Atton Jonathan jonathan.at...@gmail.com said: i've never had this happen - so never seen it :) When a new .desktop is created a popup is already display. 2009/9/3 Carsten Haitzler ras...@rasterman.com On Fri, 4 Sep 2009 09:36:13 +1000 Jochen Schroeder cycoma...@gmail.com said: On 09/03/09 11:04, Carsten Haitzler wrote: On Mon, 31 Aug 2009 21:50:32 -0500 Nick Hughart mek...@mekius.net said: On Mon, 31 Aug 2009 17:16:52 -0400 Atton Jonathan jonathan.at...@gmail.com wrote: new test made with liferea. I have drag and drop the icon from the window's border into the ibar. A new .desktop file has been created in ~/.local/sare/applications. Now I have 2 files! /usr/share/applications/liferea.desktop ~/.local/share/applications/liferea-bin.desktop Maybe the window was not link to a valid .desktop, that's why the ibar has created a new one. See, the both files name are different. The systeam file use the binarie liferea and the local use liferea-bin. Yes, this is most likely why it did this. There was no way for E to match the original .desktop to the window as the exec doesn't match and there is probably not StartupWMClass in the original .desktop. E does some tracking on apps if they've been started via the .desktop, but this info is lost if you restart IIRC. unfortunately there isn't much to be done if e can't find a matching .desktop. of course this can be improved to it finds them more easily and keeps them (done already), but there are cases where it will fail. in these cases e is creating the .desktop for u from the wm_command as as far as it can figure out no .desktop file exists for this app. the only other choice is disabling that kind of feature entirely. Should there maybe be a dialog asking if you want to select an existing desktop file as basis? that can be done. if making a new .desktop - pop up a dialog with the info on the new app and that it can't find an existing .desktop - should it create it. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] .desktop files in .local dir are very bad managed IMHO
On 09/03/09 11:04, Carsten Haitzler wrote: On Mon, 31 Aug 2009 21:50:32 -0500 Nick Hughart mek...@mekius.net said: On Mon, 31 Aug 2009 17:16:52 -0400 Atton Jonathan jonathan.at...@gmail.com wrote: new test made with liferea. I have drag and drop the icon from the window's border into the ibar. A new .desktop file has been created in ~/.local/sare/applications. Now I have 2 files! /usr/share/applications/liferea.desktop ~/.local/share/applications/liferea-bin.desktop Maybe the window was not link to a valid .desktop, that's why the ibar has created a new one. See, the both files name are different. The systeam file use the binarie liferea and the local use liferea-bin. Yes, this is most likely why it did this. There was no way for E to match the original .desktop to the window as the exec doesn't match and there is probably not StartupWMClass in the original .desktop. E does some tracking on apps if they've been started via the .desktop, but this info is lost if you restart IIRC. unfortunately there isn't much to be done if e can't find a matching .desktop. of course this can be improved to it finds them more easily and keeps them (done already), but there are cases where it will fail. in these cases e is creating the .desktop for u from the wm_command as as far as it can figure out no .desktop file exists for this app. the only other choice is disabling that kind of feature entirely. Should there maybe be a dialog asking if you want to select an existing desktop file as basis? 2009/8/31 Atton Jonathan jonathan.at...@gmail.com Some times ago I had this problem : the .desktop file was copied in ~/.local/application. The result was an entry in the category others of the menu. I have made the test today and no .desktop files was created. Maybe the problem has been fixed some days/weeks ago ? 2009/8/29 Carsten Haitzler ras...@rasterman.com On Fri, 28 Aug 2009 04:08:11 +0200 Thanatermesis thanatermesis.e...@gmail.com said: Ok I don't have read the code to know how exactly works internally but what I see (and my experience) is that: When you drag an icon to your bar, it creates a entire new .desktop file to your .local directory with totally new values, some set by the user and some automatic, but most of times they simply doesn't works (bad values), I have see a lot of different cases, most of them are applications that doesn't launch, applications that can't be added (when inserted to the bar, nothing appears), wrong/null icon, etc... doesn't happen. i just dragged the gacltool icon from the calc window to ibar. before: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop after: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop the same. no change. so this doesn't happen. :/ well not in this test case My thoughts are: if there's already an existing .desktop file, original, good-made, with the correct data on it, with full of translations, with the correct executable and parameters... why WTF we are going to change them to something from scratch, bad-auto-detected, and mostly-wrong ?, could be interesting that the user will modify manually some values, that YES... but only the ones modified by him! and the rest will remain untouched. Like I say, this gives a lot of problems (just try to drag-n-drop a bunch of 10-20 applications to your bar and check all of them (icon image that not works as before, lost translations, wrong executable command set, wrong parameters of the executable,
Re: [E-devel] .desktop files in .local dir are very bad managed IMHO
Thanartermesis told me than his bug is fixed by the change #42067 2009/8/31 Nick Hughart mek...@mekius.net On Mon, 31 Aug 2009 17:16:52 -0400 Atton Jonathan jonathan.at...@gmail.com wrote: new test made with liferea. I have drag and drop the icon from the window's border into the ibar. A new .desktop file has been created in ~/.local/sare/applications. Now I have 2 files! /usr/share/applications/liferea.desktop ~/.local/share/applications/liferea-bin.desktop Maybe the window was not link to a valid .desktop, that's why the ibar has created a new one. See, the both files name are different. The systeam file use the binarie liferea and the local use liferea-bin. Yes, this is most likely why it did this. There was no way for E to match the original .desktop to the window as the exec doesn't match and there is probably not StartupWMClass in the original .desktop. E does some tracking on apps if they've been started via the .desktop, but this info is lost if you restart IIRC. 2009/8/31 Atton Jonathan jonathan.at...@gmail.com Some times ago I had this problem : the .desktop file was copied in ~/.local/application. The result was an entry in the category others of the menu. I have made the test today and no .desktop files was created. Maybe the problem has been fixed some days/weeks ago ? 2009/8/29 Carsten Haitzler ras...@rasterman.com On Fri, 28 Aug 2009 04:08:11 +0200 Thanatermesis thanatermesis.e...@gmail.com said: Ok I don't have read the code to know how exactly works internally but what I see (and my experience) is that: When you drag an icon to your bar, it creates a entire new .desktop file to your .local directory with totally new values, some set by the user and some automatic, but most of times they simply doesn't works (bad values), I have see a lot of different cases, most of them are applications that doesn't launch, applications that can't be added (when inserted to the bar, nothing appears), wrong/null icon, etc... doesn't happen. i just dragged the gacltool icon from the calc window to ibar. before: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop after: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop the same. no change. so this doesn't happen. :/ well not in this test case My thoughts are: if there's already an existing .desktop file, original, good-made, with the correct data on it, with full of translations, with the correct executable and parameters... why WTF we are going to change them to something from scratch, bad-auto-detected, and mostly-wrong ?, could be interesting that the user will modify manually some values, that YES... but only the ones modified by him! and the rest will remain untouched. Like I say, this gives a lot of problems (just try to drag-n-drop a bunch of 10-20 applications to your bar and check all of them (icon image that not works as before, lost translations, wrong executable command set, wrong parameters of the executable, wmclass changed, error-prone values, big etc...) There's also two reports by me from long time ago: http://trac.enlightenment.org/e/ticket/365 http://trac.enlightenment.org/e/ticket/357 Thanatermesis -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
Re: [E-devel] .desktop files in .local dir are very bad managed IMHO
On Fri, 28 Aug 2009 04:08:11 +0200 Thanatermesis thanatermesis.e...@gmail.com said: Ok I don't have read the code to know how exactly works internally but what I see (and my experience) is that: When you drag an icon to your bar, it creates a entire new .desktop file to your .local directory with totally new values, some set by the user and some automatic, but most of times they simply doesn't works (bad values), I have see a lot of different cases, most of them are applications that doesn't launch, applications that can't be added (when inserted to the bar, nothing appears), wrong/null icon, etc... doesn't happen. i just dragged the gacltool icon from the calc window to ibar. before: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop after: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop the same. no change. so this doesn't happen. :/ well not in this test case My thoughts are: if there's already an existing .desktop file, original, good-made, with the correct data on it, with full of translations, with the correct executable and parameters... why WTF we are going to change them to something from scratch, bad-auto-detected, and mostly-wrong ?, could be interesting that the user will modify manually some values, that YES... but only the ones modified by him! and the rest will remain untouched. Like I say, this gives a lot of problems (just try to drag-n-drop a bunch of 10-20 applications to your bar and check all of them (icon image that not works as before, lost translations, wrong executable command set, wrong parameters of the executable, wmclass changed, error-prone values, big etc...) There's also two reports by me from long time ago: http://trac.enlightenment.org/e/ticket/365 http://trac.enlightenment.org/e/ticket/357 Thanatermesis -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] .desktop files in .local dir are very bad managed IMHO
Some times ago I had this problem : the .desktop file was copied in ~/.local/application. The result was an entry in the category others of the menu. I have made the test today and no .desktop files was created. Maybe the problem has been fixed some days/weeks ago ? 2009/8/29 Carsten Haitzler ras...@rasterman.com On Fri, 28 Aug 2009 04:08:11 +0200 Thanatermesis thanatermesis.e...@gmail.com said: Ok I don't have read the code to know how exactly works internally but what I see (and my experience) is that: When you drag an icon to your bar, it creates a entire new .desktop file to your .local directory with totally new values, some set by the user and some automatic, but most of times they simply doesn't works (bad values), I have see a lot of different cases, most of them are applications that doesn't launch, applications that can't be added (when inserted to the bar, nothing appears), wrong/null icon, etc... doesn't happen. i just dragged the gacltool icon from the calc window to ibar. before: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop after: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop the same. no change. so this doesn't happen. :/ well not in this test case My thoughts are: if there's already an existing .desktop file, original, good-made, with the correct data on it, with full of translations, with the correct executable and parameters... why WTF we are going to change them to something from scratch, bad-auto-detected, and mostly-wrong ?, could be interesting that the user will modify manually some values, that YES... but only the ones modified by him! and the rest will remain untouched. Like I say, this gives a lot of problems (just try to drag-n-drop a bunch of 10-20 applications to your bar and check all of them (icon image that not works as before, lost translations, wrong executable command set, wrong parameters of the executable, wmclass changed, error-prone values, big etc...) There's also two reports by me from long time ago: http://trac.enlightenment.org/e/ticket/365 http://trac.enlightenment.org/e/ticket/357 Thanatermesis -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
Re: [E-devel] .desktop files in .local dir are very bad managed IMHO
new test made with liferea. I have drag and drop the icon from the window's border into the ibar. A new .desktop file has been created in ~/.local/sare/applications. Now I have 2 files! /usr/share/applications/liferea.desktop ~/.local/share/applications/liferea-bin.desktop Maybe the window was not link to a valid .desktop, that's why the ibar has created a new one. See, the both files name are different. The systeam file use the binarie liferea and the local use liferea-bin. 2009/8/31 Atton Jonathan jonathan.at...@gmail.com Some times ago I had this problem : the .desktop file was copied in ~/.local/application. The result was an entry in the category others of the menu. I have made the test today and no .desktop files was created. Maybe the problem has been fixed some days/weeks ago ? 2009/8/29 Carsten Haitzler ras...@rasterman.com On Fri, 28 Aug 2009 04:08:11 +0200 Thanatermesis thanatermesis.e...@gmail.com said: Ok I don't have read the code to know how exactly works internally but what I see (and my experience) is that: When you drag an icon to your bar, it creates a entire new .desktop file to your .local directory with totally new values, some set by the user and some automatic, but most of times they simply doesn't works (bad values), I have see a lot of different cases, most of them are applications that doesn't launch, applications that can't be added (when inserted to the bar, nothing appears), wrong/null icon, etc... doesn't happen. i just dragged the gacltool icon from the calc window to ibar. before: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop after: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop the same. no change. so this doesn't happen. :/ well not in this test case My thoughts are: if there's already an existing .desktop file, original, good-made, with the correct data on it, with full of translations, with the correct executable and parameters... why WTF we are going to change them to something from scratch, bad-auto-detected, and mostly-wrong ?, could be interesting that the user will modify manually some values, that YES... but only the ones modified by him! and the rest will remain untouched. Like I say, this gives a lot of problems (just try to drag-n-drop a bunch of 10-20 applications to your bar and check all of them (icon image that not works as before, lost translations, wrong executable command set, wrong parameters of the executable, wmclass changed, error-prone values, big etc...) There's also two reports by me from long time ago: http://trac.enlightenment.org/e/ticket/365 http://trac.enlightenment.org/e/ticket/357 Thanatermesis -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___
Re: [E-devel] .desktop files in .local dir are very bad managed IMHO
On Mon, 31 Aug 2009 17:16:52 -0400 Atton Jonathan jonathan.at...@gmail.com wrote: new test made with liferea. I have drag and drop the icon from the window's border into the ibar. A new .desktop file has been created in ~/.local/sare/applications. Now I have 2 files! /usr/share/applications/liferea.desktop ~/.local/share/applications/liferea-bin.desktop Maybe the window was not link to a valid .desktop, that's why the ibar has created a new one. See, the both files name are different. The systeam file use the binarie liferea and the local use liferea-bin. Yes, this is most likely why it did this. There was no way for E to match the original .desktop to the window as the exec doesn't match and there is probably not StartupWMClass in the original .desktop. E does some tracking on apps if they've been started via the .desktop, but this info is lost if you restart IIRC. 2009/8/31 Atton Jonathan jonathan.at...@gmail.com Some times ago I had this problem : the .desktop file was copied in ~/.local/application. The result was an entry in the category others of the menu. I have made the test today and no .desktop files was created. Maybe the problem has been fixed some days/weeks ago ? 2009/8/29 Carsten Haitzler ras...@rasterman.com On Fri, 28 Aug 2009 04:08:11 +0200 Thanatermesis thanatermesis.e...@gmail.com said: Ok I don't have read the code to know how exactly works internally but what I see (and my experience) is that: When you drag an icon to your bar, it creates a entire new .desktop file to your .local directory with totally new values, some set by the user and some automatic, but most of times they simply doesn't works (bad values), I have see a lot of different cases, most of them are applications that doesn't launch, applications that can't be added (when inserted to the bar, nothing appears), wrong/null icon, etc... doesn't happen. i just dragged the gacltool icon from the calc window to ibar. before: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop after: 5:32PM ~/.local/share/applications ls total 68K 4.0K audacious.desktop4.0K start_nm.desktop 4.0K blender-fullscreen.desktop 4.0K start_xdpms.desktop 4.0K blender-windowed.desktop 4.0K start_xfonts.desktop 4.0K claws-mail.desktop 4.0K start_xmodmap.desktop 4.0K firefox.desktop 4.0K start_xmouse.desktop 4.0K rage-gl.desktop 4.0K start_xrdb.desktop 4.0K rage.desktop 4.0K sylpheed.desktop 4.0K start_alsa.desktop 4.0K xterm.desktop 4.0K start_gnome-settings-daemon.desktop the same. no change. so this doesn't happen. :/ well not in this test case My thoughts are: if there's already an existing .desktop file, original, good-made, with the correct data on it, with full of translations, with the correct executable and parameters... why WTF we are going to change them to something from scratch, bad-auto-detected, and mostly-wrong ?, could be interesting that the user will modify manually some values, that YES... but only the ones modified by him! and the rest will remain untouched. Like I say, this gives a lot of problems (just try to drag-n-drop a bunch of 10-20 applications to your bar and check all of them (icon image that not works as before, lost translations, wrong executable command set, wrong parameters of the executable, wmclass changed, error-prone values, big etc...) There's also two reports by me from long time ago: http://trac.enlightenment.org/e/ticket/365 http://trac.enlightenment.org/e/ticket/357 Thanatermesis -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I
[E-devel] .desktop files in .local dir are very bad managed IMHO
Ok I don't have read the code to know how exactly works internally but what I see (and my experience) is that: When you drag an icon to your bar, it creates a entire new .desktop file to your .local directory with totally new values, some set by the user and some automatic, but most of times they simply doesn't works (bad values), I have see a lot of different cases, most of them are applications that doesn't launch, applications that can't be added (when inserted to the bar, nothing appears), wrong/null icon, etc... My thoughts are: if there's already an existing .desktop file, original, good-made, with the correct data on it, with full of translations, with the correct executable and parameters... why WTF we are going to change them to something from scratch, bad-auto-detected, and mostly-wrong ?, could be interesting that the user will modify manually some values, that YES... but only the ones modified by him! and the rest will remain untouched. Like I say, this gives a lot of problems (just try to drag-n-drop a bunch of 10-20 applications to your bar and check all of them (icon image that not works as before, lost translations, wrong executable command set, wrong parameters of the executable, wmclass changed, error-prone values, big etc...) There's also two reports by me from long time ago: http://trac.enlightenment.org/e/ticket/365 http://trac.enlightenment.org/e/ticket/357 Thanatermesis -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
