attach files to a task

Using a more generic url handler we could use file:// urls to attach
files.

Le mercredi 23 décembre 2009 à 11:32 +0000, Lionel Dricot a écrit :
> Public bug reported:
>
> It should be possible to attach to a given task all files related to
> that task.
>
> ** Affects: gtg
> Importance: Undecided
> Status: New
>

Before we can implement this feature, I would like to have an agreement on what the GUI should look like.

- How do you see the files attached to task ?

- How do you attach a file ? (drag-n-drop seems perfect to me)

- How do you remove a file from a task ?

- How do you open and save on your disk a file from a task ?

Le 10/01/2010 21:27, Lionel Dricot a écrit :
> Before we can implement this feature, I would like to have an agreement
> on what the GUI should look like.
>
> - How do you see the files attached to task ?
>
As the mimetype icon and the file path.
> - How do you attach a file ? (drag-n-drop seems perfect to me)
>
Drag and drop is fine. I think we should be able to attach a file in
typing its url as the same as we can add a web link.
> - How do you remove a file from a task ?
>
By erasing the url and perhaps with the right clic.
> - How do you open and save on your disk a file from a task ?
>
Left clic on the file open it.

Somewhere else it was suggested to allow filesystem URIs like in Tomboy/Gnote...I like that idea better than making GTG a file manager.

[Setting as wishlist since this is a new feature request]
[Setting as incomplete since there are several conceptual questions raised which do not have answers yet]

I have written a brief implementation of this feature. See lp:~chronitis/gtg/file-attach for code.

file://... URLs are recognised (or at least, recognised as easily as http URLs are). The file URL is then reformatted as a short name (file:///home/user/file.ext -> file.ext) and the appropriate icon displayed next to it. The link can be clicked to open the file in the default program (using xdg-open, as with other URLs).

File links are serialized as file://... URLs for storage and converted back on loading.

The automatic icon picking introduces a dependency on gnome.ui and gnomevfs. There are probably workarounds if this is unwanted.

This approach
    * supports drag and drop of files
    * introduces no new elements into the storage XML format
    * is slightly more friendly than displaying file://... URLs in full (which can be done with about 3 line's worth of changes)
    * requires no additional UI elements

Hi Gordon!
First of all, what you've done is *really* nice. I think the other developers will agree.

Before merging to trunk, though, there are a few bugs to shoot down. In my 5 minutes review, I've seen that:
- icons are always blank
- filenames with special character cannot be opened (e.g: output "No such file or directoryting file '/home/luca/a_b.txt").

I'll look at your code tonight so I can point out better/patch these issues.
Again, great work!
for the future, I'm thinking supporting natively also tomboy:// links

a tiny patch is here: lp:~gtg-user/gtg/file-attach/
I've found a bug, that can be reproduced like this:
1) drag and drop a file. sometimes, the file:// url is not recognized on the fly (which is also a bug)
2) press enter and backspace. the file is recognized, but the internal fileurl is set to <filename><enter><backspace>
3) opening such a file is impossible.

This one is probably a GTG bug (that existed before your work, for web urls) but it's quite noticeable, so it should be fixed before merging. I'll look at it over the weekend if you don't have time to do it.

I have merged that patch and added a couple more fixes to my branch: ( lp:~chronitis/gtg/file-attach )

* Drag and drop uses a customised handler to instantly format file:/ URLs (including multiple drops).
* Invalid file URIs should be stripped (to remove control characters)
* File tags now aren't lost if you edit the same line
* Icon fetching is implemented with both gnomevfs/gnome.ui and gio bindings (the former are technically deprecated), with ImportError testing
* Serialization checks that file:/ URLs aren't concated together (in which case neither would be recognised on load), adding spaces if necessary

However, there are probably still some cases where text editing around file tags will break them. Following the taskview code is rather hard, it's difficult to track down every case. Copy and paste for instance breaks tags (just copies the short name).

I tried Gordon's patch. Wow ! Congratulation it's realy a great one. I hope the branch will be merged with the trunk very soon.

Much that I would like this merged, the issue with certain text operations breaking the tags and causing the serialized output to not contain links should really be fixed first (ie, when you reload you see just the name of the file as plain text, not a link).

I haven't looked at it for a while but I'll have another go now I'm no longer on holiday. I have also added some support for note:// URLs from Tomboy. This works, but suffers the same deserialize/serialize issues.

Merging several file attachement bugs into one, please see bug #913251