[PD] messing with help-patches

[Roman Haefeli]

ciao frank

On Mon, 2006-08-21 at 08:48 +0200, Frank Barknecht wrote:
> Hallo,
> Roman Haefeli hat gesagt: // Roman Haefeli wrote:
> > since the helppatches cannot be reached from the helpbrowser, when they
> > are located in pd/extra, 
>
> This must be another bug of the help browser: It doesn't seem to care
> about user-settings regarding -help-path.

for me it is not obvious that the helpbrowser is suppoesed to show all
-helppathes, but i am not the developer of it and therefore cannot tell
what it is intended to do. a statement on that from the developer would
be nice (miller?). but i think such a feature would solve a lot
problems.
 
> I don't think the location of the help-patches should be used to get
> an overview of the objects in a library. There is no direct connection
> between these two attributes, it would be artificial and error prone
> to create one IMO. Still for making installation and packaging easier,
> subdirs for every library have advantages.
> 

of course, it would be error prone, but what other way is there to find
out all the objects of a certain library? i see only two ways: looking
into the helppatches or visiting the website of the external, if there
is one (not having the possibility in pd itself to view the content of
an external is kind of awkward, IMO)

> > from the users point of view the following points would make life easy:
> > - helppatches of the libs are located in pd/doc/5.refernece/<lib>
> 
> Possible. pd-extended generally works that way IIR. However you need
> to use pd-extended's "-libdir" extension (or is this already in 0.40)
> to make it work when using directory prefixes.

'possible' is not the answer i was looking for. finally i don't care
much, where the helppatches are located, but it would be nice if there
is a standard and if developer of externals would follow that standard.
the situation as it is now is not quite satisfying from a users point of
view.

> > the only problem i see here, is that one has to add an extra -helppath
> > for each lib. it would be nice, if that could be avoided by searching
> > pd/doc/5.reference recursively.
> 
> No, this would break a lot of things, especially directory prefixed
> names like [maxlib/scale].

i see, although this is only a problem in pd-extended, afaik. that means
there is no other way than having to add an extra -helppath for each
external. since the good ol' .pdrc has been considered to be deprecated
many times , iirc, and i couldn't find a way to add a -helppath through
the menu, this concept seems to be problematic.
 

> For my abstractions I like to keep it simple and I just place the help
> patches next to the original abstractions. 
this is a nice approach, imo. 
 
> NB: I think, we should not try to organize the file layout by looking
> at the current help browser. IMO the browser has a broken design,
> because it's just a filebrowser limited to a certain directory, and
> it's a worse filebrowser than the builtin Tk filebrowser was. A real
> help browser should look different anyways. What I have seen in
> DesireData is going in the right direction IMO, but it's a radical
> change, os don't hold your breath. 

i am just looking for a good way to organize the helppatches. it seems
that now everybody just fights him/herself through this jungle on its
own... ;-)

ciao
roman


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de