Ross Gardler wrote:
> Cyriaque Dupoirieux wrote:
>> le 07/06/2006 13:23 [EMAIL PROTECTED] a écrit :
>>
> 
> ...
> 
>> Ok, You have totally removed the previous text, but I think
>> information were useful - declaration of the location of the new copy,
>> share between several projects, order of the declaration.
>> Can't we merge both versions ?
> 
> You beat me to it. I was going to mail on this subject...
> 
> When I came to do the merge I thought better of it. The main problem I
> have is with the fact that copying a plugin, as you suggested, results
> in a conflict of plugin names. This is in contradiction of the naming
> convention which requires a world unique name.
> 
> I tried to think of a use case where such a forking would be necessary.
> I couldn't think of any. Either the use case is sufficiently different
> that it warrants a new plugin. Or it is sufficiently similar that it
> should be added to the existing plugin. 

I recently used the photo-gallery plugin.
I had support PNG (sufficiently similar to be added to the plugin).
I also changed the appearance of the filename "buttons":
  they were generated with svg and our long filenames didn't fit.
  This is a matter of taste ...
  How would I adapt this?
  It's not sufficiently different and yet a "matter of taste" how to
  display the file name (I know your answer: make it configurable ;-)

Johannes


> I'm -1 on appearing to encourage
> users (and this is a user doc) to fork our code.
> 
> The idea of adding a plugin to a project directory also smells of bad
> practice to me. One of the goals of Forrest is to separate the concerns
> of the content designer, the content publisher and the developer. A
> plugin has, IMHO, no place inside the content. Therefore, all plugins
> should be in an external directory. Regardless, this discussion has no
> place in a users document, but should be in the developers
> documentation, so I stripped it and intend to add it to the developer docs.
> 
> With respect to adding the location of the plugins to the users
> forrest.properties file I initially thought this a bad idea. However, in
> trying to explain my reasoning in this reply I realised  I had
> misunderstood the point you were making. You are right to put this
> information in a user doc. I'll correct that in a few minutes.
> 
> Is this OK?
> 
> Ross
> 
> 
> 

-- 
User Interface Design GmbH
Teinacher Str. 38, 71634 Ludwigsburg
Fon:      +49-7141-37700-0
Fax:      +49-7141-37700-99
Email:    [EMAIL PROTECTED]
Internet: www.uidesign.de

Geschäftsstellen:
Teinacher Str. 38,    71634 Ludwigsburg
Truderinger Str. 330, 81825 München
Friedrichsring 46,    68161 Mannheim

Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de

Attraktivität von interaktiven Produkten messen mit
www.attrakdiff.de