Re: [Bibdesk-users] citekeys too easy to change

[Michael M. <mic...@ma...>]

Note that undo is excellent medicine for any accidental change.

I think that might be part of the reason why this problem has existed  
for almost five years without major complaint. (OK, undo is only a  
couple years old, but still.)

I have actually thought along these lines before - that the key field  
should be harder to edit.
I once mocked up a BibEditor UI that had the key uneditable, and you  
either had to autogenerate it or control-click on it to bring up a  
sheet. It didn't seem like a super-important change, but it does  
remove one more thing from the Tab loop, meaning faster navigation to  
the items you do want to edit.

One related question, changing the cite key doesn't trigger any other  
changes, right?
I mean, it doesn't auto-rename a file in any situation, does it?

-mike

On Aug 10, 2006, at 3:49 PM, Adam Maxwell wrote:

>
> On Thursday, August 10, 2006, at 02:27PM, Paul Ingraham, RMT  
> <pa...@va...> wrote:
>
>>>> change it again (or at least give me a warning).  This 'initially
>>>> blank but we'll let you accidentally change it' is just bizarre!
>>>
>>> Please clarify the last sentence, possibly with less colorful
>>> verbiage.
>>
>> I believe what he means is: in a system that dependends heavily on
>> the consistency of references to records in a database, it seems
>> peculiar that BibDesk does nothing to prevent accidental modification
>> of citekeys.
>
> OK...the "initially blank but" part is confusing, so I wanted to  
> make sure; some (many?) of our bugs come from users doing things  
> that we just didn't predict, or through preference combinations  
> that we don't test.  If there is a case where you have a blank key,  
> it's a bug (the next version won't allow you to leave an empty key).
>
>>> When creating a new record, the cite key is set to "cite-key" and
>>> you are warned to change it if you try to close an editor window.
>>
>> Which serves to ensure that citekeys are generated in the first
>> place, but of course does nothing to protect them once they are.
>>
>>> There probably should be a warning sheet for the generate command
>>> with the option to disable it.
>>
>> Yes, this seems quite important.
>
> Depends on your usage, I guess; no one's commented on it before,  
> and we have at least a couple of users :).
>
> Adam
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Bibdesk-users mailing list
> Bib...@li...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users



--
     Michael McCracken
     mic...@ma...
     http://michael-mccracken.net/