Default folder for files

[Miguel Pagano]

Hi all,

I'm starting to use Referencer and I was kindly surprised
that I can throw in Referencer a link and Referencer will
download the link for me and save it in "~/Downloaded Documents".
I think it would be nice to have a property of each library
to indicate where to download a file.

This can also be useful in other use case I have: I usually
put the papers I read in some folder (v.g., "~/papers/cs").
Then if I'd like to cite some which wasn't in the library,
I add the paper to the library (by adding the file). And always
Referencer launches the file chooser in ~, or worst in
some folder like / or /usr/share/...

I've added manually an attribute "docs_home" that
defines which is the folder where the files for this
library are. Does this make sense for other people?

Also, a more general question: how would be the best
form of defining attributes for a library? From what I've
seen, there is yet no attribute for the library. Is this because
you think there shouldn't be any attribute associated with
the library? Or is it just because you haven't needed it yet?

Thanks for a nice program.
Best regards,
Miguel

[John Spray]

Post by Miguel Pagano
Hi all,
I'm starting to use Referencer and I was kindly surprised
that I can throw in Referencer a link and Referencer will
download the link for me and save it in "~/Downloaded Documents".
I think it would be nice to have a property of each library
to indicate where to download a file.

To quote my own code in DocumentView.C:
610 /*
611 * THIS IS ALL BOLLOCKS
612 * Really we should just show the user a save dialog
and let him choose
613 */
614
615 Glib::ustring destinationdir;
616 if (liburi) {
617 destinationdir =
618 liburi->get_scheme ()
619 + "://"
620 + Glib::build_filename (
621 liburi->extract_dirname (),
622 _("Downloaded Documents"));

Apologies for the profanity, but it's accurately used :-)

Post by Miguel Pagano
This can also be useful in other use case I have: I usually
put the papers I read in some folder (v.g., "~/papers/cs").
Then if I'd like to cite some which wasn't in the library,
I add the paper to the library (by adding the file). And always
Referencer launches the file chooser in ~, or worst in
some folder like / or /usr/share/...

One of the features I'm halfway through implementing (shelved it in
favour of other more obscure projects a while back) is a "managed
directory" for a library where pdfs dropped in that directory are
automatically added -- this would also be where the downloaded documents
would drop.

Post by Miguel Pagano
I've added manually an attribute "docs_home" that
defines which is the folder where the files for this
library are. Does this make sense for other people?

Yes, that's the right idea. There is actually a <library_folder> tag in
the file format which isn't exposed anywhere because I'm a horrible
person and only got halfway through doing that piece of code. I shipped
a release with the GUI bits for this hidden in order to get other bug
fixes out.

Post by Miguel Pagano
Also, a more general question: how would be the best
form of defining attributes for a library? From what I've
seen, there is yet no attribute for the library. Is this because
you think there shouldn't be any attribute associated with
the library? Or is it just because you haven't needed it yet?

I'm not sure in what sense you're using "attributes" -- currently there
are things like <manage_target> and the aforementioned <library_folder>
which map to the manage_target_ and library_folder_uri_ members of the
Library class in src/Library.h. A more general mechanism would be
possible, but since special-case behaviour in the GUI is required for
anything like that I would question the utility of a generalised
mechanism -- I prefer to define XML tags rather than defining valid
values for a generic map. But perhaps I'm not understanding you
correctly.

John

[Miguel Pagano]

Post by John Spray
612 * Really we should just show the user a save dialog
and let him choose
Apologies for the profanity, but it's accurately used :-)

Ok, I think is nicer the idea of the managed directory.

Post by John Spray
One of the features I'm halfway through implementing (shelved it in
favour of other more obscure projects a while back) is a "managed
directory" for a library where pdfs dropped in that directory are
automatically added -- this would also be where the downloaded documents
would drop.

Nice!

Post by John Spray

Post by Miguel Pagano
I've added manually an attribute "docs_home" that
defines which is the folder where the files for this
library are. Does this make sense for other people?

Yes, that's the right idea. There is actually a <library_folder> tag in
the file format which isn't exposed anywhere because I'm a horrible
person and only got halfway through doing that piece of code. I shipped
a release with the GUI bits for this hidden in order to get other bug
fixes out.

Ok, I should look more carefully in the code. (Why a tag? See below).

Post by John Spray

Post by Miguel Pagano
Also, a more general question: how would be the best
form of defining attributes for a library? From what I've
seen, there is yet no attribute for the library. Is this because
you think there shouldn't be any attribute associated with
the library? Or is it just because you haven't needed it yet?

I'm not sure in what sense you're using "attributes" -- currently there
are things like <manage_target> and the aforementioned <library_folder>
which map to the manage_target_ and library_folder_uri_ members of the
Library class in src/Library.h. A more general mechanism would be
possible, but since special-case behaviour in the GUI is required for
anything like that I would question the utility of a generalised
mechanism -- I prefer to define XML tags rather than defining valid
values for a generic map. But perhaps I'm not understanding you
correctly.

Attribute in my sentence has two meanings: an attribute in the XML
file and this attribute seen as a member in the corresponding class.
Sorry for being ambiguous. With respect of using attributes or tags, I
think that a path looks like something which should be in an attribute.
Again it seems that I've overlooked some things or that the source
I've get from debian is not up-to-date.

I'll try to read more carefully the (last version of the) code and see if I
can get my feature done in a right way. I'd very grateful if you give
me any suggestion on how to start, or how to avoid you the need of
profanities ;).

[jcspray]

Post by Miguel Pagano

Post by John Spray
I'm not sure in what sense you're using "attributes" -- currently there
are things like <manage_target> and the aforementioned <library_folder>
which map to the manage_target_ and library_folder_uri_ members of the
Library class in src/Library.h. A more general mechanism would be
possible, but since special-case behaviour in the GUI is required for
anything like that I would question the utility of a generalised
mechanism -- I prefer to define XML tags rather than defining valid
values for a generic map. But perhaps I'm not understanding you
correctly.

Attribute in my sentence has two meanings: an attribute in the XML
file and this attribute seen as a member in the corresponding class.
Sorry for being ambiguous. With respect of using attributes or tags, I
think that a path looks like something which should be in an attribute.
Again it seems that I've overlooked some things or that the source
I've get from debian is not up-to-date.

To be honest, I didn't put a lot of through into whether it should be
an attribute or a tag. For a monitored directory (the
'library_folder'), I would stick with a tag for the following reasons:
* A library might monitor more than one directory
* Multiple monitored directories might have varying properties such
as a glob for which kinds of files to include.

A download directory is clearly a singular thing, and I can't imagine
it having extra properties, so it could very well be an attribute. I
am no XML purist, so whichever way it's done won't upset me.

Having had that little internal debate I now realise that a monitored
directory and a download directory ought to be distinct locations.
Perhaps at this stage it has become worthwhile to have a single
"Library Properties" dialog or so, for the following settings:
* Managed bibtex file
* Monitored directory
* Download directory

Aside from the directory configuration, another very nice thing to
have would be some logic in the download process to recognise whether
something is a document file, or metadata like a bibtex file.

John