[PD] helpbrowser and the paths

IOhannes m zmoelnig zmoelnig at iem.at
Tue May 3 10:54:12 CEST 2011

Hash: SHA1

while preparing a debian package of Gem, i stumbled across a
help-browser weirdness, which i'm not sure how to fix.

the background: Gem comes both as a big binary (Gem.pd_linux) and a
number of abstractions. everything is installed into /u/l/p/extra/Gem
(to avoid cluttering the global filespace with Gem files); in order to
use the abstractions painlessly (that is: without prefixing them
"Gem/"), the /u/l/p/extra/Gem path has to be added somehow to Pd's
search paths. (this can be done manually via the -path, or automatically
by Gem). so far so good.

the problem: starting Pd with Gem added to the paths, results in a
not-so-nice help-browser experience: basically the left column (the one
that is crucial for navigating the various directories) is filled with
224 or so help-patches from Gem, sorted alphabetically (so directories
are lost somewhere between files), and upper-case before lower-case.
of course there is also a directory entry for Gem/ in the help-browser,
making the information accessible two times (adding more confusion)

given that both GF and Gem are to add their paths automatically on
startup, the left column if the help-browser might have >500
help-patches and several dozens of directories.

i don't know exactly where to fix the problem, but a simple solution
would be to only allow directories on the left side (and add an entry
for "<searchpaths>" (probably an entry for "all searchpaths" and
separate entries for each searchpath), rather than throwing everything

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110503/b7a92318/attachment.bin>

More information about the Pd-list mailing list