Re: [Bibdesk-users] differentiating multiple files
On Jan 7, 2008, at 8:35 PM, Alexander H. Montgomery wrote: > Actually, it's not about *visual* differentiation (which I can do), > but differentiation that can, say, be discerned by an AppleScript or a > Smart Folder. (For the record, 4938 refs, 3119 single files, and 304 > > 1 file). Thanks, that's a pretty important distinction! I hacked some trivial Finder label support in, but it'll be disabled until after the next release (if it ever does make it in) since it has the potential to kill performance. It'll take some work to make it aesthetically pleasing, also. You'd probably have to AppleScript Finder to get/set those labels, even if we do display them. It might be possible to use smart folders with Finder labels, but extending them to arbitrary tags would take some thought. > For example, I put together syllabi with an AppleScript that copies > references and PDFs to a separate directory for easy distribution. The > AppleScript can't tell the difference between a local file that is the > actual PDF and a local file that is a related PDF. But if I could tag > the correct local file (or, much easier, tag the incorrect ones!) then > an AppleScript or a smart folder could do it. My current smart folders > allow me to find articles that don't have PDFs (of the article) > easily; the new architecture doesn't. One suggestion is to reserve the first slot for the "actual" PDF. This is a drawback of having everything in one bag, but at least it's ordered. The tagging ideas will probably stay on the back burner for a while. I like xattrs and they're fast to read/write, but I'm not sure if it's worth the support costs... -- 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] differentiating multiple files
Actually, it's not about *visual* differentiation (which I can do), but differentiation that can, say, be discerned by an AppleScript or a Smart Folder. (For the record, 4938 refs, 3119 single files, and 304 > 1 file). For example, I put together syllabi with an AppleScript that copies references and PDFs to a separate directory for easy distribution. The AppleScript can't tell the difference between a local file that is the actual PDF and a local file that is a related PDF. But if I could tag the correct local file (or, much easier, tag the incorrect ones!) then an AppleScript or a smart folder could do it. My current smart folders allow me to find articles that don't have PDFs (of the article) easily; the new architecture doesn't. Now, I certainly don't think this needs to be in 1.3.13 (I already have a workaround for my scripts through script hooks: everything added to the local-url field is added automatically as a linked file, and vice versa if local-url isn't yet filled in) I'm partially thinking out loud about how the current metadata-in-a-file support in BibDesk (Skim notes!) could be expanded to include tagging files with other metadata. One way to do it would be to use Finder metadata; another just to store it in xattrs on each PDF. Of course, that might take forever to read in, so it might be easier (faster?) to do it within BibDesk instead. -AHM On 2008-01-07, at 7:57 PM, Derick Fay wrote: > Here are my #s: > 847 total refs. > 1 w 14 files (a complete book) > 1 w 13 files (a complete dissertation) > 1 w 6 files (a complete book) > 1 w 4 files (2 sets reading notes, two articles on the pub.) > 3 w 3 files > 12 w 2 files (all reading notes and text) > 205 w 1 file (a mix of reading notes and texts) > > and the balance with none (but this is largely because I imported 550 > or so items from an old Paradox database -- most will have files > added eventually; likewise many with one will have two). > > Or about 2% with >1 file. > > Looking through the items, I can differentiate each attachment from > the preview image, filename &/or file type (sorry Alex :) ) so it's > not a serious problem for me. > >> Alex, do you have a lot of references with multiple attachments, or >> is it a small percentage? I generally work with references that >> will have 1 or 2 attachments at most, so I'm interested in hearing >> about problems from others. I'd also like to make sure that it's >> a /real/ problem before solving it :). >> > > - > 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 > - 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] differentiating multiple files
Here are my #s: 847 total refs. 1 w 14 files (a complete book) 1 w 13 files (a complete dissertation) 1 w 6 files (a complete book) 1 w 4 files (2 sets reading notes, two articles on the pub.) 3 w 3 files 12 w 2 files (all reading notes and text) 205 w 1 file (a mix of reading notes and texts) and the balance with none (but this is largely because I imported 550 or so items from an old Paradox database -- most will have files added eventually; likewise many with one will have two). Or about 2% with >1 file. Looking through the items, I can differentiate each attachment from the preview image, filename &/or file type (sorry Alex :) ) so it's not a serious problem for me. >>> > Alex, do you have a lot of references with multiple attachments, or > is it a small percentage? I generally work with references that > will have 1 or 2 attachments at most, so I'm interested in hearing > about problems from others. I'd also like to make sure that it's > a /real/ problem before solving it :). > - 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] Differentiating between multiple attached files in BibDesk
On Jan 7, 2008, at 6:27 PM, Adam R. Maxwell wrote: > > On Monday, January 07, 2008, at 03:10PM, "Adam M. Goldstein" <[EMAIL > PROTECTED] > > wrote: >> On Jan 7, 2008, at 5:51 PM, Alexander H. Montgomery wrote: >> >>> I was just working with the new file view; it occurs to me that at >>> some point (not to hold up 1.3.13), it might be helpful for users to >>> be able to differentiate between the multiple attached files. For >>> example, I have articles, summaries of articles and books, and >>> tables >>> of contents attached as PDFs. Formerly I created multiple local-url >>> fields to handle this. > > Alex, do you have a lot of references with multiple attachments, or > is it a small percentage? I generally work with references that > will have 1 or 2 attachments at most, so I'm interested in hearing > about problems from others. I'd also like to make sure that it's a / > real/ problem before solving it :). > >>> One way of doing this is by color (a la the Finder's tags). BibDesk >>> wouldn't necessarily even store the information, it might just fetch >>> and show and possibly set (as each icon's background, for instance) >>> colors from the Finder. >>> >> >> It sounds like you might use this, but I personally have never been >> quite able to get the finder's different file types and corresponding >> color coding to work for me. > > It works for me, but I never use it. What do you mean about file > types? I can see how some people might like to display the Finder > label color, but we'll have to think about that. I'm hoping to get > the release out tonight or tomorrow (and likewise hoping we didn't > break anything today). > I don't mean that the feature is broken; it's just that I have never been able to use it the way it seems to be intended. You can color code your files according to label, so, for instance, once I tried to color code all PDFs that were readings for a class so that they would turn out red in various finder views; and I did this by assigning them a label in the finder and setting that label up so that all of its associated files had the red coloring. But there are only a few colors to use and I always had a hard time putting things in the right categories, so I gave up. = Adam M. Goldstein PhD MSLIS Assistant Professor of Philosophy Iona College -- email: [EMAIL PROTECTED] web:http://www.iona.edu/faculty/agoldstein/ tel:(914) 637-2717 post: Iona College Department of Philosophy 715 North Avenue New Rochelle, NY 10801 - 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] Differentiating between multiple attached files in BibDesk
On Monday, January 07, 2008, at 03:37PM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: > >On 8 Jan 2008, at 12:27 AM, Adam R. Maxwell wrote: > >> >> [snip] > >> It works for me, but I never use it. What do you mean about file >> types? I can see how some people might like to display the Finder >> label color, but we'll have to think about that. I'm hoping to get >> the release out tonight or tomorrow (and likewise hoping we didn't >> break anything today). > >Is the crossref problem solved than? No. I'll look at it later. I don't think it's worth holding up the release for, though. - 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] Differentiating between multiple attached files in BibDesk
On 8 Jan 2008, at 12:27 AM, Adam R. Maxwell wrote: > > [snip] > It works for me, but I never use it. What do you mean about file > types? I can see how some people might like to display the Finder > label color, but we'll have to think about that. I'm hoping to get > the release out tonight or tomorrow (and likewise hoping we didn't > break anything today). Is the crossref problem solved than? 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] Differentiating between multiple attached files in BibDesk
On Monday, January 07, 2008, at 03:10PM, "Adam M. Goldstein" <[EMAIL PROTECTED]> wrote: >On Jan 7, 2008, at 5:51 PM, Alexander H. Montgomery wrote: > >> I was just working with the new file view; it occurs to me that at >> some point (not to hold up 1.3.13), it might be helpful for users to >> be able to differentiate between the multiple attached files. For >> example, I have articles, summaries of articles and books, and tables >> of contents attached as PDFs. Formerly I created multiple local-url >> fields to handle this. Alex, do you have a lot of references with multiple attachments, or is it a small percentage? I generally work with references that will have 1 or 2 attachments at most, so I'm interested in hearing about problems from others. I'd also like to make sure that it's a /real/ problem before solving it :). >> One way of doing this is by color (a la the Finder's tags). BibDesk >> wouldn't necessarily even store the information, it might just fetch >> and show and possibly set (as each icon's background, for instance) >> colors from the Finder. >> > >It sounds like you might use this, but I personally have never been >quite able to get the finder's different file types and corresponding >color coding to work for me. It works for me, but I never use it. What do you mean about file types? I can see how some people might like to display the Finder label color, but we'll have to think about that. I'm hoping to get the release out tonight or tomorrow (and likewise hoping we didn't break anything today). >One thought that crosses my mind that is not particularly developer- >friendly I think is to create metadata for attached files. I have no >idea how that would work. So for instance one attached file could have >a type "TOC" or something like that. Sounds like even more complexity, and not real likely to happen. - 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] Differentiating between multiple attached files in BibDesk
On Jan 7, 2008, at 5:51 PM, Alexander H. Montgomery wrote: > I was just working with the new file view; it occurs to me that at > some point (not to hold up 1.3.13), it might be helpful for users to > be able to differentiate between the multiple attached files. For > example, I have articles, summaries of articles and books, and tables > of contents attached as PDFs. Formerly I created multiple local-url > fields to handle this. > > One way of doing this is by color (a la the Finder's tags). BibDesk > wouldn't necessarily even store the information, it might just fetch > and show and possibly set (as each icon's background, for instance) > colors from the Finder. > It sounds like you might use this, but I personally have never been quite able to get the finder's different file types and corresponding color coding to work for me. Also, in BD you can either use quicklook (in Leopard) or else enlarge the preview to see what the file is. A little testing shows that a moderate-to-small size preview gives enough resolution to make out the basic kind of thing a file is---a link to a web page, an article (JSTOR articles are particularly conspicuous), a book or something with a title page. I hate being negative about things but I would be interested in hearing how the color-coding scheme would work. One thought that crosses my mind that is not particularly developer- friendly I think is to create metadata for attached files. I have no idea how that would work. So for instance one attached file could have a type "TOC" or something like that. -Adam G = Adam M. Goldstein PhD MSLIS Assistant Professor of Philosophy Iona College -- email: [EMAIL PROTECTED] web:http://www.iona.edu/faculty/agoldstein/ tel:(914) 637-2717 post: Iona College Department of Philosophy 715 North Avenue New Rochelle, NY 10801 - 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] Differentiating between multiple attached files in BibDesk
I was just working with the new file view; it occurs to me that at some point (not to hold up 1.3.13), it might be helpful for users to be able to differentiate between the multiple attached files. For example, I have articles, summaries of articles and books, and tables of contents attached as PDFs. Formerly I created multiple local-url fields to handle this. One way of doing this is by color (a la the Finder's tags). BibDesk wouldn't necessarily even store the information, it might just fetch and show and possibly set (as each icon's background, for instance) colors from the Finder. Thoughts? -AHM - 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] [OT] How to crossref?
On Jan 7, 2008 6:51 PM, Niels Kobschaetzki <[EMAIL PROTECTED]> wrote: > On Jan 7, 2008 5:31 PM, Adam R. Maxwell <[EMAIL PROTECTED]> wrote: > > > > On Jan 7, 2008, at 4:57 AM, Jason Davies wrote: > > > > >>> > > >>> Makes sense. Thanks. But then why does the child item copy both > > >>> title > > >>> and booktitle? The title will always need to be replaced by the > > >>> child's specific title--at least this has been the rule in my use. > > >>> > > >>> Thanks, Ingrid > > >> > > >> The crossref feature does not interpret. It just copies. It's your > > >> responsibility to fill in the details as needed. > > > > > > for my sins, I didn't realise I could override > > > the inherited Title. In the past when I,'ve seen the greyed text > > > and the arrow, it has not allowed editing so I stupidly assumed > > > this was the case. In fact, of course, when I tried it, it > > > allowed me. > > > > Well, that's not stupidity on your part. That's us abusing standard > > user interface a bit to show that values are inherited. Suggestions > > on improving that are welcome. > > Just make the text black - the icon (the little arrow) should be > enough as a sign that it is inherited. The marking of the inherited > fields is not really necessary imho because those are autofilled > fields and auto-filled items have never a special mark (not that I can > remember at least). > And the arrow-icon for the link is at every inherited field anyway. > > Greyed text is usually a marker for not editable or not usable text/(menu) > items > > > Btw. I've just seen in 1.3.13 v988 that if I click the arrow, the > cross-referenced item opens, when I close the cross-referenced item > again the field with the icon of the item which includes the > cross-referenced is empty, until I click into the field again. > > > Niels I doubt whether the arrow alone is clear enough to show it's inherited. An arrow could lots of things. Note that also the Crossref field itself has an arrow, while it's not inherited. I disagree with your remarks on the text being auto-filled: the text is *not* filled in any way, the actual value of the field is empty. The text you see is only a marker to show you what bibtex would make of it. That's why it should be drawn differently IMHO. Moreover, with this remark in mind, inherited text is closer to a placeholder text. And that is consistently grayed out *and* editable in Cocoa. Also, in a sense the text is indeed not editable: you're not editing the inherited text you're seeing (the inherited text), but rather overwrite it. Also the disabled text in external items are not drawn in gray, only the editing is disabled and the border around the text field is slightly lighter (though that's quite subtle). 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] [OT] How to crossref?
On Jan 7, 2008 5:31 PM, Adam R. Maxwell <[EMAIL PROTECTED]> wrote: > > On Jan 7, 2008, at 4:57 AM, Jason Davies wrote: > > >>> > >>> Makes sense. Thanks. But then why does the child item copy both > >>> title > >>> and booktitle? The title will always need to be replaced by the > >>> child's specific title--at least this has been the rule in my use. > >>> > >>> Thanks, Ingrid > >> > >> The crossref feature does not interpret. It just copies. It's your > >> responsibility to fill in the details as needed. > > > > for my sins, I didn't realise I could override > > the inherited Title. In the past when I,'ve seen the greyed text > > and the arrow, it has not allowed editing so I stupidly assumed > > this was the case. In fact, of course, when I tried it, it > > allowed me. > > Well, that's not stupidity on your part. That's us abusing standard > user interface a bit to show that values are inherited. Suggestions > on improving that are welcome. Just make the text black - the icon (the little arrow) should be enough as a sign that it is inherited. The marking of the inherited fields is not really necessary imho because those are autofilled fields and auto-filled items have never a special mark (not that I can remember at least). And the arrow-icon for the link is at every inherited field anyway. Greyed text is usually a marker for not editable or not usable text/(menu) items Btw. I've just seen in 1.3.13 v988 that if I click the arrow, the cross-referenced item opens, when I close the cross-referenced item again the field with the icon of the item which includes the cross-referenced is empty, until I click into the field again. Niels - 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] [OT] How to crossref?
On Jan 7, 2008, at 4:57 AM, Jason Davies wrote: >>> >>> Makes sense. Thanks. But then why does the child item copy both >>> title >>> and booktitle? The title will always need to be replaced by the >>> child's specific title--at least this has been the rule in my use. >>> >>> Thanks, Ingrid >> >> The crossref feature does not interpret. It just copies. It's your >> responsibility to fill in the details as needed. > > for my sins, I didn't realise I could override > the inherited Title. In the past when I,'ve seen the greyed text > and the arrow, it has not allowed editing so I stupidly assumed > this was the case. In fact, of course, when I tried it, it > allowed me. Well, that's not stupidity on your part. That's us abusing standard user interface a bit to show that values are inherited. Suggestions on improving that are welcome. External items also display disabled in the same way, so I can see where this could cause problems. The crossref interface predates those. -- adam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] [OT] How to crossref?
On 7 Jan 2008, at 5:00 PM, Ingrid Giffin wrote: > > On 1/4/08 4:10 PM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: > >>> Makes sense. Thanks. But then why does the child item copy both >>> title and >>> booktitle? The title will always need to be replaced by the child's >>> specific >>> title--at least this has been the rule in my use. >>> >>> Thanks, >>> Ingrid >> >> The crossref feature does not interpret. It just copies. It's your >> responsibility to fill in the details as needed. >> >> Christiaan > > I do understand that it just copies. The question is, why does it > copy the > *title*? In my experience the booktitle, not the title, is the > information > that is needed in the child. If however there are cases in others' > experience where the title is indeed needed, then that is a > different story. > > Thanks, > Ingrid Please read the FAQ on that. It's simply the bibtex behavior for crossref, we only simulate it. Christiaan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] [OT] How to crossref?
On 1/4/08 4:10 PM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: >> Makes sense. Thanks. But then why does the child item copy both >> title and >> booktitle? The title will always need to be replaced by the child's >> specific >> title--at least this has been the rule in my use. >> >> Thanks, >> Ingrid > > The crossref feature does not interpret. It just copies. It's your > responsibility to fill in the details as needed. > > Christiaan I do understand that it just copies. The question is, why does it copy the *title*? In my experience the booktitle, not the title, is the information that is needed in the child. If however there are cases in others' experience where the title is indeed needed, then that is a different story. Thanks, Ingrid - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Bibdesk terminology
On Jan 7, 2008, at 1:14 AM, Justin C. Walker wrote: > > On Jan 4, 2008, at 17:08 , Adam R. Maxwell wrote: > >> >> On Friday, January 04, 2008, at 04:56PM, "Justin C. Walker" >> <[EMAIL PROTECTED]> wrote: >>> Hi, all, >>> >>> I've been fiddling with a recent nightly build (Version 1.3.12 >>> (v987)), and wanted to add some refs to my database. The 'help' >>> says, roughly, "go ahead and drag `em in". >>> >>> Two questions: >>> - the help refers variously to the "database" and "publications" >>> window. Are these the same? And, are these the window containing >>> the (column) listing of the entries in the database? >> >> That sounds right; this is the main document window that has >> columns and groups. It would be great if someone wanted to clean >> up the terminology in the help...Texinfo is pretty easy. > > Not knowing anything about "Help", is that written in Texinfo, and > turned into "Mac Help" during the build? Yes; Apple's Help is just HTML with some special tags. Theoretically we could turn the help into a PDF document as well, but it didn't work the last time I tried... -- adam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] [OT] How to crossref?
>> >>Makes sense. Thanks. But then why does the child item copy both title >>and booktitle? The title will always need to be replaced by the >>child's specific title--at least this has been the rule in my use. >> >>Thanks, Ingrid > >The crossref feature does not interpret. It just copies. It's your >responsibility to fill in the details as needed. for my sins, I didn't realise I could override the inherited Title. In the past when I,'ve seen the greyed text and the arrow, it has not allowed editing so I stupidly assumed this was the case. In fact, of course, when I tried it, it allowed me. Sorry for wasting everyone's time:-) (but it seems to have cleared it up for a few others at least). thanks again. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Bibdesk terminology
On Jan 4, 2008, at 17:08 , Adam R. Maxwell wrote: > > On Friday, January 04, 2008, at 04:56PM, "Justin C. Walker" > <[EMAIL PROTECTED]> wrote: >> Hi, all, >> >> I've been fiddling with a recent nightly build (Version 1.3.12 >> (v987)), and wanted to add some refs to my database. The 'help' >> says, roughly, "go ahead and drag `em in". >> >> Two questions: >> - the help refers variously to the "database" and "publications" >> window. Are these the same? And, are these the window containing >> the (column) listing of the entries in the database? > > That sounds right; this is the main document window that has > columns and groups. It would be great if someone wanted to clean > up the terminology in the help...Texinfo is pretty easy. Not knowing anything about "Help", is that written in Texinfo, and turned into "Mac Help" during the build? >> And finally, when I drag a file containing a bibtex entry onto the >> 'central' window, I get this file added to the entry I drop the file >> onto, instead of getting a new entry. What am I missing? > > Try moving your file around until the entire tableview is > highlighted (between rows or near the edge). If a row is > highlighted, it adds to that row. If the entire table is > highlighted, it adds a new ref. Dropping on a group might be an > easier target. The drop highlight should give you a pretty good > idea of what it's going to do, though. Oh, duh! It was in the doc, but I saw right past it... Thanks for the help. Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- If it weren't for carbon-14, I wouldn't date at all. --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
