Re: Templates (Was: Re: File Useability question)

[Uli Kusterer]

In article <mailman.251.1077389154.340.discuss-gnustep@gnu.org>,
 Stefan Urbanek <stefan@agentfarms.net> wrote:

> What do you think about this very rough idea similar to MS Windows one:
> 
> There will be a well defined place, where templates are put. Like 
> */Library/Templates, plus GWorkspace will search .app bundles for additional 
> ones (caching them, probably). When you do "New file" you will be presented 
> with a panel with files (in a list/icons/whatever useable) that you can 
> create. In other words, user will see a set of "templates" or "prototypes".

 Drat, you beat me to it. Just before I got this message, I posted a 
similar idea :-)

 But allowing applications to include default templates in their bundle 
is a great idea! Hadn't thought of that. However, it should be possible 
for the user to sort their own templates to the top, and applications' 
templates should probably be in their own collapsible section (think: 
tree view). Otherwise, the list of templates may be full of templates 
the user never uses, just because those applications are installed.

 I.e. an NSOutlineView with */Library/Templates/ templates at the top, 
and then an entry for each application that has templates in its 
foo.app/Contents/Resources/Templates/ directory, which can be 
uncollapsed to show those templates.

 If the UI also allowed re-arranging the items in that list (i.e. drag a 
template from an application's subentry to the top - which could create 
a symlink to that template in ~/Library/Templates/), that would be quite 
flexible.

> corresponding applications (hint: roles/defaults can be used here :-). User 
> does need to know which application to use to create/edit those files he 
> wants - gworkspace already knows that!

 I would like to voice my vote for this (if I get one, that is). The 
user shouldn't have to enter the file suffix. Many users probably don't 
care about the suffix and just want to create "a gimp file" or whatever. 
The above approach would solve that easily, and at the same time provide 
enough flexibility, and be easy to implement.

Cheers,
-- Uli
http://www.zathras.de