On 22 May 2008, at 10:46 PM, Alex Montgomery wrote: > 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. >
But note that there are 2 completely separate parts: - The role of special fields (like person or URL fields) - The types and fields info The latter can actually pretty easily be distributed, as it is stored in a file in Application Support (~/Library/Application Support/ BibDesk/TypeInfo.plist). The former is a bit harder, because it is stored in the preference file. > 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 > But are there many different systems? So is there another effective standard apart from bibtex and biblatex? And how much of a standard is biblatex ATM? Perhaps we could add an easy choice for either of these two default settings (with some custom stuff thrown in, as is also currently the case), and leave other settings to the user, in the Advanced section of the prefs. I think that could cover it for most users, while allowing the current flexibility for advanced users. Christiaan > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
