r23397 - gnucash/trunk/src - Bug 336843: Attach images/files/urls to transactions.

[Patrick]

Indeed I assumed that gvfs wasn't available on non-linux/gnome
platforms, hence my (failed) attempt at implementing the win32/mac
code sections.

Someone commented earlier that the import/associate functionality used
by the open-source project "Shotwell" would be a good model. I'd be
inclined to agree. Giving the user an option to choose between
importing (copying) or just linking to an existing file would be
preferable, in my opinion.

More immediately, I just test-drove 2.5.8 and found that the
"Associate Location" option brings up a dialog to select a file as
well as enter a URI. (The former appearing to be unused). I'd looked
for an integrated chooser so that only one option "Associate" would be
necessary, however I was unable to find one. Comparing with "gimp" I
regarded their use of differing options as a validation that two
selection paths were necessary (file and URI).

In any case, the gtk dialog call in
default_associate_handler_location() was changed to
gtk_file_chooser_dialog_new()
 from my best guess of gtk_dialog_new_with_buttons(). This change
added a file chooser to the URI dialog, which appears superfluous.

Cheers,
Patrick

On Mon, Nov 18, 2013 at 3:02 PM, Geert Janssens
<janssens-geert at telenet.be> wrote:
> On Sunday 17 November 2013 10:19:10 John Ralls wrote:
>
>> On Nov 17, 2013, at 9:02 AM, Geert Janssens <janssens-geert at telenet.be>
>> wrote:
>
>> > On Sunday 17 November 2013 08:13:21 John Ralls wrote:
>
>> > > Geert,
>
>> > >
>
>> > > When I tested it on a Mac, gtk_show_uri failed because it depends
>
>> > > on
>
>> > > gvfs which isn't at present a GC dependency, so please at least
>
>> > > put
>
>> > > back the Mac bit -- which I'd already fixed so that it works.
>
>> > >
>
>> > > If you can get it to build and work on Win32 without resorting to
>
>> > > Win32 calls, great, but let's not add any new Gnome dependencies.
>
>> >
>
>> > If I understand this correctly, gvfs is only required for non-local
>
>> > uris. What I did for Windows was enforcing local-only uris and then
>
>> > using gtk_file_chooser_get_filename instead of
>
>> > gtk_file_chooser_get_uri.
>
>> >
>
>> >
>
>> > But my test box is taking too long to complete the build. I'm out of
>
>> > time for today.
>
>> >
>
>> > John, if you want to do a release, the quickest solution is to
>
>> > replace INT_PTR with int in gnc-gnome-utils.c.
>
>> >
>
>> > I have seen several examples like this on the net. I'll push my
>
>> > changes for 2.5.9 if/when I get it sorted out. These changes
>
>> > shouldn't conflict with the string/feature freeze.
>
>> Geert,
>
>>
>
>> The error message implied that gvfs was required to figure out what
>
>> type of file was being opened, but that's actually not material
>
>> because Patrick's UI includes an "associate URL" menu item that
>
>> presents a dialog to enter an unrestricted URL.
>
>>
>
>> I'll fix the win32 case and do the release; we can figure out what to
>
>> do next when you have time.
>
>>
>
>> Regards,
>
>> John Ralls
>
>
>
> My test build finished. Using local-only filenames instead of uri's doesn't
> fix the problem.
>
> Regardless of the input (local-only filename of full uri), gtk_show_uri
> errors out with "URI's are not supported).
>
>
>
> This looks like a bug in gio to me. It seems to take the presence of a ":"
> in the path to automatically mean the path is a full uri. This is obviously
> not correct for absolute pathnames on Windows.
>
>
>
> Perhaps adding gvfs will fix this. But given the added functions are pretty
> short and clear, I don't think it's worth now trying to add gvfs. So I won't
> go into this any further. There are more pressing and important matters to
> deal with.
>
>
>
> Perhaps one day I'll check if adding gvfs support in GnuCash adds sufficient
> benefit to make it worth (if we haven't switched gui frameworks by then ;)
> ).
>
>
>
> Geert