Comment 1 Erik Forsberg 2007-03-19 14:26:07 CET

Swedish summary: Automatisk associering av applikationer som körs via
windowsterminalserver från applikationer på Linux - klick på word-dokument i
mailäsare på Linux ska kunna starta Word via WTS.

Comment 2 Erik Forsberg 2007-03-26 10:19:37 CEST

Clarifying this bug - it's about associations on the Linux desktop run against
Xvnc, which should be able to start applications on WTS/Citrix.

Bug 2429 and bug 2430 deal with the situation where associations on the client
start applications on the ThinLinc server. 

Comment 3 Erik Forsberg 2007-03-27 13:21:53 CEST

To solve this, we need to find out how to associate applications we add to
mime-types and file extensions. We might not have to find out how to educate KDE
and Gnome to use them - that can be done via Kiosktool/Sabayon/etc.

Unfortunately, the file association systems in Linux is a can of worms.

Crossover manages to create file associations, so we can look at their tools for
some inspiration. /opt/cxoffice/bin/locate_gui.sh prints an interesting list of
paths in use. It seems like crossover updates /etc/mailcap (for legacy
software), adds files to /usr/share/mime-info (for gnome) and
/usr/share/mimelnk/ (for KDE).

There is an freedesktop standard, shared-mine-info-spec, but it says that "
KDE is planning to support it for their next major release.". It is however used
by Gnome 2.8 and later. 

Probably, the best solution is to do what Crossover does - after all, Francois
Gouget is one of the main contributors to many freedesktop standards. 

We also need to find out how to ensure that the application on the WTS can open
the file. One idea is to use the RDP drive redirection and export either / as
'unixroot', or some other directory, and then use the path to the RDP "share"
when calling the program.

Tricky bug. Rough time est.  

Comment 4 Karl Mikaelsson 2014-01-09 11:09:12 CET

The file association mess has largely gone away with the advent of xdg and freedesktop standards, but there are still a couple of problems left with associating a WTS application to a mimetype:

 1. Making sure that the WTS can read the file in question
 2. Quoting the filename to make it work with the remote app

As discussed on todays devmeeting, a "tl-run-winapp-openfile" (or whatever) utility could perform this task with the help of a bit of configuration.

As for problem 1, you could rely on sharing a network filesystem between the Windows and Linux boxes or let rdesktop create a new shared folder. The network filesystem approach requires some kind of translation as Unix paths won't be found on Windows. We thus need to be able to tell this utility which paths are mounted where. In my example below there are keys (of unix paths) and values (of windows paths) where files are expected to be the same. I've allowed for a magic HOME key, which would then mean the home folder of the user.

  [/appservergroups/application_filename_translation/]
  HOME=H:
  /shared=Z:

Next up is the file name quoting, which as stated on bug 4954 is impossible to solve in a generic way. There are two options here - either have the quote format be given to the utility on the command line or read it from a configuration file. Again, here's an example config file - key is application name, value is how to quote the filename, with a magic %s marker to be replaced by the actual filename.

  [/appservergroups/application_filename_quoting/]
  winword.exe = "%s"
  notepad.exe = %s
  whatever.exe = '%s'

The principle would be the same for passing the quote format on the command line.

Comment 6 Pierre Ossman 2022-02-23 11:09:19 CET

We no longer have any integration with Windows servers since bug 7279.