not handling local file URI as links

Yep, it's a very good idea! The patch looks good (except that a line should not be more than 76 char in order to write "good" python ;-) ). I haven't tested it yet.

Nicolas> Thanks for your patch! If you are not afraid of learning something new, try to use Bazaar for managing code. You can work on your patch, then commit, upload it and just provide link to this bug. Have a look at these tutorials:
  https://live.gnome.org/gtg/contributing
  http://doc.bazaar.canonical.com/latest/en/mini-tutorial/

Using Bazaar can save work for you and GTG developers :-)

------

I've merged Nicolas patch and add some other features as well:
  * if the address is not correct, it marks the link in a different color (right now red)
  * after drag'n'drop into task editor, task editor refreshes itself, so links to files are immediately recognized

I merged other requests for attaching files to GTG and now we have only one opened bug for that :-)

----------

In previous attempts to code this feature, somebody coded support for nice looking links:
  * instead of link URI is shown just the name of the file
  * file icon is shown

It looks better but:
  * a new type of link must be introduced into TaskEditor (there are some problem, e.g. pasing link into a link)
  * you are not able to change the link address from editor
  * you are allowed to remove characters from the name without changing address
  * file icons are just 2: direcotry/regular file what my be confussing
  * special serialization must be used (more code)

Link to that implementation: https://code.edge.launchpad.net/~chronitis/gtg/file-attach

-------------

What do you think? Is the implementation in lp:~gtg-user/gtg/file-attach2 enough for GTG needs? Do you have any troubles using this branch? Do we need file icons and shortening of those links?

Thanks for the pointers about bazaar.

About the file-attach branch:
  * it is indeed very good looking! To be yet better, I would suggest to show the icon related to the filetype.
  * It doesn't use gnome-open or xdg-open, but should be easy to fix
  * Not being able to change the link is not a big issue I think, even if it might add flexibility/usability, I don't see it as being *very* useful in my workflow right now. However, it seems to me that if a proper integration of such links is going to need a lot of code changes, it would be worth making a really well-designed way of manipulating it.
  * it seems to add some complexity to the code (disclaimer: i've not even had a look at it): I've seen at least 3 bugs in 5minutes of testing (spaces in filenames dispalyed as %20, file:/// being automatically replaced by an icon in specific situations, link without icon -- mignt be related to the previous one though)

My personal conclusion is that the idea is good, the way it is displayed adds a real impression of finition to the software. But that sentiment goes away with the points you raised and the bugs: it adds code for less flexibility.
For the moment I'd stay with my hack, although it's not very elegant, it works and is flexible enough.
On the long run, though, I'd go with an improved version of the file-attach branch. As I said, it gives a good "pro" experience.

After a discussion with ploum I am merging this branch to have at least a basic support for file handling. Feel free to open a new bug for more fancy version of this.

Solved in rev1058