On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There were some reports of a search taking over a minute, but with GNU/Linux and winxp I'm getting about 3 seconds for a little over 9,000 docs (I think I'm searching two different copies of pd-extended libs so that should be well over what you'd typically be searching). If people are getting long searches please start by telling me how many files you're searching. Also, the progressbar updates don't start until it's built a list of files and sorted it, so if it's taking a long time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think there's much need to build an index. You can start reading the first results immediately and even scroll the list as it finishes printing the results. (I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should install now. The progress bar is a good enhancement. I wonder if it could somehow fit in to the GUI elements better somehow. Its fine how it is, but it seems a little out of place.
Looks like there are some debug messages still in it, I get these when hovering:
filename is 5.reference/all_about_arrays.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/loop~-help.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Tuesday, October 30, 2012 10:38 PM Subject: Re: [PD] Browse/Search plugin update
On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There were some reports of a search taking over a minute, but with GNU/Linux and winxp I'm getting about 3 seconds for a little over 9,000 docs (I think I'm searching two different copies of pd-extended libs so that should be well over what you'd typically be searching). If people are getting long searches please start by telling me how many files you're searching. Also, the progressbar updates don't start until it's built a list of files and sorted it, so if it's
taking a long
time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think there's
much
need to build an index. You can start reading the first results immediately and even scroll the list as it finishes printing the results. (I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should install now. The progress bar is a good enhancement. I wonder if it could somehow fit in to the GUI elements better somehow. Its fine how it is, but it seems a little out of place.
After trying it out on winxp it seemed obvious that progress bars like that are generally transient. Now it fills up, disappears and gets replaced by the text telling the number of results.
I also found out that the lsort -command flag is causing the delay before the progress bar starts. There's a workaround on the tcl wiki. I'll post the update once I get it working.
Looks like there are some debug messages still in it, I get these when hovering:
filename is 5.reference/all_about_arrays.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/loop~-help.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
Ah yes, forgot about those. Thanks.
-Jonathan
.hc
Ok, I changed the progress bar and replaced the sluggish [lsort -command]. It now responds pretty much instantaneously when you start a search:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
Earlier when I tested on winxp it initially took about 15 seconds to load the search, but then it took around 3 seconds after that (even after re-opening Pd, so I don't think it was caching anything). Haven't tried on OSX yet.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Tuesday, October 30, 2012 10:38 PM Subject: Re: [PD] Browse/Search plugin update
On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There were some reports of a search taking over a minute, but with GNU/Linux and winxp I'm getting about 3 seconds for a little over 9,000 docs (I think I'm searching two different copies of pd-extended libs so that should be well over what you'd typically be searching). If people are getting long searches please start by telling me how many files you're searching. Also, the progressbar updates don't start until it's built a list of files and sorted it, so if it's
taking a long
time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think there's
much
need to build an index. You can start reading the first results immediately and even scroll the list as it finishes printing the results. (I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should install now. The progress bar is a good enhancement. I wonder if it could somehow fit in to the GUI elements better somehow. Its fine how it is, but it seems a little out of place.
Looks like there are some debug messages still in it, I get these when hovering:
filename is 5.reference/all_about_arrays.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/loop~-help.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
was caching anything). Haven't tried on OSX yet
Works quite swell here on 10.7 Thanks!!! M
On Oct 31, 2012, at 2:12 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Ok, I changed the progress bar and replaced the sluggish [lsort -command]. It now responds pretty much instantaneously when you start a search:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
Earlier when I tested on winxp it initially took about 15 seconds to load the search, but then it took around 3 seconds after that (even after re-opening Pd, so I don't think it was caching anything). Haven't tried on OSX yet.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Tuesday, October 30, 2012 10:38 PM Subject: Re: [PD] Browse/Search plugin update
On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There were some reports of a search taking over a minute, but with GNU/Linux and winxp I'm getting about 3 seconds for a little over 9,000 docs (I think I'm searching two different copies of pd-extended libs so that should be well over what you'd typically be searching). If people are getting long searches please start by telling me how many files you're searching. Also, the progressbar updates don't start until it's built a list of files and sorted it, so if it's
taking a long
time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think there's
much
need to build an index. You can start reading the first results immediately and even scroll the list as it finishes printing the results. (I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should install now. The progress bar is a good enhancement. I wonder if it could somehow fit in to the GUI elements better somehow. Its fine how it is, but it seems a little out of place.
Looks like there are some debug messages still in it, I get these when hovering:
filename is 5.reference/all_about_arrays.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/loop~-help.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Good to hear. I've got a few more changes I'll post a little later.
-Jonathan
----- Original Message -----
From: me.grimm megrimm@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; PD List pd-list@iem.at Sent: Wednesday, October 31, 2012 6:25 PM Subject: Re: [PD] Browse/Search plugin update
was caching anything). Haven't tried on OSX yet
Works quite swell here on 10.7 Thanks!!! M
On Oct 31, 2012, at 2:12 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Ok, I changed the progress bar and replaced the sluggish [lsort -command]. It now responds pretty much instantaneously when you start a search:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
Earlier when I tested on winxp it initially took about 15 seconds to load the search, but then it took around 3 seconds after that (even after re-opening Pd, so I don't think it was caching anything).
Haven't
tried on OSX yet.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Tuesday, October 30, 2012 10:38 PM Subject: Re: [PD] Browse/Search plugin update
On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There were
some
reports of a search taking over a minute, but with GNU/Linux and winxp I'm getting about 3 seconds for a little over 9,000 docs
(I
think I'm searching two different copies of pd-extended libs so that should be well over what you'd typically be searching).
If
people are getting long searches please start by telling me how many files you're searching. Also, the progressbar updates
don't
start until it's built a list of files and sorted it, so if
it's
taking a long
time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think
there's
much
need to build an index. You can start reading the first results immediately and even scroll the list as it finishes printing the
results.
(I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should install
now. The
progress bar is a good enhancement. I wonder if it could somehow fit
in to the
GUI elements better somehow. Its fine how it is, but it seems a little
out of
place.
Looks like there are some debug messages still in it, I get these when
hovering:
filename is 5.reference/all_about_arrays.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/loop~-help.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Here's another update: http://puredata.info/Members/jancsika/searchandbrowseplugin/view
- There are now links to browse doc folder and browse external libs at the top.
These two links should cover all the features of the <ctrl-b> browser other than keyboard browsing.
- Another speedup. In the search I'm able to do 255 recursive iterations with
no delay and on the 256th one call the next iteration with [after idle]. I really don't understand how that remains deterministic but it looks like it does, and it has the effect of speeding up the average search greatly. So much so that you barely even notice the progressbar before it disappears. But if you click on a result that opens a pd file it has to finish the search before it opens, so the progressbar is handy in that situation as an indicator.
- there's still substantial overhead in parsing the description/keywords/etc.
for a result. Not sure if I can do much to speed that up-- you'll notice if you do a search that has a lot of results like "a" or "".
- I'm catching badly formed tcl lists and improper regex syntax in the search
text and giving the user a pretty and (hopefully helpful) error message and link in the text widget instead of shooting a tk error dialog at him/her. You'll see it if you search for an open curly bracket, single quote, forward slash, etc.
- This ui is really at the edge of what tcl/tk can do-- I tried to get a bit fancier
in the recursive event loop and got a "Too Many Nested Evolutions" error from Tk.
Anyway, after writing various hacks to get tooltips and hyperlinks in Tk, I really hope someone ports Pd to a modern GUI toolkit where you get those things for free!
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: me.grimm megrimm@gmail.com Cc: PD List pd-list@iem.at Sent: Wednesday, October 31, 2012 8:44 PM Subject: Re: [PD] Browse/Search plugin update
G ood to hear. I've got a few more changes I'll post a little later.
-Jonathan
----- Original Message -----
From: me.grimm megrimm@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; PD List
Sent: Wednesday, October 31, 2012 6:25 PM Subject: Re: [PD] Browse/Search plugin update
was caching anything). Haven't tried on OSX yet
Works quite swell here on 10.7 Thanks!!! M
On Oct 31, 2012, at 2:12 AM, Jonathan Wilkes jancsika@yahoo.com
wrote:
Ok, I changed the progress bar and replaced the sluggish [lsort -command]. It now responds pretty much instantaneously when you start a search:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
Earlier when I tested on winxp it initially took about 15 seconds to load the search, but then it took around 3 seconds after that (even after re-opening Pd, so I don't think it was caching anything).
Haven't
tried on OSX yet.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Tuesday, October 30, 2012 10:38 PM Subject: Re: [PD] Browse/Search plugin update
On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There
were
some
reports of a search taking over a minute, but with GNU/Linux
and
winxp I'm getting about 3 seconds for a little over 9,000
docs
(I
think I'm searching two different copies of pd-extended
libs so
that should be well over what you'd typically be
searching).
If
people are getting long searches please start by telling me
how
many files you're searching. Also, the progressbar
updates
don't
start until it's built a list of files and sorted it, so
if
it's
taking a long
time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think
there's
much
need to build an index. You can start reading the first
results
immediately and even scroll the list as it finishes printing
the
results.
(I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should
install
now. The
progress bar is a good enhancement. I wonder if it could somehow
fit
in to the
GUI elements better somehow. Its fine how it is, but it seems a
little
out of
place.
Looks like there are some debug messages still in it, I get these
when
hovering:
filename is 5.reference/all_about_arrays.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/loop~-help.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Tuesday, October 30, 2012 10:38 PM Subject: Re: [PD] Browse/Search plugin update
On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There were some reports of a search taking over a minute, but with GNU/Linux and winxp I'm getting about 3 seconds for a little over 9,000 docs (I think I'm searching two different copies of pd-extended libs so that should be well over what you'd typically be searching). If people are getting long searches please start by telling me how many files you're searching. Also, the progressbar updates don't start until it's built a list of files and sorted it, so if it's
taking a long
time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think there's
much
need to build an index. You can start reading the first results immediately and even scroll the list as it finishes printing the results. (I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should install now.
It's UI is designed to be a drop-in replacement for the ctrl-b browser. You should be able to browse all the same locations, plus the user gets descriptions of all the libdirs which makes browsing them much more meaningful. There is zero delay when browsing docs. (Well, aside from a small delay on winxp with the libdirs because of another lsort -command, but I'll be removing that soon.)
You can use ctrl-minus and ctrl-plus (or ctrl-equals) to make the text larger or smaller, just like every web browser and word-processor I've ever used, so it has more accessibility than the ctrl-b browser. Additionally, clicking the folder icon to bring up the containing folder is easier to discover than however you do that in the ctrl-b browser (which isn't documented).
Finally, displaying a description for the content of pd files encourages devs to actually describe the content of their files. I know "No DESCRIPTION tag" looks ugly but the fix is to add descriptions and improve the documentation.
If there's interest in this replacing the ctrl-b browser I'll do some work to make it an actual drop-in replacement instead of a plug-in. (So for example, you click ctrl-b and the search/browse plugin pops up.)
-Jonathan
The progress bar is a good enhancement. I wonder if it could somehow fit in to the GUI elements better somehow. Its fine how it is, but it seems a little out of place.
Looks like there are some debug messages still in it, I get these when hovering:
filename is 5.reference/all_about_arrays.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/loop~-help.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
On Oct 31, 2012, at 2:20 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Tuesday, October 30, 2012 10:38 PM Subject: Re: [PD] Browse/Search plugin update
On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There were some reports of a search taking over a minute, but with GNU/Linux and winxp I'm getting about 3 seconds for a little over 9,000 docs (I think I'm searching two different copies of pd-extended libs so that should be well over what you'd typically be searching). If people are getting long searches please start by telling me how many files you're searching. Also, the progressbar updates don't start until it's built a list of files and sorted it, so if it's
taking a long
time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think there's
much
need to build an index. You can start reading the first results immediately and even scroll the list as it finishes printing the results. (I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should install now.
It's UI is designed to be a drop-in replacement for the ctrl-b browser. You should be able to browse all the same locations, plus the user gets descriptions of all the libdirs which makes browsing them much more meaningful. There is zero delay when browsing docs. (Well, aside from a small delay on winxp with the libdirs because of another lsort -command, but I'll be removing that soon.)
You can use ctrl-minus and ctrl-plus (or ctrl-equals) to make the text larger or smaller, just like every web browser and word-processor I've ever used, so it has more accessibility than the ctrl-b browser. Additionally, clicking the folder icon to bring up the containing folder is easier to discover than however you do that in the ctrl-b browser (which isn't documented).
Finally, displaying a description for the content of pd files encourages devs to actually describe the content of their files. I know "No DESCRIPTION tag" looks ugly but the fix is to add descriptions and improve the documentation.
If there's interest in this replacing the ctrl-b browser I'll do some work to make it an actual drop-in replacement instead of a plug-in. (So for example, you click ctrl-b and the search/browse plugin pops up.)
Its definitely a lot more polished than the help browser, and its almost a complete replacement. Here are a couple things that I spotted:
it lacks a clear way to go back a level, I think this would be well handled by standard back/forward buttons like are in internet browsers, file browsers, etc.
there are a number of libraries that show: "version: no AUTHOR tag or values" while the author: field is filled out.
.hc
-Jonathan
The progress bar is a good enhancement. I wonder if it could somehow fit in to the GUI elements better somehow. Its fine how it is, but it seems a little out of place.
Looks like there are some debug messages still in it, I get these when hovering:
filename is 5.reference/all_about_arrays.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/loop~-help.pd basedir is /Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Wednesday, October 31, 2012 11:46 PM Subject: Re: [PD] Browse/Search plugin update
On Oct 31, 2012, at 2:20 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Tuesday, October 30, 2012 10:38 PM Subject: Re: [PD] Browse/Search plugin update
On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There were
some
reports of a search taking over a minute, but with GNU/Linux and winxp I'm getting about 3 seconds for a little over 9,000 docs
(I
think I'm searching two different copies of pd-extended libs so that should be well over what you'd typically be searching).
If
people are getting long searches please start by telling me how many files you're searching. Also, the progressbar updates
don't
start until it's built a list of files and sorted it, so if
it's
taking a long
time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think
there's
much
need to build an index. You can start reading the first results immediately and even scroll the list as it finishes printing the
results.
(I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should install
now.
It's UI is designed to be a drop-in replacement for the ctrl-b
browser. You should
be able to browse all the same locations, plus the user gets descriptions
of
all the libdirs which makes browsing them much more meaningful. There is zero delay when browsing docs. (Well, aside from a small delay on winxp with the libdirs because of another lsort -command, but I'll be
removing that
soon.)
You can use ctrl-minus and ctrl-plus (or ctrl-equals) to make the text
larger or
smaller, just like every web browser and word-processor I've ever used,
so it
has more accessibility than the ctrl-b browser. Additionally, clicking the
folder
icon to bring up the containing folder is easier to discover than however
you
do that in the ctrl-b browser (which isn't documented).
Finally, displaying a description for the content of pd files encourages
devs to
actually describe the content of their files. I know "No DESCRIPTION
tag" looks
ugly but the fix is to add descriptions and improve the documentation.
If there's interest in this replacing the ctrl-b browser I'll do
some work to make it
an actual drop-in replacement instead of a plug-in. (So for example, you
click
ctrl-b and the search/browse plugin pops up.)
Its definitely a lot more polished than the help browser, and its almost a complete replacement. Here are a couple things that I spotted:
- it lacks a clear way to go back a level, I think this would be well handled by
standard back/forward buttons like are in internet browsers, file browsers, etc.
You can follow the folder links back. For initial search you can go back home. For multiple searches no, you can't.
To rectify this would require caching the state of the text widget-- using the "dump" subcommand I guess-- for however many levels you want to support. It could probably become several megs of data pretty quick, so I guess it'd have to be cached to a file somewhere, which adds another level of complexity.
Also, guess what? There's no matching subcommand for "dump"! So just like hyperlinks I'd have to hand craft some way to read the contents back in to the widget.
If you have an easier suggestion to get this functionality let me know. Otherwise I think it's too much trouble.
- there are a number of libraries that show: "version: no AUTHOR tag or
values" while the author: field is filled out.
Which library? I'll check it out.
Thanks, Jonathan
.hc
-Jonathan
The progress bar is a good enhancement. I wonder if it could somehow fit
in to the
GUI elements better somehow. Its fine how it is, but it seems a little
out of
place.
Looks like there are some debug messages still in it, I get these when
hovering:
filename is 5.reference/all_about_arrays.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/loop~-help.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
On Nov 1, 2012, at 12:35 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Wednesday, October 31, 2012 11:46 PM Subject: Re: [PD] Browse/Search plugin update
On Oct 31, 2012, at 2:20 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Tuesday, October 30, 2012 10:38 PM Subject: Re: [PD] Browse/Search plugin update
On 10/30/2012 07:20 PM, Jonathan Wilkes wrote:
I updated my search plugin by adding a progressbar:
http://puredata.info/Members/jancsika/searchandbrowseplugin/view
It also prints out the number of files it searched. There were
some
reports of a search taking over a minute, but with GNU/Linux and winxp I'm getting about 3 seconds for a little over 9,000 docs
(I
think I'm searching two different copies of pd-extended libs so that should be well over what you'd typically be searching).
If
people are getting long searches please start by telling me how many files you're searching. Also, the progressbar updates
don't
start until it's built a list of files and sorted it, so if
it's
taking a long
time when you search before the progressbar appears then that may be the culprit.
Now that the interface updates live I don't really think
there's
much
need to build an index. You can start reading the first results immediately and even scroll the list as it finishes printing the
results.
(I guess I can also add a "Cancel" button, too.)
Let me know if there are any bugs.
-Jonathan
Looking very good! I consider this something everyone should install
now.
It's UI is designed to be a drop-in replacement for the ctrl-b
browser. You should
be able to browse all the same locations, plus the user gets descriptions
of
all the libdirs which makes browsing them much more meaningful. There is zero delay when browsing docs. (Well, aside from a small delay on winxp with the libdirs because of another lsort -command, but I'll be
removing that
soon.)
You can use ctrl-minus and ctrl-plus (or ctrl-equals) to make the text
larger or
smaller, just like every web browser and word-processor I've ever used,
so it
has more accessibility than the ctrl-b browser. Additionally, clicking the
folder
icon to bring up the containing folder is easier to discover than however
you
do that in the ctrl-b browser (which isn't documented).
Finally, displaying a description for the content of pd files encourages
devs to
actually describe the content of their files. I know "No DESCRIPTION
tag" looks
ugly but the fix is to add descriptions and improve the documentation.
If there's interest in this replacing the ctrl-b browser I'll do
some work to make it
an actual drop-in replacement instead of a plug-in. (So for example, you
click
ctrl-b and the search/browse plugin pops up.)
Its definitely a lot more polished than the help browser, and its almost a complete replacement. Here are a couple things that I spotted:
- it lacks a clear way to go back a level, I think this would be well handled by
standard back/forward buttons like are in internet browsers, file browsers, etc.
You can follow the folder links back. For initial search you can go back home. For multiple searches no, you can't.
To rectify this would require caching the state of the text widget-- using the "dump" subcommand I guess-- for however many levels you want to support. It could probably become several megs of data pretty quick, so I guess it'd have to be cached to a file somewhere, which adds another level of complexity.
Also, guess what? There's no matching subcommand for "dump"! So just like hyperlinks I'd have to hand craft some way to read the contents back in to the widget.
If you have an easier suggestion to get this functionality let me know. Otherwise I think it's too much trouble.
It would help to make the folder links more apparent, they are quite small and easily overlooked, at least for impatient people like me ;)
For back/forward buttons, couldn't you just store a reference to each page? Basically you have two stacks, one for the back and one for the forward. Each time you click on a link, you add the current page to the back stack. Each time you click back, you add the current page to the forward stack. Clicking a new link clears the forward stack.
- there are a number of libraries that show: "version: no AUTHOR tag or
values" while the author: field is filled out.
Which library? I'll check it out.
A few of them, I just opened up the libraries view and skimmed the list.
.hc
Thanks, Jonathan
.hc
-Jonathan
The progress bar is a good enhancement. I wonder if it could somehow fit
in to the
GUI elements better somehow. Its fine how it is, but it seems a little
out of
place.
Looks like there are some debug messages still in it, I get these when
hovering:
filename is 5.reference/all_about_arrays.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/loop~-help.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 11:21 AM Subject: Re: [PD] Browse/Search plugin update
[...]
For back/forward buttons, couldn't you just store a reference to each page? Basically you have two stacks, one for the back and one for the forward. Each time you click on a link, you add the current page to the back stack. Each time you click back, you add the current page to the forward stack. Clicking a new link clears the forward stack.
It'd have to work for the search, too. So any time someone browses or searches I keep a reference to where they were browsing or the term they searched for. Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to navigation buttons working immediately, and though I've sped up the search considerably there's still some initial overhead in building the list of files to search. That will lead to irregular intervals of latency when users click the "back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when you click the Down arrow.
-Jonathan
- there are a number of libraries that show: "version: no AUTHOR tag or
values" while the author: field is filled out.
Which library? I'll check it out.
A few of them, I just opened up the libraries view and skimmed the list.
Ok, that's fixed: https://puredata.info/Members/jancsika/searchandbrowseplugin/view
.hc
Thanks, Jonathan
.hc
-Jonathan
The progress bar is a good enhancement. I wonder if it could somehow fit
in to the
GUI elements better somehow. Its fine how it is, but it seems a little
out of
place.
Looks like there are some debug messages still in it, I get these when
hovering:
filename is 5.reference/all_about_arrays.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/loop~-help.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
Another update... https://puredata.info/Members/jancsika/searchandbrowseplugin/view
- fixed some small bugs with the navigation bar and
<ctrl-f> throwing a tk error.
I also played around with limiting search scope to the directory the user is currently browsing, but really it's a lot cleaner to keep the two functions separate. I think new users will save a lot of time by just getting used to searching and forgo browsing altogether. If things are tagged properly it shouldn't really matter what directory the information is in. (And besides, if you really need to know it's at the top of the patch window anyway.)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 2:06 PM Subject: Re: [PD] Browse/Search plugin update
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 11:21 AM Subject: Re: [PD] Browse/Search plugin update
[...]
For back/forward buttons, couldn't you just store a reference to each
page? Basically you have two stacks, one for the back and one for the forward. Each time you click on a link, you add the current page to the back stack. Each time you click back, you add the current page to the forward stack. Clicking a new link clears the forward stack.
It'd have to work for the search, too. So any time someone browses or searches I keep a reference to where they were browsing or the term they searched for. Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to navigation buttons working immediately, and though I've sped up the search considerably there's still some initial overhead in building the list of files to search. That will lead to irregular intervals of latency when users click the "back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when you click the Down arrow.
-Jonathan
- there are a number of libraries that show: "version: no
AUTHOR tag or
values" while the author: field is filled out.
Which library? I'll check it out.
A few of them, I just opened up the libraries view and skimmed the list.
Ok, that's fixed: https://puredata.info/Members/jancsika/searchandbrowseplugin/view
.hc
Thanks, Jonathan
.hc
-Jonathan
The progress bar is a good enhancement. I wonder if it could
somehow fit
in to the
GUI elements better somehow. Its fine how it is, but it
seems a little
out of
place.
Looks like there are some debug messages still in it, I get
these when
hovering:
filename is 5.reference/all_about_arrays.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/loop~-help.pd basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
filename is 5.reference/all_about_arrays.pd filelist is 7751 filelist is 7751
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
And now it's refactored as a literal drop-in replacement for helpbrowser.tcl: https://sourceforge.net/tracker/?func=detail&aid=3585469&group_id=55...
It seems to have outgrown its "dialog" window class, but I manually added the standard pd dialog bindings, so ESC will withdraw the window. (It will also stop the search in progress, too.)
If anyone wants me to add any tutorials or docs that I'm missing to the browser's homepage, let me know. The neat thing is that if it gets large I can tag the entries and the dropdown list can be used to filter the homepage (just like it does with search results).
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 9:34 PM Subject: Re: [PD] Browse/Search plugin update
Another update... https://puredata.info/Members/jancsika/searchandbrowseplugin/view
- fixed some small bugs with the navigation bar and
<ctrl-f> throwing a tk error.
I also played around with limiting search scope to the directory the user is currently browsing, but really it's a lot cleaner to keep the two functions separate. I think new users will save a lot of time by just getting used to searching and forgo browsing altogether. If things are tagged properly it shouldn't really matter what directory the information is in. (And besides, if you really need to know it's at the top of the patch window anyway.)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 2:06 PM Subject: Re: [PD] Browse/Search plugin update
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 11:21 AM Subject: Re: [PD] Browse/Search plugin update
[...]
For back/forward buttons, couldn't you just store a reference to
each
page? Basically you have two stacks, one for the back and one for the
forward.
Each time you click on a link, you add the current page to the back stack.
Each
time you click back, you add the current page to the forward stack.
Clicking a
new link clears the forward stack.
It'd have to work for the search, too. So any time someone browses or searches I keep a reference to where they were browsing or the term they searched
for.
Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to navigation
buttons
working immediately, and though I've sped up the search considerably there's still some
initial
overhead in building the list of files to search. That will lead to irregular intervals of latency when users click
the
"back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when you click
the
Down arrow.
-Jonathan
* there are a number of libraries that show: "version: no
AUTHOR tag or
values" while the author: field is filled out.
Which library? I'll check it out.
A few of them, I just opened up the libraries view and skimmed the
list.
Ok, that's fixed: https://puredata.info/Members/jancsika/searchandbrowseplugin/view
.hc
Thanks, Jonathan
.hc
-Jonathan
> The > progress bar is a good enhancement. I wonder if it
could
somehow fit
in to the
> GUI elements better somehow. Its fine how it is, but
it
seems a little
out of
> place. > > Looks like there are some debug messages still in it,
I get
these when
hovering:
> > filename is 5.reference/all_about_arrays.pd > basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
> filename is 5.reference/loop~-help.pd > basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
> filename is 5.reference/all_about_arrays.pd > filelist is 7751 > filelist is 7751 > > .hc >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That's really great work Jonathan - thank you.
Julian
On 8 November 2012 22:06, Jonathan Wilkes jancsika@yahoo.com wrote:
And now it's refactored as a literal drop-in replacement for helpbrowser.tcl:
https://sourceforge.net/tracker/?func=detail&aid=3585469&group_id=55...
It seems to have outgrown its "dialog" window class, but I manually added the standard pd dialog bindings, so ESC will withdraw the window. (It will also stop the search in progress, too.)
If anyone wants me to add any tutorials or docs that I'm missing to the browser's homepage, let me know. The neat thing is that if it gets large I can tag the entries and the dropdown list can be used to filter the homepage (just like it does with search results).
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner <
hans@at.or.at>
Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 9:34 PM Subject: Re: [PD] Browse/Search plugin update
Another update... https://puredata.info/Members/jancsika/searchandbrowseplugin/view
- fixed some small bugs with the navigation bar and
<ctrl-f> throwing a tk error.
I also played around with limiting search scope to the directory the user is currently browsing, but really it's a lot cleaner to keep the two functions separate. I think new users will save a lot of time by just getting used to searching and forgo browsing altogether. If things are tagged properly it shouldn't really matter what directory the information is in. (And besides, if you really need to know it's at the top of the patch window anyway.)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 2:06 PM Subject: Re: [PD] Browse/Search plugin update
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 11:21 AM Subject: Re: [PD] Browse/Search plugin update
[...]
For back/forward buttons, couldn't you just store a reference to
each
page? Basically you have two stacks, one for the back and one for the
forward.
Each time you click on a link, you add the current page to the back
stack.
Each
time you click back, you add the current page to the forward stack.
Clicking a
new link clears the forward stack.
It'd have to work for the search, too. So any time someone browses or searches I keep a reference to where they were browsing or the term they searched
for.
Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to navigation
buttons
working immediately, and though I've sped up the search considerably there's still some
initial
overhead in building the list of files to search. That will lead to irregular intervals of latency when users
click
the
"back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when you
click
the
Down arrow.
-Jonathan
- there are a number of libraries that show: "version: no
AUTHOR tag or
values" while the author: field is filled out.
Which library? I'll check it out.
A few of them, I just opened up the libraries view and skimmed the
list.
Ok, that's fixed: https://puredata.info/Members/jancsika/searchandbrowseplugin/view
.hc
Thanks, Jonathan
.hc
> > -Jonathan > >> The >> progress bar is a good enhancement. I wonder if it
could
somehow fit
in to the >> GUI elements better somehow. Its fine how it is, but
it
seems a little
out of >> place. >> >> Looks like there are some debug messages still in it,
I get
these when
hovering: >> >> filename is 5.reference/all_about_arrays.pd >> basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>> filename is 5.reference/loop~-help.pd >> basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>> filename is 5.reference/all_about_arrays.pd >> filelist is 7751 >> filelist is 7751 >> >> .hc >>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Jonathan,
This is a great plugin! My only issue is a visual one, which might be a bit nit-picky, but I'm sure I'm not the only one who'll come across it. I'm using a dark OS theme (default theme from KXStudio) that uses light grey fonts on black backgrounds. So for me, your plug-in is using a grey font on a white background for the .resultstext widget, making them hard to read (see attached). I found that not setting the -bg option defaults to a black background, or just set -fg black works as a quick fix. Also, since the default background for my theme is black, the grey backgrounds for the tkk widgets don't match. I'm guessing sticking all the widgets in a single frame would make the whole background grey, but my Tk is very beginner level, so I didn't try this yet, nor do I know if it's the best solution.
.mmb
On Thu, Nov 1, 2012 at 8:34 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Another update... https://puredata.info/Members/jancsika/searchandbrowseplugin/view
- fixed some small bugs with the navigation bar and
<ctrl-f> throwing a tk error.
I also played around with limiting search scope to the directory the user is currently browsing, but really it's a lot cleaner to keep the two functions separate. I think new users will save a lot of time by just getting used to searching and forgo browsing altogether. If things are tagged properly it shouldn't really matter what directory the information is in. (And besides, if you really need to know it's at the top of the patch window anyway.)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 2:06 PM Subject: Re: [PD] Browse/Search plugin update
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 11:21 AM Subject: Re: [PD] Browse/Search plugin update
[...]
For back/forward buttons, couldn't you just store a reference to each
page? Basically you have two stacks, one for the back and one for the forward. Each time you click on a link, you add the current page to the back stack. Each time you click back, you add the current page to the forward stack. Clicking a new link clears the forward stack.
It'd have to work for the search, too. So any time someone browses or searches I keep a reference to where they were browsing or the term they searched for. Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to navigation buttons working immediately, and though I've sped up the search considerably there's still some initial overhead in building the list of files to search. That will lead to irregular intervals of latency when users click the "back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when you click the Down arrow.
-Jonathan
- there are a number of libraries that show: "version: no
AUTHOR tag or
values" while the author: field is filled out.
Which library? I'll check it out.
A few of them, I just opened up the libraries view and skimmed the list.
Ok, that's fixed: https://puredata.info/Members/jancsika/searchandbrowseplugin/view
.hc
Thanks, Jonathan
.hc
-Jonathan
> The > progress bar is a good enhancement. I wonder if it could
somehow fit
in to the
> GUI elements better somehow. Its fine how it is, but it
seems a little
out of
> place. > > Looks like there are some debug messages still in it, I get
these when
hovering:
> > filename is 5.reference/all_about_arrays.pd > basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
> filename is 5.reference/loop~-help.pd > basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
> filename is 5.reference/all_about_arrays.pd > filelist is 7751 > filelist is 7751 > > .hc >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Mike Moser-Booth mmoserbooth@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Saturday, November 10, 2012 5:32 PM Subject: Re: [PD] Browse/Search plugin update
Hello Jonathan,
This is a great plugin! My only issue is a visual one, which might be a bit nit-picky, but I'm sure I'm not the only one who'll come across it. I'm using a dark OS theme (default theme from KXStudio) that uses light grey fonts on black backgrounds. So for me, your plug-in is using a grey font on a white background for the .resultstext widget, making them hard to read (see attached). I found that not setting the -bg option defaults to a black background, or just set -fg black works as a quick fix.
It's a bit problematic because the user won't be able to set the color of links which are hard-coded to be blue, so if they have a theme of white on blue or something they wouldn't show up. I think I should just set the other fonts in the results to black and keep the bg white, which will guarantee it looks the same across all platforms.
Also, since the default background for my theme is black, the grey backgrounds for the tkk widgets don't match. I'm guessing sticking all the widgets in a single frame would make the whole background grey, but my Tk is very beginner level, so I didn't try this yet, nor do I know if it's the best solution.
I'll work on this. Can you send a screenshot of some other properties dialogs or path dialogs so I can compare?
Thanks, Jonathan
.mmb
On Thu, Nov 1, 2012 at 8:34 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Another update... https://puredata.info/Members/jancsika/searchandbrowseplugin/view
- fixed some small bugs with the navigation bar and
<ctrl-f> throwing a tk error.
I also played around with limiting search scope to the directory the user is currently browsing, but really it's a lot cleaner to keep the two functions separate. I think new users will save a lot of time by just getting used to searching and forgo browsing altogether. If things are tagged properly it shouldn't really matter what directory the information is in. (And besides, if you really need to know it's at the top of the patch window anyway.)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 2:06 PM Subject: Re: [PD] Browse/Search plugin update
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 11:21 AM Subject: Re: [PD] Browse/Search plugin update
[...]
For back/forward buttons, couldn't you just store a reference
to each
page? Basically you have two stacks, one for the back and one for the
forward.
Each time you click on a link, you add the current page to the back
stack. Each
time you click back, you add the current page to the forward stack.
Clicking a
new link clears the forward stack.
It'd have to work for the search, too. So any time someone browses
or
searches I keep a reference to where they were browsing or the term they searched
for.
Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to navigation
buttons
working immediately, and though I've sped up the search considerably there's still some
initial
overhead in building the list of files to search. That will lead to irregular intervals of latency when users
click the
"back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when you
click the
Down arrow.
-Jonathan
* there are a number of libraries that show:
"version: no
AUTHOR tag or
values" while the author: field is filled out.
Which library? I'll check it out.
A few of them, I just opened up the libraries view and skimmed the
list.
Ok, that's fixed: https://puredata.info/Members/jancsika/searchandbrowseplugin/view
.hc
Thanks, Jonathan
.hc
> > -Jonathan > >> The >> progress bar is a good enhancement. I wonder if
it could
somehow fit
in to the >> GUI elements better somehow. Its fine how it is,
but it
seems a little
out of >> place. >> >> Looks like there are some debug messages still in
it, I get
these when
hovering: >> >> filename is 5.reference/all_about_arrays.pd >> basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>> filename is 5.reference/loop~-help.pd >> basedir is
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>> filename is 5.reference/all_about_arrays.pd >> filelist is 7751 >> filelist is 7751 >> >> .hc >>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Mike Moser-Booth - mmoserbooth@gmail.com Master's Student in Music Technology Schulich School of Music, McGill University Centre for Interdisciplinary Research in Music Media and Technology
"Words that make questions may not be questions at all." -- Neil deGrasse Tyson
Here you go.
.mmb
On Sat, Nov 10, 2012 at 5:51 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Mike Moser-Booth mmoserbooth@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Saturday, November 10, 2012 5:32 PM Subject: Re: [PD] Browse/Search plugin update
Hello Jonathan,
This is a great plugin! My only issue is a visual one, which might be a bit nit-picky, but I'm sure I'm not the only one who'll come across it. I'm using a dark OS theme (default theme from KXStudio) that uses light grey fonts on black backgrounds. So for me, your plug-in is using a grey font on a white background for the .resultstext widget, making them hard to read (see attached). I found that not setting the -bg option defaults to a black background, or just set -fg black works as a quick fix.
It's a bit problematic because the user won't be able to set the color of links which are hard-coded to be blue, so if they have a theme of white on blue or something they wouldn't show up. I think I should just set the other fonts in the results to black and keep the bg white, which will guarantee it looks the same across all platforms.
Also, since the default background for my theme is black, the grey backgrounds for the tkk widgets don't match. I'm guessing sticking all the widgets in a single frame would make the whole background grey, but my Tk is very beginner level, so I didn't try this yet, nor do I know if it's the best solution.
I'll work on this. Can you send a screenshot of some other properties dialogs or path dialogs so I can compare?
Thanks, Jonathan
.mmb
On Thu, Nov 1, 2012 at 8:34 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Another update... https://puredata.info/Members/jancsika/searchandbrowseplugin/view
- fixed some small bugs with the navigation bar and
<ctrl-f> throwing a tk error.
I also played around with limiting search scope to the directory the user is currently browsing, but really it's a lot cleaner to keep the two functions separate. I think new users will save a lot of time by just getting used to searching and forgo browsing altogether. If things are tagged properly it shouldn't really matter what directory the information is in. (And besides, if you really need to know it's at the top of the patch window anyway.)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 2:06 PM Subject: Re: [PD] Browse/Search plugin update
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 11:21 AM Subject: Re: [PD] Browse/Search plugin update
[...]
For back/forward buttons, couldn't you just store a reference
to each
page? Basically you have two stacks, one for the back and one for the
forward.
Each time you click on a link, you add the current page to the back
stack. Each
time you click back, you add the current page to the forward stack.
Clicking a
new link clears the forward stack.
It'd have to work for the search, too. So any time someone browses
or
searches I keep a reference to where they were browsing or the term they searched
for.
Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to navigation
buttons
working immediately, and though I've sped up the search considerably there's still some
initial
overhead in building the list of files to search. That will lead to irregular intervals of latency when users
click the
"back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when you
click the
Down arrow.
-Jonathan
> * there are a number of libraries that show:
"version: no
AUTHOR tag or
> values" while the author: field is filled out.
Which library? I'll check it out.
A few of them, I just opened up the libraries view and skimmed the
list.
Ok, that's fixed: https://puredata.info/Members/jancsika/searchandbrowseplugin/view
.hc
Thanks, Jonathan
> > .hc > > > > > >> >> -Jonathan >> >>> The >>> progress bar is a good enhancement. I wonder if
it could
somehow fit
> in to the >>> GUI elements better somehow. Its fine how it is,
but it
seems a little
> out of >>> place. >>> >>> Looks like there are some debug messages still in
it, I get
these when
> hovering: >>> >>> filename is 5.reference/all_about_arrays.pd >>> basedir is >
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>> filename is 5.reference/loop~-help.pd >>> basedir is >
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>> filename is 5.reference/all_about_arrays.pd >>> filelist is 7751 >>> filelist is 7751 >>> >>> .hc >>> >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Mike Moser-Booth - mmoserbooth@gmail.com Master's Student in Music Technology Schulich School of Music, McGill University Centre for Interdisciplinary Research in Music Media and Technology
"Words that make questions may not be questions at all." -- Neil deGrasse Tyson
Would it be possible to put usage instructions on the download page?
On 11 November 2012 07:02, Mike Moser-Booth mmoserbooth@gmail.com wrote:
Here you go.
.mmb
On Sat, Nov 10, 2012 at 5:51 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Mike Moser-Booth mmoserbooth@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Saturday, November 10, 2012 5:32 PM Subject: Re: [PD] Browse/Search plugin update
Hello Jonathan,
This is a great plugin! My only issue is a visual one, which might be a bit nit-picky, but I'm sure I'm not the only one who'll come across it. I'm using a dark OS theme (default theme from KXStudio) that uses light grey fonts on black backgrounds. So for me, your plug-in is using a grey font on a white background for the .resultstext widget, making them hard to read (see attached). I found that not setting the -bg option defaults to a black background, or just set -fg black works as a quick fix.
It's a bit problematic because the user won't be able to set the color of links which are hard-coded to be blue, so if they have a theme of white on blue or something they wouldn't show up. I think I should just set the other fonts in the results to black and keep the bg white, which will guarantee it looks the same across all platforms.
Also, since the default background for my theme is black, the grey backgrounds for the tkk widgets don't match. I'm guessing sticking all the widgets in a single frame would make the whole background grey, but my Tk is very beginner level, so I didn't try this yet, nor do I know if it's the best solution.
I'll work on this. Can you send a screenshot of some other properties dialogs or path dialogs so I can compare?
Thanks, Jonathan
.mmb
On Thu, Nov 1, 2012 at 8:34 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Another update... https://puredata.info/Members/jancsika/searchandbrowseplugin/view
- fixed some small bugs with the navigation bar and
<ctrl-f> throwing a tk error.
I also played around with limiting search scope to the directory the user is currently browsing, but really it's a lot cleaner to keep the two functions separate. I think new users will save a lot of time by just getting used to searching and forgo browsing altogether. If things are tagged properly it shouldn't really matter what directory the information is in. (And besides, if you really need to know it's at the top of the patch window anyway.)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 2:06 PM Subject: Re: [PD] Browse/Search plugin update
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 11:21 AM Subject: Re: [PD] Browse/Search plugin update
[...]
For back/forward buttons, couldn't you just store a reference
to each
page? Basically you have two stacks, one for the back and one for the
forward.
Each time you click on a link, you add the current page to the back
stack. Each
time you click back, you add the current page to the forward stack.
Clicking a
new link clears the forward stack.
It'd have to work for the search, too. So any time someone browses
or
searches I keep a reference to where they were browsing or the term they searched
for.
Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to navigation
buttons
working immediately, and though I've sped up the search considerably there's still some
initial
overhead in building the list of files to search. That will lead to irregular intervals of latency when users
click the
"back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when you
click the
Down arrow.
-Jonathan
>> * there are a number of libraries that show:
"version: no
AUTHOR tag or
>> values" while the author: field is filled out. > > Which library? I'll check it out.
A few of them, I just opened up the libraries view and skimmed the
list.
Ok, that's fixed: https://puredata.info/Members/jancsika/searchandbrowseplugin/view
.hc
> > Thanks, > Jonathan > >> >> .hc >> >> >> >> >> >>> >>> -Jonathan >>> >>>> The >>>> progress bar is a good enhancement. I wonder if
it could
somehow fit
>> in to the >>>> GUI elements better somehow. Its fine how it is,
but it
seems a little
>> out of >>>> place. >>>> >>>> Looks like there are some debug messages still in
it, I get
these when
>> hovering: >>>> >>>> filename is 5.reference/all_about_arrays.pd >>>> basedir is >>
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>>> filename is 5.reference/loop~-help.pd >>>> basedir is >>
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>>> filename is 5.reference/all_about_arrays.pd >>>> filelist is 7751 >>>> filelist is 7751 >>>> >>>> .hc >>>> >>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Mike Moser-Booth - mmoserbooth@gmail.com Master's Student in Music Technology Schulich School of Music, McGill University Centre for Interdisciplinary Research in Music Media and Technology
"Words that make questions may not be questions at all." -- Neil deGrasse Tyson
-- Mike Moser-Booth - mmoserbooth@gmail.com Master's Student in Music Technology Schulich School of Music, McGill University Centre for Interdisciplinary Research in Music Media and Technology
"Words that make questions may not be questions at all." -- Neil deGrasse Tyson
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Unfortunately I can't get Gnome themes to be reflected inside any of the tk stuff, so it's hard for me to test this. I'll try figuring it out at some point but in the meantime if you hit upon a setting that reflects your os theme _without_ screwing up the default look on winxp, macos or tk defaults then let me know.
Without Pd-wide GUI prefs it's always going to be a subpar experience for you, however-- I doubt blue links on a black bg will look great.
-Jonathan
----- Original Message -----
From: Mike Moser-Booth mmoserbooth@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Sunday, November 11, 2012 2:02 AM Subject: Re: [PD] Browse/Search plugin update
Here you go.
.mmb
On Sat, Nov 10, 2012 at 5:51 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Mike Moser-Booth mmoserbooth@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Saturday, November 10, 2012 5:32 PM Subject: Re: [PD] Browse/Search plugin update
Hello Jonathan,
This is a great plugin! My only issue is a visual one, which might be a bit nit-picky, but I'm sure I'm not the only one who'll
come
across it. I'm using a dark OS theme (default theme from KXStudio) that
uses
light grey fonts on black backgrounds. So for me, your plug-in is using a grey font on a white background for the .resultstext widget, making them hard to read (see attached). I found that not setting the -bg option defaults to a black background, or just set -fg black works as a quick fix.
It's a bit problematic because the user won't be able to set the
color of
links which are hard-coded to be blue, so if they have a theme of white on blue or something they wouldn't show up. I think I should just set
the
other fonts in the results to black and keep the bg white, which will guarantee it looks the same across all platforms.
Also, since the default background for my theme is black, the grey backgrounds for the tkk widgets don't match.
I'm
guessing sticking all the widgets in a single frame would make the whole background grey, but my Tk is very beginner level, so I
didn't
try this yet, nor do I know if it's the best solution.
I'll work on this. Can you send a screenshot of some other properties dialogs or path dialogs so I can compare?
Thanks, Jonathan
.mmb
On Thu, Nov 1, 2012 at 8:34 PM, Jonathan Wilkes
wrote:
Another update... https://puredata.info/Members/jancsika/searchandbrowseplugin/view
* fixed some small bugs with the navigation bar and <ctrl-f> throwing a tk error.
I also played around with limiting search scope to the directory
the
user is currently browsing, but really it's a lot cleaner to
keep the
two functions separate. I think new users will save a lot of time
by
just getting used to searching and forgo browsing altogether. If things are tagged properly it shouldn't really matter what
directory
the information is in. (And besides, if you really need to know
it's
at the top of the patch window anyway.)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 2:06 PM Subject: Re: [PD] Browse/Search plugin update
________________________________ From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 11:21 AM Subject: Re: [PD] Browse/Search plugin update
[...]
For back/forward buttons, couldn't you just store a
reference
to each
page? Basically you have two stacks, one for the back and one
for the
forward.
Each time you click on a link, you add the current page to the
back
stack. Each
time you click back, you add the current page to the forward
stack.
Clicking a
new link clears the forward stack.
It'd have to work for the search, too. So any time
someone browses
or
searches I keep a reference to where they were browsing or the term they
searched
for.
Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to
navigation
buttons
working immediately, and though I've sped up the search considerably there's
still some
initial
overhead in building the list of files to search. That will lead to irregular intervals of latency when
users
click the
"back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when
you
click the
Down arrow.
-Jonathan
>> * there are a number of libraries that show:
"version: no
AUTHOR tag or
>> values" while the author: field is filled
out.
> > Which library? I'll check it out.
A few of them, I just opened up the libraries view and
skimmed the
list.
Ok, that's fixed:
https://puredata.info/Members/jancsika/searchandbrowseplugin/view
.hc
> > Thanks, > Jonathan > >> >> .hc >> >> >> >> >> >>> >>> -Jonathan >>> >>>> The >>>> progress bar is a good enhancement. I
wonder if
it could
somehow fit
>> in to the >>>> GUI elements better somehow. Its fine
how it is,
but it
seems a little
>> out of >>>> place. >>>> >>>> Looks like there are some debug messages
still in
it, I get
these when
>> hovering: >>>> >>>> filename is
5.reference/all_about_arrays.pd
>>>> basedir is >>
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>>> filename is 5.reference/loop~-help.pd >>>> basedir is >>
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>>> filename is
5.reference/all_about_arrays.pd
>>>> filelist is 7751 >>>> filelist is 7751 >>>> >>>> .hc >>>> >>
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Mike Moser-Booth - mmoserbooth@gmail.com Master's Student in Music Technology Schulich School of Music, McGill University Centre for Interdisciplinary Research in Music Media and Technology
"Words that make questions may not be questions at all." --
Neil
deGrasse Tyson
-- Mike Moser-Booth - mmoserbooth@gmail.com Master's Student in Music Technology Schulich School of Music, McGill University Centre for Interdisciplinary Research in Music Media and Technology
"Words that make questions may not be questions at all." -- Neil deGrasse Tyson
You can make Pd-wide GUI prefs using GUI plugins that use the Tk 'options' command. There are some examples here:
http://puredata.info/docs/guiplugins
.hc
On Nov 11, 2012, at 3:39 PM, Jonathan Wilkes wrote:
Unfortunately I can't get Gnome themes to be reflected inside any of the tk stuff, so it's hard for me to test this. I'll try figuring it out at some point but in the meantime if you hit upon a setting that reflects your os theme _without_ screwing up the default look on winxp, macos or tk defaults then let me know.
Without Pd-wide GUI prefs it's always going to be a subpar experience for you, however-- I doubt blue links on a black bg will look great.
-Jonathan
----- Original Message -----
From: Mike Moser-Booth mmoserbooth@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Sunday, November 11, 2012 2:02 AM Subject: Re: [PD] Browse/Search plugin update
Here you go.
.mmb
On Sat, Nov 10, 2012 at 5:51 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Mike Moser-Booth mmoserbooth@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Saturday, November 10, 2012 5:32 PM Subject: Re: [PD] Browse/Search plugin update
Hello Jonathan,
This is a great plugin! My only issue is a visual one, which might be a bit nit-picky, but I'm sure I'm not the only one who'll
come
across it. I'm using a dark OS theme (default theme from KXStudio) that
uses
light grey fonts on black backgrounds. So for me, your plug-in is using a grey font on a white background for the .resultstext widget, making them hard to read (see attached). I found that not setting the -bg option defaults to a black background, or just set -fg black works as a quick fix.
It's a bit problematic because the user won't be able to set the
color of
links which are hard-coded to be blue, so if they have a theme of white on blue or something they wouldn't show up. I think I should just set
the
other fonts in the results to black and keep the bg white, which will guarantee it looks the same across all platforms.
Also, since the default background for my theme is black, the grey backgrounds for the tkk widgets don't match.
I'm
guessing sticking all the widgets in a single frame would make the whole background grey, but my Tk is very beginner level, so I
didn't
try this yet, nor do I know if it's the best solution.
I'll work on this. Can you send a screenshot of some other properties dialogs or path dialogs so I can compare?
Thanks, Jonathan
.mmb
On Thu, Nov 1, 2012 at 8:34 PM, Jonathan Wilkes
wrote:
Another update... https://puredata.info/Members/jancsika/searchandbrowseplugin/view
- fixed some small bugs with the navigation bar and
<ctrl-f> throwing a tk error.
I also played around with limiting search scope to the directory
the
user is currently browsing, but really it's a lot cleaner to
keep the
two functions separate. I think new users will save a lot of time
by
just getting used to searching and forgo browsing altogether. If things are tagged properly it shouldn't really matter what
directory
the information is in. (And besides, if you really need to know
it's
at the top of the patch window anyway.)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD List pd-list@iem.at Sent: Thursday, November 1, 2012 2:06 PM Subject: Re: [PD] Browse/Search plugin update
> ________________________________ > From: Hans-Christoph Steiner hans@at.or.at > To: Jonathan Wilkes jancsika@yahoo.com > Cc: PD List pd-list@iem.at > Sent: Thursday, November 1, 2012 11:21 AM > Subject: Re: [PD] Browse/Search plugin update > >
[...]
> For back/forward buttons, couldn't you just store a
reference
to each
page? Basically you have two stacks, one for the back and one
for the
forward.
Each time you click on a link, you add the current page to the
back
stack. Each
time you click back, you add the current page to the forward
stack.
Clicking a
new link clears the forward stack.
It'd have to work for the search, too. So any time
someone browses
or
searches I keep a reference to where they were browsing or the term they
searched
for.
Then just add some forward/back buttons and bind to the arrow keys and the interface is done.
I think this would cause problems. Users are accustomed to
navigation
buttons
working immediately, and though I've sped up the search considerably there's
still some
initial
overhead in building the list of files to search. That will lead to irregular intervals of latency when
users
click the
"back" a bunch of times in a row (and users will certainly do that once the feature is there).
Anyway, the search combobox has a history you can display when
you
click the
Down arrow.
-Jonathan
> >>> * there are a number of libraries that show:
"version: no
AUTHOR tag or >>> values" while the author: field is filled
out.
>> >> Which library? I'll check it out. > > A few of them, I just opened up the libraries view and
skimmed the
list.
Ok, that's fixed:
https://puredata.info/Members/jancsika/searchandbrowseplugin/view
> > .hc > > >> >> Thanks, >> Jonathan >> >>> >>> .hc >>> >>> >>> >>> >>> >>>> >>>> -Jonathan >>>> >>>>> The >>>>> progress bar is a good enhancement. I
wonder if
it could
somehow fit >>> in to the >>>>> GUI elements better somehow. Its fine
how it is,
but it
seems a little >>> out of >>>>> place. >>>>> >>>>> Looks like there are some debug messages
still in
it, I get
these when >>> hovering: >>>>> >>>>> filename is
5.reference/all_about_arrays.pd
>>>>> basedir is >>>
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>>>> filename is 5.reference/loop~-help.pd >>>>> basedir is >>>
/Applications/Pd-0.43.3-extended-20121008.app/Contents/Resources/doc
>>>>> filename is
5.reference/all_about_arrays.pd
>>>>> filelist is 7751 >>>>> filelist is 7751 >>>>> >>>>> .hc >>>>> >>> > > > >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Mike Moser-Booth - mmoserbooth@gmail.com Master's Student in Music Technology Schulich School of Music, McGill University Centre for Interdisciplinary Research in Music Media and Technology
"Words that make questions may not be questions at all." --
Neil
deGrasse Tyson
-- Mike Moser-Booth - mmoserbooth@gmail.com Master's Student in Music Technology Schulich School of Music, McGill University Centre for Interdisciplinary Research in Music Media and Technology
"Words that make questions may not be questions at all." -- Neil deGrasse Tyson
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: PD List pd-list@iem.at Sent: Wednesday, October 31, 2012 11:46 PM Subject: Re: [PD] Browse/Search plugin update
[...]
- it lacks a clear way to go back a level, I think this would be well handled by
standard back/forward buttons like are in internet browsers, file browsers, etc.
Just to be clear-- it matches the ability of the <ctrl-b> browser to go back a level when _browsing_. The current level is at the top of the widget, with the previous levels hyperlinked. It just doesn't remember previous searches.
-
Antonio Roberts -
Hans-Christoph Steiner -
Jonathan Wilkes -
Julian Brooks -
me.grimm -
Mike Moser-Booth