I think the point is that in order for some templates to work properly, certain Custom BibTeX fields have to be set up, which are normally configured in Preferences->Default Field Preferences. Simon was looking for a way of setting these default fields in the templates.
One way of doing this would be to introduce "import custom fields/ types" functionality. This wouldn't put them in the templates, but would allow bundling of a file that could set the custom fields/types properly for the templates to work. This may not be a bad idea in general, seeing as different BibTeX replacement systems that rely on the same format but different or expanded fields and types could be more easily set. -AHM On 2008-05-22, at 1:04 PM, Adam M. Goldstein wrote: > I am pretty sure this won't satisfy Simon, but how about an "export > template" button somewhere? If the templates really are just text > files, then someone wanting to share templates could export them to > the desktop or somewhere else, and then someone else could drop it > into his or her BD configuration (perhaps wtih an "import template" > button somewhere?). > > I am coming in late to this discussion so I hope I am not missing the > point. > > -Adam > > On May 22, 2008, at 4:57 AM, Christiaan Hofman wrote: > >> >> On 22 May 2008, at 9:38 AM, Simon Spiegel wrote: >> >>> >>>>>> >>>>>> >>>>> I know that the template doesn't contain this information – yet. >>>>> But >>>>> how about putting the template files and a plist file with the >>>>> needed >>>>> information in a package ... Doubleclick it and everything gets >>>>> installed as it should ... >>>> >>> >>>> Which makes it even more of a hassle for a user to add templates. >>>> Moreover you'll get questions about what takes preference, and >>>> reports >>>> from users saying that their pref settings are ignored. Sorry, I'm >>>> not >>>> going into that wasp nest. >>> >>> My point is the following: Let's say I create a template for >>> "incollection". The chances that I will use this template for >>> anything >>> else but this specific entry type are very small IMO. So if a >>> mechanism could be established where a template can have a default >>> entry type I'd only see benefits. This default could always be >>> overruled by BibDesk preferences we already have, but I see little >>> potential conflict here. >>> >> >> It's more a question for the field type (like author or URL fields) >> than for type info. Note that the template editor accepts templates >> referring to unknown fields. It can just be rejected when the type of >> field does not match. >> >>> >>>> The type info is totally separate from the templates, logically and >>>> in the >>>> code. I don't see how you could move that with the templates. For >>>> the >>>> rest, it sounds like you want a separate document type? That would >>>> preclude >>>> easy editing of templates in TextEdit. However, if the template >>>> editor's >>>> state could be archived and saved such that they could always be >>>> reopened, >>>> maybe it could become the exclusive way to edit templates? >>> >>> How it would be technically solved, I don't know. I also wouldn't >>> mind >>> if it was a bit complicated to create such a template package. I'm >>> really more thinking about giving users who are not very tech savy a >>> way to easily use already existing templates. >>> >>> simon >> >> What I'm saying is that it would make it more difficult for the user >> to manage templates like this. And no way to change it by hand. Huge, >> enormous drawback. And I also say that it makes no difference: you >> still would not be able to use it properly, because the information >> is >> embedded in the program, and the program (in a general broad sense) >> does not know about the template. So the only thing you would gain >> is >> that you could open a few more templates in the template editor. >> That's certainly not worth the cost. >> >> Christiaan >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Bibdesk-users mailing list >> Bibdesk-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bibdesk-users > > > ================================= > Adam M. Goldstein PhD MSLIS > Assistant Professor of Philosophy > Iona College > -- > email 1 [EMAIL PROTECTED] > email 2 [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 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Bibdesk-users mailing list > Bibdesk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
