Re: [Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Adam R. Maxwell

On Jan 13, 2008, at 2:33 PM, Holger Frauenrath wrote:

>> I don't understand this complaint (and regardless of the disclaimer
>> below, it is a complaint).  How could you see the PDF file before
>> without selecting or opening it?  If you're thinking of drag-and-drop
>> from the main table, add a "Local File" column and drag the paperclip
>> or click on it.
>
> I did not know this was possible now. As I said ... I have not had the
> time to take a detailed look at the new version.

We added that a couple weeks ago after users requested the ability to  
sort and see at a glance which entries had files associated.  Same  
thing exists for URLs, and I prefer it to the old system.

As during nightly build testing, I'd strongly urge people to try it  
out for a while before lamenting the apparent loss of features!

>>> Don't get me wrong: this is not a complaint. I followed the previous
>>> discussion and decided to stay quiet - so that's "my own fault".
>
>> If people on this list ignored the discussion over the last 4 months
>> we've been working on this and did not test the nightly builds, that
>> is your own fault.
>
> That is what I said.

I know; that was mainly for the rest of the people on the list who  
stayed quiet :).

regards,
adam

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


Re: [Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Holger Frauenrath
Hi Adam,

> I don't understand this complaint (and regardless of the disclaimer
> below, it is a complaint).  How could you see the PDF file before
> without selecting or opening it?  If you're thinking of drag-and-drop
> from the main table, add a "Local File" column and drag the paperclip
> or click on it.

I did not know this was possible now. As I said ... I have not had the  
time to take a detailed look at the new version.

>> Don't get me wrong: this is not a complaint. I followed the previous
>> discussion and decided to stay quiet - so that's "my own fault".

> If people on this list ignored the discussion over the last 4 months
> we've been working on this and did not test the nightly builds, that
> is your own fault.

That is what I said.

> Frankly, I'd suggest that the only place you'll
> find sympathy is in the dictionary... :)

I have plenty things that give me pleasure. :-)

Best regards
Holger



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


Re: [Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Holger Frauenrath
Hi Christiaan

> First of all: there *is* a definite need for it now, because it is
> *possible* to add more than one files to an item, which all can be
> auto-filed (the word 'possible' is crucial). So you need a way to
> make the name unique, otherwise they would overwrite each other. It
> is just a consequence of the new possibility.

I have a naming scheme "author+year+short journal+pages". This is a  
*systematic naming scheme, and it is unique for my PDF files (I see  
that it would not be in case I had more than one file per reference).  
My label is the same as my PDFfile name, as in the case of the  
original poster.

> It will *not* break your old naming scheme, it just has to be
> modified a little bit.

> In most cases when you already have a format that works, the only
> thing you'd want to do is add a "%u0" of "%n0" just before the file
> extension (I recommend your format always to end with "%u0%e" or "%n0%
> e"). This will use your old scheme when possible, but creates unique
> file names when needed.

Okay, I did not know this detail. I assumed that a unique letter would  
always be added. This would not be acceptable because the above naming  
scheme is used by all of my group members, in BibTeX/LaTeX, in Word/ 
Endnote, and for saving PDF files of literature to our group partition  
on the server; so it needs to be systematic (and should not rely on  
unique letters).

Holger


__
Dr. Holger Frauenrath
ETH Zurich
Department of Materials
Wolfgang-Pauli-Str. 10, HCI H515
CH-8093 Zurich
Switzerland

Phone: (+41) 44 633 6474
Fax:   (+41) 44 633 1390
Email: [EMAIL PROTECTED]
Web:   http://www.polychem.mat.ethz.ch/frauenrath/





-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


Re: [Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Christiaan Hofman

On 13 Jan 2008, at 11:17 PM, Christopher MacMinn wrote:

>>> I use the cite key as the local file name, so my custom file format
>>> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
>>> invalid because "Format for local file requires a unique specifier."
>>> I'm fairly certain that cite keys are required to be unique, so I
>>> think this is a bug.  Thoughts?
>>
>> Cite keys should be unique within a document, but it's not
>> guaranteed.  AutoFile needs a specifier that lets it create a unique
>> filename on disk, since the filenames on your disk are independent of
>> your document and cite keys.
>
> Hm.  So here's my problem -- for cite keys, I use something like
> "first author's last name"-"journal"-"year" followed by a lowercase
> letter if necessary for uniqueness.  I can't auto-generate them
> because I use my own quirky abbreviations for journal names (e.g.,
> "Journal of Fluid Mechanics" is "jfm", but "Annual Review of Fluid
> Mechanics" is "annrevfm").  Each cite key is unique, so I use them as
> autofile specifiers and all of my references live happily in a single
> folder on my disk.  Is there any way to achieve this in 1.3.13?
>

Yes and no. See also my other post. Note that the cite key generated  
this way is unique *for the publication*, but for files it has to be  
unique *for the file* (on disk). These are different requirements, in  
particular now that a publication can have several files. Just use "%f 
{Cite Key}%u0%e". This will most of the time create a file with the  
same name as the cite key, but if necessary (and only if necessary)  
makes it unique. And you'd want that anyway to avoid overwriting a file.

Christiaan

> I suppose that this is a lengthy way of asking, "Is there any way to
> have the cite key and the file name be the same?"
>
>> I think there was a post on this yesterday as well.
>
> Yes, I see that now -- sorry I missed it.  I apologize for the  
> overlap.
>
>
> Thanks very much for your help.
>
> Best, Chris



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


Re: [Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Adam R. Maxwell

On Jan 13, 2008, at 1:57 PM, Holger Frauenrath wrote:

>
> On Jan 13, 2008, at 10:43 PM, Adam R. Maxwell wrote:
>
>> Cite keys should be unique within a document, but it's not
>> guaranteed.  AutoFile needs a specifier that lets it create a unique
>> filename on disk, since the filenames on your disk are independent of
>> your document and cite keys.
>>
>> I think there was a post on this yesterday as well.
>
>
> I know that this is intended (new) behavior. But it also breaks my old
> and proven naming scheme for the PDF files (I only have PDF files
> attached to all references; therefore, there is no need for a "unique
> identifier" as part of the label name or file name) in the same way it
> does for the original poster and, as a matter of fact my whole way of
> dealing with the PDF files.

The fact that they're all PDF files is irrelevant.  The unique  
specifier is only added if a file with the newly generated name  
already exists on disk; if your filenames are unique already, as you  
say, you won't notice a difference.

> I have not had the time to look at the new
> version in detail (and probably will not have it in the near future)
> in order to find out how I can adapt my established to the new way of
> dealing with files. I must admit that I also do not like the fact that
> I have to select a reference now in order to see the PDF file and be
> able to click on it.

I don't understand this complaint (and regardless of the disclaimer  
below, it is a complaint).  How could you see the PDF file before  
without selecting or opening it?  If you're thinking of drag-and-drop  
from the main table, add a "Local File" column and drag the paperclip  
or click on it.

> Don't get me wrong: this is not a complaint. I followed the previous
> discussion and decided to stay quiet - so that's "my own fault".
>
> I just wanted to explain why I think that several other people are
> going to bring up problems like the one above, be it intended behavior
> or not.


If people on this list ignored the discussion over the last 4 months  
we've been working on this and did not test the nightly builds, that  
is your own fault.  Frankly, I'd suggest that the only place you'll  
find sympathy is in the dictionary... :)

-- 
adam

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


Re: [Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Christiaan Hofman

On 13 Jan 2008, at 10:57 PM, Holger Frauenrath wrote:

>
> On Jan 13, 2008, at 10:43 PM, Adam R. Maxwell wrote:
>
>>
>> On Jan 13, 2008, at 1:30 PM, Christopher MacMinn wrote:
>>
>>> Hey folks -
>>>
>>> I just installed BibDesk version 1.3.13, and it's giving me a hard
>>> time about the "local file format" I've been using for autofile.  I
>>> use the cite key as the local file name, so my custom file format
>>> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
>>> invalid because "Format for local file requires a unique specifier."
>>> I'm fairly certain that cite keys are required to be unique, so I
>>> think this is a bug.  Thoughts?
>>
>> Cite keys should be unique within a document, but it's not
>> guaranteed.  AutoFile needs a specifier that lets it create a unique
>> filename on disk, since the filenames on your disk are independent of
>> your document and cite keys.
>>
>> I think there was a post on this yesterday as well.
>
>
> I know that this is intended (new) behavior. But it also breaks my old
> and proven naming scheme for the PDF files (I only have PDF files
> attached to all references; therefore, there is no need for a "unique
> identifier" as part of the label name or file name) in the same way it
> does for the original poster and, as a matter of fact my whole way of
> dealing with the PDF files. I have not had the time to look at the new
> version in detail (and probably will not have it in the near future)
> in order to find out how I can adapt my established to the new way of
> dealing with files. I must admit that I also do not like the fact that
> I have to select a reference now in order to see the PDF file and be
> able to click on it.
>
> Don't get me wrong: this is not a complaint. I followed the previous
> discussion and decided to stay quiet - so that's "my own fault".
>
> I just wanted to explain why I think that several other people are
> going to bring up problems like the one above, be it intended behavior
> or not.
>
> Best regards
> Holger
>

First of all: there *is* a definite need for it now, because it is  
*possible* to add more than one files to an item, which all can be  
auto-filed (the word 'possible' is crucial). So you need a way to  
make the name unique, otherwise they would overwrite each other. It  
is just a consequence of the new possibility.

It will *not* break your old naming scheme, it just has to be  
modified a little bit.

In most cases when you already have a format that works, the only  
thing you'd want to do is add a "%u0" of "%n0" just before the file  
extension (I recommend your format always to end with "%u0%e" or "%n0% 
e"). This will use your old scheme when possible, but creates unique  
file names when needed.

Christiaan



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


Re: [Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Christopher MacMinn
>> I use the cite key as the local file name, so my custom file format
>> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
>> invalid because "Format for local file requires a unique specifier."
>> I'm fairly certain that cite keys are required to be unique, so I
>> think this is a bug.  Thoughts?
>
> Cite keys should be unique within a document, but it's not
> guaranteed.  AutoFile needs a specifier that lets it create a unique
> filename on disk, since the filenames on your disk are independent of
> your document and cite keys.

Hm.  So here's my problem -- for cite keys, I use something like  
"first author's last name"-"journal"-"year" followed by a lowercase  
letter if necessary for uniqueness.  I can't auto-generate them  
because I use my own quirky abbreviations for journal names (e.g.,  
"Journal of Fluid Mechanics" is "jfm", but "Annual Review of Fluid  
Mechanics" is "annrevfm").  Each cite key is unique, so I use them as  
autofile specifiers and all of my references live happily in a single  
folder on my disk.  Is there any way to achieve this in 1.3.13?

I suppose that this is a lengthy way of asking, "Is there any way to  
have the cite key and the file name be the same?"

> I think there was a post on this yesterday as well.

Yes, I see that now -- sorry I missed it.  I apologize for the overlap.


Thanks very much for your help.

Best, Chris

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


Re: [Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Holger Frauenrath

On Jan 13, 2008, at 10:43 PM, Adam R. Maxwell wrote:

>
> On Jan 13, 2008, at 1:30 PM, Christopher MacMinn wrote:
>
>> Hey folks -
>>
>> I just installed BibDesk version 1.3.13, and it's giving me a hard
>> time about the "local file format" I've been using for autofile.  I
>> use the cite key as the local file name, so my custom file format
>> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
>> invalid because "Format for local file requires a unique specifier."
>> I'm fairly certain that cite keys are required to be unique, so I
>> think this is a bug.  Thoughts?
>
> Cite keys should be unique within a document, but it's not
> guaranteed.  AutoFile needs a specifier that lets it create a unique
> filename on disk, since the filenames on your disk are independent of
> your document and cite keys.
>
> I think there was a post on this yesterday as well.


I know that this is intended (new) behavior. But it also breaks my old  
and proven naming scheme for the PDF files (I only have PDF files  
attached to all references; therefore, there is no need for a "unique  
identifier" as part of the label name or file name) in the same way it  
does for the original poster and, as a matter of fact my whole way of  
dealing with the PDF files. I have not had the time to look at the new  
version in detail (and probably will not have it in the near future)  
in order to find out how I can adapt my established to the new way of  
dealing with files. I must admit that I also do not like the fact that  
I have to select a reference now in order to see the PDF file and be  
able to click on it.

Don't get me wrong: this is not a complaint. I followed the previous  
discussion and decided to stay quiet - so that's "my own fault".

I just wanted to explain why I think that several other people are  
going to bring up problems like the one above, be it intended behavior  
or not.

Best regards
Holger



__
Dr. Holger Frauenrath
ETH Zurich
Department of Materials
Wolfgang-Pauli-Str. 10, HCI H515
CH-8093 Zurich
Switzerland

Phone: (+41) 44 633 6474
Fax:   (+41) 44 633 1390
Email: [EMAIL PROTECTED]
Web:   http://www.polychem.mat.ethz.ch/frauenrath/





-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


Re: [Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Adam R. Maxwell

On Jan 13, 2008, at 1:30 PM, Christopher MacMinn wrote:

> Hey folks -
>
> I just installed BibDesk version 1.3.13, and it's giving me a hard
> time about the "local file format" I've been using for autofile.  I
> use the cite key as the local file name, so my custom file format
> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
> invalid because "Format for local file requires a unique specifier."
> I'm fairly certain that cite keys are required to be unique, so I
> think this is a bug.  Thoughts?

Cite keys should be unique within a document, but it's not  
guaranteed.  AutoFile needs a specifier that lets it create a unique  
filename on disk, since the filenames on your disk are independent of  
your document and cite keys.

I think there was a post on this yesterday as well.

-- 
adam

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


[Bibdesk-users] Autofile problems with 1.3.13

2008-01-13 Thread Christopher MacMinn
Hey folks -

I just installed BibDesk version 1.3.13, and it's giving me a hard  
time about the "local file format" I've been using for autofile.  I  
use the cite key as the local file name, so my custom file format  
string was simply "%f{Cite Key}"... but now 1.3.13 says that this is  
invalid because "Format for local file requires a unique specifier."   
I'm fairly certain that cite keys are required to be unique, so I  
think this is a bug.  Thoughts?

Thanks!

Best, Chris MacMinn

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users