dx-packages team mailing list archive

[matteo sisti sette <1296909@xxxxxxxxxxxxxxxxxx>]

If the system is generating .desktop files automatically, then it should
generate different desktop files for different binaries that are in
different locations. What if I run two programs that have absolutely
nothing to do with each other but whose executable file happens to have
the same name?!?

Generating automatically a .desktop file based on a binary name, and
reusing that for another binary of the same name, is a wrong design and
should be fixed (and the fix is easy).

Also, if I download an executable, place it in an arbitrary place, and
run it, and then delete it, I don't expect it to leave any trash around
the system that will potentially affect other programs. If _it_ does,
then it's that executable's author's responsibility, but if the system
does, and doesn't warn me, then the system is doing somnething wrong. At
least it should show a notice (with a "don't show again" option)
indicating that a desktop file has been created and showing its
location, so I know that I may need to delete it later. Consider at
least that.

And another thing: apparently the .desktop files that are automatically generated for any executable you run,  not always work.
I downloaded Processing (http://processing.org). It's a .tgz that you extract to a folder and then you run an executable in it. When I run it, an icon appears on the Launcher. Right-clicking and selecting "lock to launcher" locks the icon lock to the launcher, but when I later click on the icon nothing happens. So the mechanism that creates .desktop files automatically does not always work.


> I'm marking this bug as invalid because the system is actually working completely as designed. 
The design is seriously wrong then, and the bug should be reopened until the design is fixed.


>  In this case the problem can be resolved by manually fixing the configuration (.desktop) files that are reserved for the user,
> probably by removing them.
Yes, given that the user figures out that a .desktop file has been created and where. Now I know that, but I had to come here to figure out. That's ridiculous.

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dx-packages
https://bugs.launchpad.net/bugs/1296909

Title:
  What you lock to launcher is not what you get locked to launcher

Status in “unity” package in Ubuntu:
  Invalid

Bug description:
  I downloaded Eclipse from here: https://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/kepler/SR2/eclipse-standard-kepler-SR2-linux-gtk-x86_64.tar.gz
  which is a tar.gz, which I untarred into a custom folder, namely ~/Documents/programmi/eclipse, by placing the .tar.gz in ~/Documents/programmi and right clicking on it with Nautilus and doing "extract here".
  (~/Documents/programmi is not set up to be any special or privileged folder for programs, it's just a folder that I created inside Documents).

  Then I realized that was not the version of Eclipse I wanted, so I installed Eclipsed by running in a terminal:
  sudo apt-get install eclipse
  This created, among other things, a /usr/share/applications/eclipse.desktop file
  "which eclipse" outputs "/usr/bin/eclipse"

  When I type "eclipse" into a terminal, the one installed with apt-get will run, as expected.
  I slightly modified /usr/share/applications/eclipse.desktop so that UBUNTU_MENUPROXY would be used (to work around the menus-not-working bug), and when I run "eclipse" from a terminal, I can see the menu is affected by the change I made to the .desktop file, so the /usr/share/applications/eclipse.desktop file somehow "relates" to the executable that is run by writing just "eclipse" from a command line.

  When I wrote "eclipse" into the Dash, the one I had manually
  downloaded and unzipped would run, which is somewhat funny in itself,
  because I wonder how it "finds" the one that I have installed in an
  arbitrary folder and it doesn't find the one that has been installed
  with the package manager.

  Then I did the following:
  - run "eclipse" from a terminal (this would run the apt-get installed one)
  - right click on the icon on the launcher and choose "lock to launcher".
  - exit eclipse
  - click on the icon that has been created on the launcher

  Expected: should run the same thing that was running when I locked it to the launcher, which is what I run from a terminal typing "eclipse"
  Observed: it runs the one that I had manually downloaded and unzipped.

  Whatever is going on, there is an inconsistency here. If I run some
  program, whatever I run it from, and then lock its icon to the
  launcher, then clicking on that icon must load the program that was
  running when I locked that icon on the launcher, whatever that is. Not
  some other version that is installed somewhere else.

  Then I deleted the folder ~/Documents/programmi/eclipse altogether.
  Now the icon on the launcher does nothing. Even if I remove it (unlock
  from launcher), start "eclipse" again from a terminal (which runs
  /usr/bin/eclipse), lock it to the launcher again, exit it, even so
  when I later click on the launcher icon it will launch nothing (as if
  "looking for" the one that I deleted).

  And surprisingly, when I type "eclipse" into the Dash, it still
  "finds" the old one, or at least, it finds something that won't run if
  I click on it. Even after restarting the computer.

  The only file named eclipse.desktop in the entire filesystem is the
  one under /usr/share/applications/eclipse.desktop

  
  It's as if by merely unzipping the .tar.gz file into an arbitrary non-standard folder, some kind of shortcut to it has been installed somewhere that allows it to be found when typing "Eclipse" into the Dash; even if I didn't install any package, just unzipped a .tar.gz file. Even after deleting the unzipped folder, that "link" somehow persists somewhere. It's crazy. And it even takes the place of the icon that I lock to Launcher when running /usr/bin/eclipse.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.10
  Package: unity 7.1.2+13.10.20131014.1-0ubuntu1
  ProcVersionSignature: Ubuntu 3.11.0-18.32-generic 3.11.10.4
  Uname: Linux 3.11.0-18-generic x86_64
  ApportVersion: 2.12.5-0ubuntu2.2
  Architecture: amd64
  CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
  Date: Mon Mar 24 20:08:39 2014
  InstallationDate: Installed on 2013-10-11 (164 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  MarkForUpload: True
  SourcePackage: unity
  UpgradeStatus: Upgraded to saucy on 2014-02-23 (29 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1296909/+subscriptions