-----BEGIN PGP SIGNED MESSAGE----- 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 together. fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2/wrQACgkQkX2Xpv6ydvT6UACghrBixWNveMT8bMl9u/Vdu+l3 f80An2WzIBvBwaeDNHA3vua4Hj3npyN1 =yl89 -----END PGP SIGNATURE-----
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
