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