Here's a revised version of the search-plugin that Hans started:
* fixed problem with double results if a path dir was a subdir of another * can search for phrases by using double quotes * search for whole words or partial matches * search for all or any terms * better scrollbar (ttk::scrollbar) * Google-style search history (press the down-arrow in the search box to make it appear, Escape to make it go away) * hacked a proc to get <control-delete> to delete previous word
Requires tcl/tk 8.5. Works best with the revised pddp docs (i.e., if you want to search by the keywords listed you'll need them).
-Jonathan
That's quite nice, looks and works very well. You've taken my sketch and made it something far beyond what it was originally.
One thing, I notice that for objects' help files, you strip the paths. That make sense, except it does the same for all_about* patches. Also, that could get confusing when a search result finds something in an abstraction and its help file.
.hc
On Jun 16, 2011, at 3:50 PM, Jonathan Wilkes wrote:
Here's a revised version of the search-plugin that Hans started:
- fixed problem with double results if a path dir was a subdir of
another
- can search for phrases by using double quotes
- search for whole words or partial matches
- search for all or any terms
- better scrollbar (ttk::scrollbar)
- Google-style search history (press the down-arrow in the search
box to make it appear, Escape to make it go away)
- hacked a proc to get <control-delete> to delete previous word
Requires tcl/tk 8.5. Works best with the revised pddp docs (i.e., if you want to search by the keywords listed you'll need them).
-Jonathan<search- plugin.tcl>_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
--- On Mon, 6/20/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] revised search-plugin.tcl To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "pd-dev" pd-dev@iem.at Date: Monday, June 20, 2011, 4:37 PM
That's quite nice, looks and works very well. You've taken my sketch and made it something far beyond what it was originally.
One thing, I notice that for objects' help files, you strip the paths.
I strip out everything except the immediate parent. That way you can still tell the difference between libs-- intimacy/love-help.pd vs. tennis/love-help.pd. But I don't see a reason to display /usr/local/softwares/classic-90s-interfaces/tinytinyscrollbarzplzthx/pd/doc/externals/Dr.Externals/...
That make sense, except it does the same for all_about* patches. Also, that could get confusing when a search result finds something in an abstraction and its help file.
I'm just testing it on pd vanilla at the moment: foo.pd displays as foo.pd, and foo-help.pd displays as foo-help.pd. Is it different for you?
I'll rethink the all_about* regsub. Probably just displaying "All About foo" will look decent and not too repetitive...
-Jonathan
.hc
On Jun 16, 2011, at 3:50 PM, Jonathan Wilkes wrote:
Here's a revised version of the search-plugin that
Hans started:
- fixed problem with double results if a path dir was
a subdir of another
- can search for phrases by using double quotes
- search for whole words or partial matches
- search for all or any terms
- better scrollbar (ttk::scrollbar)
- Google-style search history (press the down-arrow in
the search box to
make it appear, Escape to make it go away)
- hacked a proc to get <control-delete> to
delete previous word
Requires tcl/tk 8.5. Works best with the revised pddp
docs (i.e., if you
want to search by the keywords listed you'll need
them).
-Jonathan<search-plugin.tcl>_______________________________________________
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
On Jun 20, 2011, at 6:55 PM, Jonathan Wilkes wrote:
--- On Mon, 6/20/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] revised search-plugin.tcl To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "pd-dev" pd-dev@iem.at Date: Monday, June 20, 2011, 4:37 PM
That's quite nice, looks and works very well. You've taken my sketch and made it something far beyond what it was originally.
One thing, I notice that for objects' help files, you strip the paths.
I strip out everything except the immediate parent. That way you can still tell the difference between libs-- intimacy/love-help.pd vs. tennis/love-help.pd. But I don't see a reason to display /usr/local/softwares/classic-90s-interfaces/tinytinyscrollbarzplzthx/ pd/doc/externals/Dr.Externals/...
One thing that might be useful to see is whether the library is included or whether its a user-installed lib.
That make sense, except it does the same for all_about* patches. Also, that could get confusing when a search result finds something in an abstraction and its help file.
I'm just testing it on pd vanilla at the moment: foo.pd displays as foo.pd, and foo-help.pd displays as foo-help.pd. Is it different for you?
I'll rethink the all_about* regsub. Probably just displaying "All About foo" will look decent and not too repetitive...
Yeah, that sounds good.
.hc
-Jonathan
.hc
On Jun 16, 2011, at 3:50 PM, Jonathan Wilkes wrote:
Here's a revised version of the search-plugin that
Hans started:
- fixed problem with double results if a path dir was
a subdir of another
- can search for phrases by using double quotes
- search for whole words or partial matches
- search for all or any terms
- better scrollbar (ttk::scrollbar)
- Google-style search history (press the down-arrow in
the search box to
make it appear, Escape to make it go away)
- hacked a proc to get <control-delete> to
delete previous word
Requires tcl/tk 8.5. Works best with the revised pddp
docs (i.e., if you
want to search by the keywords listed you'll need
them).
-Jonathan<search- plugin.tcl>_______________________________________________
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
----------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
--- On Tue, 6/21/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] revised search-plugin.tcl To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "pd-dev" pd-dev@iem.at Date: Tuesday, June 21, 2011, 12:59 AM
On Jun 20, 2011, at 6:55 PM, Jonathan Wilkes wrote:
--- On Mon, 6/20/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] revised search-plugin.tcl To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "pd-dev" pd-dev@iem.at Date: Monday, June 20, 2011, 4:37 PM
That's quite nice, looks and works very
well. You've
taken my sketch and made it something far beyond
what it was
originally.
One thing, I notice that for objects' help files,
you strip
the paths.
I strip out everything except the immediate
parent. That way you can
still tell the difference between libs--
intimacy/love-help.pd vs.
tennis/love-help.pd. But I don't see a reason to
display
/usr/local/softwares/classic-90s-interfaces/tinytinyscrollbarzplzthx/
pd/doc/externals/Dr.Externals/...
One thing that might be useful to see is whether the library is included or whether its a user-installed lib.
How does one tell the difference?
-Jonathan
That make sense, except it does the same for all_about* patches. Also, that could get
confusing
when a search result finds something in an
abstraction and
its help file.
I'm just testing it on pd vanilla at the moment:
foo.pd displays as
foo.pd, and foo-help.pd displays as foo-help.pd. Is it
different for you?
I'll rethink the all_about* regsub. Probably
just displaying "All
About foo" will look decent and not too repetitive...
Yeah, that sounds good.
.hc
-Jonathan
.hc
On Jun 16, 2011, at 3:50 PM, Jonathan Wilkes
wrote:
Here's a revised version of the search-plugin
that
Hans started:
- fixed problem with double results if a path
dir was
a subdir of another
- can search for phrases by using double
quotes
- search for whole words or partial matches
- search for all or any terms
- better scrollbar (ttk::scrollbar)
- Google-style search history (press the
down-arrow in
the search box to
make it appear, Escape to make it go away)
- hacked a proc to get <control-delete>
to
delete previous word
Requires tcl/tk 8.5. Works best with the
revised pddp
docs (i.e., if you
want to search by the keywords listed you'll
need
them).
-Jonathan<search-
plugin.tcl>_______________________________________________
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"[T]he greatest purveyor of violence in the world
today
[is] my own government." - Martin Luther King,
Jr.
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-21 02:13, Jonathan Wilkes wrote:
How does one tell the difference?
i think the idea is to segregrate based on the paths libraries are installed to. usually there are directories where you need suprt-user rights to write to. whenever something gets installed there, i think it would classify as being "included".
e.g., everything in /path/to/pd/bin/../extra would be "included", whereas everything in /home/${USER}/ would be user-installed.
a simpler discrimination would be to differentiate between 'administrator-installed' (paths starting with "/usr"; eventually also include paths starting with "/opt" and "/var") 'user-installed' (the rest)
paths like /usr/local/lib/pd-externals which are searched automatically, are somewhere inbetween, as they require su priviliges for installation but can definitely not be considered as 'included'.
for other operating systems, the paths will obviously be different.
i would probably find it more convenient, if there was a simple way to see the full path of a certain object. i can then figure out myself, whether this is user-installed or system-installed, and it helps me discriminate between multiple entries of the same name.
fgmasdr IOhannes
--- On Tue, 6/21/11, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at Subject: Re: [PD-dev] revised search-plugin.tcl To: pd-dev@iem.at Date: Tuesday, June 21, 2011, 9:19 AM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-21 02:13, Jonathan Wilkes wrote:
How does one tell the difference?
i think the idea is to segregrate based on the paths libraries are installed to. usually there are directories where you need suprt-user rights to write to. whenever something gets installed there, i think it would classify as being "included".
I think separating on by dir to get a distinction between root/user accessible libraries won't work, like if I compile pd in ~/newest-vanilla/ and search for "included" libs. (Plus MacOS/Win/GNU-Linux distinctions...)
e.g., everything in /path/to/pd/bin/../extra would be "included", whereas everything in /home/${USER}/ would be user-installed.
a simpler discrimination would be to differentiate between 'administrator-installed' (paths starting with "/usr"; eventually also include paths starting with "/opt" and "/var") 'user-installed' (the rest)
paths like /usr/local/lib/pd-externals which are searched automatically, are somewhere inbetween, as they require su priviliges for installation but can definitely not be considered as 'included'.
for other operating systems, the paths will obviously be different.
i would probably find it more convenient, if there was a simple way to see the full path of a certain object. i can then figure out myself, whether this is user-installed or system-installed, and it helps me discriminate between multiple entries of the same name.
Could probably do a firefox style status bar to show the path when the mouse hovers over the respective link (otherwise it's pretty ugly if it's just in the search results for each result).
Do you think the path is needed in the search results for any reason other than to resolve ambiguity between the same library being system-installed and user-installed at the same time? I mean, if someone just wants to know whether the object described by cyclone/foo-help.pd is system- or user-installed, they just click on the link and see the path is at the top of the help patch window.
-Jonathan
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4ARfIACgkQkX2Xpv6ydvSvSwCeIKcHoA3XydXEoTZh2wF387tb liEAoPAlaBgcE9hLMgggKOUxF+rTk7IH =mi6B -----END PGP SIGNATURE-----
-----Inline Attachment Follows-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 2011-06-23 01:05, Jonathan Wilkes wrote:
I think separating on by dir to get a distinction between root/user accessible libraries won't work, like if I compile pd in ~/newest-vanilla/ and search for "included" libs. (Plus MacOS/Win/GNU-Linux distinctions...)
e.g., everything in /path/to/pd/bin/../extra would be "included", whereas everything in /home/${USER}/ would be user-installed.
well, the trick was not to look at the permissions of the directory. but of course you are right, that the full path should not be the only means for discrimination. my original example noted /path/to/pd/ which of course could resolved to /home/me/newest-vanilla/
what makes things worse, is that for different instances of Pd, the term "included" and "user-installed" might get swapped.
e.g. $ ~/pd-0.43/src/pd -path ~/pd-0.42/src/extra would use the not-included-in-pd-0.43 [expr~] from pd-0.42,
i would probably find it more convenient, if there was a simple way to see the full path of a certain object. i can then figure out myself, whether this is user-installed or system-installed, and it helps me discriminate between multiple entries of the same name.
Could probably do a firefox style status bar to show the path when the mouse hovers over the respective link (otherwise it's pretty ugly if it's just in the search results for each result).
yes something like this. i originally thought of using tooltips, but tried to avoid giving any specifics.
Do you think the path is needed in the search results for any reason other than to resolve ambiguity between the same library being system-installed and user-installed at the same time? I mean, if someone just wants to know whether the object described by cyclone/foo-help.pd is system- or user-installed, they just click on the link and see the path is at the top of the help patch window.
well, the search results could be made anonymous buttons, since the user will see what they selected as soon as the patch opens anyhow.
it's mainly about convenience, and if i know that the system-installed patch is sure to crash my installation, then i probably want to know beforehand.
fgmasdr IOhannes
On Jun 24, 2011, at 4:36 AM, IOhannes m zmoelnig wrote:
On 2011-06-23 01:05, Jonathan Wilkes wrote:
I think separating on by dir to get a distinction between root/user accessible libraries won't work, like if I compile pd in ~/newest- vanilla/ and search for "included" libs. (Plus MacOS/Win/GNU-Linux distinctions...)
e.g., everything in /path/to/pd/bin/../extra would be "included", whereas everything in /home/${USER}/ would be user-installed.
well, the trick was not to look at the permissions of the directory. but of course you are right, that the full path should not be the only means for discrimination. my original example noted /path/to/pd/ which of course could resolved to /home/me/newest-vanilla/
what makes things worse, is that for different instances of Pd, the term "included" and "user-installed" might get swapped.
e.g. $ ~/pd-0.43/src/pd -path ~/pd-0.42/src/extra would use the not-included-in-pd-0.43 [expr~] from pd-0.42,
In Tcl space, there are different variables to tell you this, and they'll work cross-platform, and should work cross-installation (i.e. in ~/newest-vanilla.) From pd-gui.tcl:
# root path to lib of Pd's files, see s_main.c for more info set sys_libdir {} # root path where the pd-gui.tcl GUI script is located set sys_guidir {} # user-specified search path for objects, help, fonts, etc. set sys_searchpath {} # hard-coded search patch for objects, help, plugins, etc. set sys_staticpath {}
.hc
i would probably find it more convenient, if there was a simple way to see the full path of a certain object. i can then figure out myself, whether this is user-installed or system-installed, and it helps me discriminate between multiple entries of the same name.
Could probably do a firefox style status bar to show the path when the mouse hovers over the respective link (otherwise it's pretty ugly if it's just in the search results for each result).
yes something like this. i originally thought of using tooltips, but tried to avoid giving any specifics.
Do you think the path is needed in the search results for any reason other than to resolve ambiguity between the same library being system- installed and user-installed at the same time? I mean, if someone just wants to know whether the object described by cyclone/foo-help.pd is system- or user-installed, they just click on the link and see the path is at the top of the help patch window.
well, the search results could be made anonymous buttons, since the user will see what they selected as soon as the patch opens anyhow.
it's mainly about convenience, and if i know that the system-installed patch is sure to crash my installation, then i probably want to know beforehand.
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes