On Tue, 12 Jul 2011 10:33 -0700, "Jonathan Wilkes" jancsika@yahoo.com wrote:
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Tuesday, July 12, 2011, 6:39 PM
On Mon, 11 Jul 2011 19:57 -0700, "Jonathan Wilkes" jancsika@yahoo.com wrote:
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD]
Pd-extended 0.43 updates: lots of new editing features
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 4:40 AM
On Jul 11, 2011, at 10:03 PM, Jonathan Wilkes
wrote:
--- On Tue, 7/12/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: implementing tooltips WAS:
[PD]
Pd-extended 0.43 updates: lots of new editing
features
To: "Hans-Christoph Steiner" hans@at.or.at Cc: "Jonathan Wilkes" jancsika@yahoo.com,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 3:28 AM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
> IMHO, I don't think we should
support other
ways of
specifying the help file. There are very
few
objects that
use it, those are fixed in Pd-extended,
it'll add
a lot to
the work of doing this, etc. etc. So I
say
just take
the object name and add the '-help' to
it.
That covers
99.5% of objects. Then once its
working, it
should be
possible to go back and add hacks to
support hacks
;)
c_helpname is not a hack, it doesn't
need to be
«fixed»,
and it shouldn't be «fixed». It's
there for a
reason.
One thing I'm running into is that
c_helpname doesn't
help with abstractions-- it obviously just
returns
"canvas". I guess I could then compare to the
first
atom in te_binbuf and if it's not "pd" then it's
the name of
the abstraction. But that still doesn't get me
the
dir.
You could look for the standard help patch
location first,
and if that fails, use c_helpname to solve the
issue that
Matju brought up.
That still doesn't help with abstractions, because
c_helpname is still
"canvas".
It helps if it first finds the help patch right next to the abstraction's file in the same folder.
Given a t_object, what's the best way to tell if it's an abstraction, and-- if it is-- how can I query its glist members (gl_name and the canvasenvironment ce_path?)
Then it wouldn't even check c_helpname.
Additionally, internal objects don't have a
c_externdir in 0.43 vanilla,
but I guess even the vanilla objects are going to be
in their own lib so
that won't matter going forward, right?
This is the case where it would fall back to using c_helpname. Like this:
- build helpfile path using c_externdir, classname and
'-help.pd'
- else if above file does not exist, try c_helpname
- else, use built-in defaults (or not).
Is there a tcl variable for the built-in default doc directory?
In Tcl/pd-gui: $::sys_libdir/doc
In C/pd:
char docdir[MAXPDSTRING]; strcat(docdir, sys_libdir); strcat(docdir, "/doc")
But you probably want to use strncat() to be safe.
.hc