Symlinks not resolved

[ollanta]

Symlinks are not resolved, making applications launched through them appear in docky with the default application icon.
Reproduce by creating a symlink to any application and launching the application through it, alternatively (in ubuntu at least) compare the docky response to launching emacs and emacs22-gtk (the former launches the latter through symlinks).

Debug output for launching emacs:
[Warn 13:28:22.681] [DrawingService] Failed to load icon resource emacs from assembly ollanta-eee: Operation is not valid due to the current state of the object
[Debug 13:28:22.694] [DrawingService] at System.Linq.Enumerable.First[Assembly] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000]
  at System.Linq.Enumerable.First[Assembly] (IEnumerable`1 source, System.Func`2 predicate) [0x00000]
  at Docky.Services.DrawingService.IconFromEmbeddedResource (System.String name, Int32 width, Int32 height) [0x00000]
[Info 13:28:22.695] [DrawingService] Could not find 'emacs@ollanta-eee', using fallback of 'application-default-icon'.
[Warn 13:28:22.804] [DrawingService] Failed to load icon resource emacs from assembly ollanta-eee: Operation is not valid due to the current state of the object
[Debug 13:28:22.804] [DrawingService] at System.Linq.Enumerable.First[Assembly] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000]
  at System.Linq.Enumerable.First[Assembly] (IEnumerable`1 source, System.Func`2 predicate) [0x00000]
  at Docky.Services.DrawingService.IconFromEmbeddedResource (System.String name, Int32 width, Int32 height) [0x00000]
[Info 13:28:22.804] [DrawingService] Could not find 'emacs@ollanta-eee', using fallback of 'application-default-icon'.

Using:
ubuntu 9.10
docky 2.1.0 r1204

[Robert Dyer (psybers)]

This might be hard or impossible to do.

For specific issues (such as your emacs one), perhaps this can help you out:

http://wiki.go-docky.com/index.php?title=How_to_Customize_Window_Matching

[Chris S. (cszikszoy)]

This isn't because symlinks aren't being resolved. It's because we were trying to get the icon from the window title, and the window title contained an '@', which is the marker we use to try to extract an icon from an embedded resource. That was obviously failing (because there was no embedded resource).

We've changed the way we grab icons from unmatched windows, however, so this shouldn't happen anymore.

[Robert Dyer (psybers)]

No Chris, I specifically tested this. Symlinks are not being resolved in the matcher. Perhaps that trace given is not observing this problem but trust me, it is a valid bug report.

[Chris S. (cszikszoy)]

This should be easy to fix, now that everything is using GLib.File. I need to rework some of the FileExtension methods to follow symlinks by default, and not to on request (right now the default is to not follow symlinks, but through an override you can follow them).