Search plugin revision: *added status bar shows link locations and search text (if searching for a keyword tag)
- quoted text works, e.g., "it's a secret to everybody"
- regexes seem to work, e.g., "outlet.*symbol" will match all objects that output a symbol
- pd-style word boundaries, e.g., "clip~" works when "whole words" option is checked
- font +/- with ctrl-plus/ctrl-minus keys
-Jonathan
Its definitely getting quite polished. Two little details on Mac OS X
that are odd:
- on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the standard key for
increasing the size of the text. Currently, its Cmd-=.
- on Mac OS X, when I mouse over the object name in the search
results, the width of the whole window jumps, because the full path
displayed on the bottom of the window is a lot longer then the normal
window size would display.
.hc
On Aug 4, 2011, at 5:49 PM, Jonathan Wilkes wrote:
Search plugin revision:
- added status bar shows link locations and search text (if
searching for a keyword tag)
- quoted text works, e.g., "it's a secret to everybody"
- regexes seem to work, e.g., "outlet.*symbol" will match all
objects that output a symbol
- pd-style word boundaries, e.g., "clip~" works when "whole words"
option is checked
- font +/- with ctrl-plus/ctrl-minus keys
-Jonathan <search-plugin.tcl> _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you are not part of the solution, you are part of the problem.
On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote:
- on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the standard key for
increasing the size of the text. Currently, its Cmd-=.
It will break on keyboard layouts that are not QWERTY or that are heavily modified QWERTY.
When I designed some things in the default DD keyboard bindings, I only had US keyboard and CF-family keyboards in mind (french QWERTY used in Québec) and then someone notified me that I couldn't distinguish Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY (it's Shift-&, whereas & is not shifted).
German QWERTZ has = on Shift+0 and * on Shift++, meaning + is unshifted ; however, Swiss QWERTZ has + shifted as Shift+1, and then there are other QWERTZ than that...
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote:
On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote:
- on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the standard key for
increasing the size of the text. Currently, its Cmd-=.
It will break on keyboard layouts that are not QWERTY or that are
heavily modified QWERTY.When I designed some things in the default DD keyboard bindings, I
only had US keyboard and CF-family keyboards in mind (french QWERTY
used in Québec) and then someone notified me that I couldn't distinguish Alt +Shift+1 from Alt+1 because 1 is already shifted in AZERTY (it's
Shift-&, whereas & is not shifted).German QWERTZ has = on Shift+0 and * on Shift++, meaning + is
unshifted ; however, Swiss QWERTZ has + shifted as Shift+1, and then
there are other QWERTZ than that...
It'd be something to test, Cmd-+ might work as a keybinding, and would
then work on other keyboards. Or perhaps you can just bind to both
Cmd-Shift-+ and Cmd-+. For other platforms, its not a big deal since
the keybindings are not very consistent. On Mac OS X, they are quite
consistent across OS and apps, so people notice wrong bindings a lot
more.
.hc
“We must become the change we want to see. - Mahatma Gandhi
Ok, fixed the weird resizing issue when the text in the status area is larger than the window.
Fixed search window to appear at 0 0 on when it's first created.
Fixed font sizing bindings.
Fixed minimum font size.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list List pd-list@iem.at Sent: Sunday, August 7, 2011 5:38 PM Subject: Re: [PD] search plugin update
On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote:
On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote:
- on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the standard key for
increasing the size of the text. Currently, its Cmd-=.
It will break on keyboard layouts that are not QWERTY or that are heavily
modified QWERTY.
When I designed some things in the default DD keyboard bindings, I only had
US keyboard and CF-family keyboards in mind (french QWERTY used in
Québec) and then someone notified me that I couldn't distinguish
Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY (it's Shift-&, whereas & is not shifted).
German QWERTZ has = on Shift+0 and * on Shift++, meaning + is unshifted ;
however, Swiss QWERTZ has + shifted as Shift+1, and then there are other QWERTZ than that...
It'd be something to test, Cmd-+ might work as a keybinding, and would then work on other keyboards. Or perhaps you can just bind to both Cmd-Shift-+ and Cmd-+. For other platforms, its not a big deal since the keybindings are not very consistent. On Mac OS X, they are quite consistent across OS and apps, so people notice wrong bindings a lot more.
.hc
“We must become the change we want to see. - Mahatma Gandhi
0 0 is problematic on couple platforms. On Mac OS X, the menubar is
always there, so it puts the window header behind on menubar. A
similar problem happens on GNOME.
.hc
On Aug 25, 2011, at 5:33 PM, Jonathan Wilkes wrote:
Ok, fixed the weird resizing issue when the text in the status area
is larger than the window.Fixed search window to appear at 0 0 on when it's first created.
Fixed font sizing bindings.
Fixed minimum font size.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list List <pd-list@iem.at
Sent: Sunday, August 7, 2011 5:38 PM Subject: Re: [PD] search plugin update
On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote:
On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote:
- on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the standard key for
increasing the size of the text. Currently, its Cmd-=.
It will break on keyboard layouts that are not QWERTY or that are
heavilymodified QWERTY.
When I designed some things in the default DD keyboard bindings, I
only hadUS keyboard and CF-family keyboards in mind (french QWERTY used in
Québec) and then someone notified me that I couldn't distinguish
Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY (it's Shift-&, whereas & is not shifted).
German QWERTZ has = on Shift+0 and * on Shift++, meaning + is
unshifted ;however, Swiss QWERTZ has + shifted as Shift+1, and then there are
other QWERTZ than that...It'd be something to test, Cmd-+ might work as a keybinding, and
would then work on other keyboards. Or perhaps you can just bind to both Cmd- Shift-+ and Cmd-+. For other platforms, its not a big deal since the
keybindings are not very consistent. On Mac OS X, they are quite consistent across OS
and apps, so people notice wrong bindings a lot more..hc
“We must become the change we want to see. - Mahatma Gandhi
<search-plugin.tcl>
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Test1: Gnome 3 (Fedora 15) -- no problems Gnome 2.32.0 (Ubuntu Maverick) -- no problems
OSX 10.7 -- problem: window decoration behind Apple's menubar.
Test2: Tried a little stand-alone version of my plugin. Still specifying 0 0 screen coordinates, and
Apple automatically puts the ".search" window below the menu bar, as it does for everything
else I've ever seen in OSX except this issue.
Test3: Tried any number of my PDDP help patches, which all have 0 0 specified as the coordinates
for the patch window. Again, Apple does the right thing and shifts it down an appropriate amount.
Test4: Tried to fool wish on OSX into putting a toplevel underneath the menubar. Can't do it.
Hypothesis: Something isn't set correctly in pd-gui, but all I can see (at a glance) are options
that have nothing to do with window position, and some variables: menubarsize and windowframey.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; pd-list List pd-list@iem.at Sent: Sunday, August 28, 2011 10:13 PM Subject: Re: [PD] search plugin update
0 0 is problematic on couple platforms. On Mac OS X, the menubar is always there, so it puts the window header behind on menubar. A similar problem happens on GNOME.
.hc
On Aug 25, 2011, at 5:33 PM, Jonathan Wilkes wrote:
Ok, fixed the weird resizing issue when the text in the status area is
larger than the window.
Fixed search window to appear at 0 0 on when it's first created.
Fixed font sizing bindings.
Fixed minimum font size.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list List
Sent: Sunday, August 7, 2011 5:38 PM Subject: Re: [PD] search plugin update
On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote:
On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote:
- on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the standard key for
increasing the size of the text. Currently, its Cmd-=.
It will break on keyboard layouts that are not QWERTY or that are
heavily
modified QWERTY.
When I designed some things in the default DD keyboard bindings, I
only had
US keyboard and CF-family keyboards in mind (french QWERTY used in
Québec) and then someone notified me that I couldn't
distinguish
Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY (it's Shift-&, whereas & is not shifted).
German QWERTZ has = on Shift+0 and * on Shift++, meaning + is
unshifted ;
however, Swiss QWERTZ has + shifted as Shift+1, and then there are
other QWERTZ
than that...
It'd be something to test, Cmd-+ might work as a keybinding, and
would then
work on other keyboards. Or perhaps you can just bind to both
Cmd-Shift-+ and
Cmd-+. For other platforms, its not a big deal since the keybindings
are not
very consistent. On Mac OS X, they are quite consistent across OS and
apps, so
people notice wrong bindings a lot more.
.hc
“We must become the change we want to see. - Mahatma Gandhi
<search-plugin.tcl>
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
Interesting test results. It would be quite nice if Tcl/Tk handled
the window placement for non-PatchWindows. Part of the problem there
is that the .pd fileformat stores the location of the windows, and
therefore Pd explicitly places the windows using those coordinates.
That might be related here, but maybe not.
As for Test 3 & 4, that's not Apple that properly places the patch
window beneath the menubar, that's code in 'pd-gui'. Check out
pdtk_canvas_new in pdtk_canvas.tcl.
.hc
On Aug 29, 2011, at 1:03 AM, Jonathan Wilkes wrote:
Test1: Gnome 3 (Fedora 15) -- no problems Gnome 2.32.0 (Ubuntu Maverick) -- no problems
OSX 10.7 -- problem: window decoration behind Apple's menubar.
Test2: Tried a little stand-alone version of my plugin. Still specifying 0
0 screen coordinates, andApple automatically puts the ".search" window below the menu bar, as
it does for everythingelse I've ever seen in OSX except this issue.
Test3: Tried any number of my PDDP help patches, which all have 0 0
specified as the coordinatesfor the patch window. Again, Apple does the right thing and shifts
it down an appropriate amount.
Test4: Tried to fool wish on OSX into putting a toplevel underneath the
menubar. Can't do it.Hypothesis: Something isn't set correctly in pd-gui, but all I can
see (at a glance) are optionsthat have nothing to do with window position, and some variables:
menubarsize and windowframey.-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; pd-list List <pd-list@iem.at
Sent: Sunday, August 28, 2011 10:13 PM Subject: Re: [PD] search plugin update
0 0 is problematic on couple platforms. On Mac OS X, the menubar
is always there, so it puts the window header behind on menubar. A similar
problem happens on GNOME..hc
On Aug 25, 2011, at 5:33 PM, Jonathan Wilkes wrote:
Ok, fixed the weird resizing issue when the text in the status
area islarger than the window.
Fixed search window to appear at 0 0 on when it's first created.
Fixed font sizing bindings.
Fixed minimum font size.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list List
Sent: Sunday, August 7, 2011 5:38 PM Subject: Re: [PD] search plugin update
On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote:
On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote:
- on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the standard key for
increasing the size of the text. Currently, its Cmd-=.
It will break on keyboard layouts that are not QWERTY or that
areheavily
modified QWERTY.
When I designed some things in the default DD keyboard
bindings, Ionly had
US keyboard and CF-family keyboards in mind (french QWERTY used
inQuébec) and then someone notified me that I couldn't
distinguish
Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY
(it's Shift-&, whereas & is not shifted).German QWERTZ has = on Shift+0 and * on Shift++, meaning + is
unshifted ;
however, Swiss QWERTZ has + shifted as Shift+1, and then there
areother QWERTZ
than that...
It'd be something to test, Cmd-+ might work as a keybinding, and
would then
work on other keyboards. Or perhaps you can just bind to both
Cmd-Shift-+ and
Cmd-+. For other platforms, its not a big deal since the
keybindingsare not
very consistent. On Mac OS X, they are quite consistent across
OS andapps, so
people notice wrong bindings a lot more.
.hc
“We must become the change we want to see. - Mahatma Gandhi
<search-plugin.tcl>
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better language;
and every chapter must be so translated.... -John Donne<search-plugin.tcl>
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
I should clarify: test4 was me in wish, trying to find some combination of options to get the window to get stuck underneath Apple's menubar. I couldn't figure out how to do it.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; pd-list List pd-list@iem.at Sent: Monday, August 29, 2011 11:05 AM Subject: Re: Pd-gui bug (was Re: [PD] search plugin update)
Interesting test results. It would be quite nice if Tcl/Tk handled the window placement for non-PatchWindows. Part of the problem there is that the .pd fileformat stores the location of the windows, and therefore Pd explicitly places the windows using those coordinates. That might be related here, but maybe not.
As for Test 3 & 4, that's not Apple that properly places the patch window beneath the menubar, that's code in 'pd-gui'. Check out pdtk_canvas_new in pdtk_canvas.tcl.
.hc
On Aug 29, 2011, at 1:03 AM, Jonathan Wilkes wrote:
Test1: Gnome 3 (Fedora 15) -- no problems Gnome 2.32.0 (Ubuntu Maverick) -- no problems
OSX 10.7 -- problem: window decoration behind Apple's menubar.
Test2: Tried a little stand-alone version of my plugin. Still specifying 0 0
screen coordinates, and
Apple automatically puts the ".search" window below the menu bar,
as it does for everything
else I've ever seen in OSX except this issue.
Test3: Tried any number of my PDDP help patches, which all have 0 0 specified as
the coordinates
for the patch window. Again, Apple does the right thing and shifts it down
an appropriate amount.
Test4: Tried to fool wish on OSX into putting a toplevel underneath the menubar.
Can't do it.
Hypothesis: Something isn't set correctly in pd-gui, but all I can see
(at a glance) are options
that have nothing to do with window position, and some variables:
menubarsize and windowframey.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; pd-list List
Sent: Sunday, August 28, 2011 10:13 PM Subject: Re: [PD] search plugin update
0 0 is problematic on couple platforms. On Mac OS X, the menubar is
always
there, so it puts the window header behind on menubar. A similar
problem
happens on GNOME.
.hc
On Aug 25, 2011, at 5:33 PM, Jonathan Wilkes wrote:
Ok, fixed the weird resizing issue when the text in the status
area is
larger than the window.
Fixed search window to appear at 0 0 on when it's first
created.
Fixed font sizing bindings.
Fixed minimum font size.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list List
Sent: Sunday, August 7, 2011 5:38 PM Subject: Re: [PD] search plugin update
On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote:
On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote:
> - on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the
standard key for
increasing the size of the text. Currently, its Cmd-=.
It will break on keyboard layouts that are not QWERTY or
that are
heavily
modified QWERTY.
When I designed some things in the default DD keyboard
bindings, I
only had
US keyboard and CF-family keyboards in mind (french QWERTY
used in
Québec) and then someone notified me that I couldn't
distinguish
Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY
(it's
Shift-&, whereas & is not shifted).
German QWERTZ has = on Shift+0 and * on Shift++, meaning
- is
unshifted ;
however, Swiss QWERTZ has + shifted as Shift+1, and then
there are
other QWERTZ
than that...
It'd be something to test, Cmd-+ might work as a
keybinding, and
would then
work on other keyboards. Or perhaps you can just bind to
both
Cmd-Shift-+ and
Cmd-+. For other platforms, its not a big deal since the
keybindings
are not
very consistent. On Mac OS X, they are quite consistent
across OS and
apps, so
people notice wrong bindings a lot more.
.hc
“We must become the change we want to see. - Mahatma Gandhi
<search-plugin.tcl>
All mankind is of one author, and is one volume; when one man dies, one
chapter
is not torn out of the book, but translated into a better language; and
every
chapter must be so translated.... -John Donne
<search-plugin.tcl>
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; pd-list List pd-list@iem.at Sent: Monday, August 29, 2011 11:05 AM Subject: Re: Pd-gui bug (was Re: [PD] search plugin update)
Interesting test results. It would be quite nice if Tcl/Tk handled the window placement for non-PatchWindows. Part of the problem there is that the .pd fileformat stores the location of the windows, and therefore Pd explicitly places the windows using those coordinates. That might be related here, but maybe not.
As for Test 3 & 4, that's not Apple that properly places the patch window beneath the menubar, that's code in 'pd-gui'.
Test 2 and test 4 don't use pd-gui, and they get the correct result. The only time I can produce the bug is when pd-gui is in play-- that's why I think it's a bug there.
Later I'll try commenting out various init values and see what happens...
-Jonathan
Check out pdtk_canvas_new in pdtk_canvas.tcl.
.hc
On Aug 29, 2011, at 1:03 AM, Jonathan Wilkes wrote:
Test1: Gnome 3 (Fedora 15) -- no problems Gnome 2.32.0 (Ubuntu Maverick) -- no problems
OSX 10.7 -- problem: window decoration behind Apple's menubar.
Test2: Tried a little stand-alone version of my plugin. Still specifying 0 0
screen coordinates, and
Apple automatically puts the ".search" window below the menu bar,
as it does for everything
else I've ever seen in OSX except this issue.
Test3: Tried any number of my PDDP help patches, which all have 0 0 specified as
the coordinates
for the patch window. Again, Apple does the right thing and shifts it down
an appropriate amount.
Test4: Tried to fool wish on OSX into putting a toplevel underneath the menubar.
Can't do it.
Hypothesis: Something isn't set correctly in pd-gui, but all I can see
(at a glance) are options
that have nothing to do with window position, and some variables:
menubarsize and windowframey.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; pd-list List
Sent: Sunday, August 28, 2011 10:13 PM Subject: Re: [PD] search plugin update
0 0 is problematic on couple platforms. On Mac OS X, the menubar is
always
there, so it puts the window header behind on menubar. A similar
problem
happens on GNOME.
.hc
On Aug 25, 2011, at 5:33 PM, Jonathan Wilkes wrote:
Ok, fixed the weird resizing issue when the text in the status
area is
larger than the window.
Fixed search window to appear at 0 0 on when it's first
created.
Fixed font sizing bindings.
Fixed minimum font size.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list List
Sent: Sunday, August 7, 2011 5:38 PM Subject: Re: [PD] search plugin update
On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote:
On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote:
> - on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the
standard key for
increasing the size of the text. Currently, its Cmd-=.
It will break on keyboard layouts that are not QWERTY or
that are
heavily
modified QWERTY.
When I designed some things in the default DD keyboard
bindings, I
only had
US keyboard and CF-family keyboards in mind (french QWERTY
used in
Québec) and then someone notified me that I couldn't
distinguish
Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY
(it's
Shift-&, whereas & is not shifted).
German QWERTZ has = on Shift+0 and * on Shift++, meaning
- is
unshifted ;
however, Swiss QWERTZ has + shifted as Shift+1, and then
there are
other QWERTZ
than that...
It'd be something to test, Cmd-+ might work as a
keybinding, and
would then
work on other keyboards. Or perhaps you can just bind to
both
Cmd-Shift-+ and
Cmd-+. For other platforms, its not a big deal since the
keybindings
are not
very consistent. On Mac OS X, they are quite consistent
across OS and
apps, so
people notice wrong bindings a lot more.
.hc
“We must become the change we want to see. - Mahatma Gandhi
<search-plugin.tcl>
All mankind is of one author, and is one volume; when one man dies, one
chapter
is not torn out of the book, but translated into a better language; and
every
chapter must be so translated.... -John Donne
<search-plugin.tcl>
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
On Aug 29, 2011, at 12:47 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; pd-list List <pd-list@iem.at
Sent: Monday, August 29, 2011 11:05 AM Subject: Re: Pd-gui bug (was Re: [PD] search plugin update)
Interesting test results. It would be quite nice if Tcl/Tk handled
the window placement for non-PatchWindows. Part of the problem there is that
the .pd fileformat stores the location of the windows, and therefore Pd
explicitly places the windows using those coordinates. That might be related
here, but maybe not.As for Test 3 & 4, that's not Apple that properly places the patch window beneath the menubar, that's code in 'pd-gui'.
Test 2 and test 4 don't use pd-gui, and they get the correct
result. The only time I can produce the bug is when pd-gui is in play-- that's why I think
it's a bug there.Later I'll try commenting out various init values and see what
happens...
Ah, ok, my guess is that its because of the placement logic that I
described. But maybe not, since that placement logic should only apply
to things created with pdtk_canvas_new, IIRC.
.hc
-Jonathan
Check out pdtk_canvas_new in pdtk_canvas.tcl.
.hc
On Aug 29, 2011, at 1:03 AM, Jonathan Wilkes wrote:
Test1: Gnome 3 (Fedora 15) -- no problems Gnome 2.32.0 (Ubuntu Maverick) -- no problems
OSX 10.7 -- problem: window decoration behind Apple's menubar.
Test2: Tried a little stand-alone version of my plugin. Still specifying
0 0screen coordinates, and
Apple automatically puts the ".search" window below the menu bar,
as it does for everything
else I've ever seen in OSX except this issue.
Test3: Tried any number of my PDDP help patches, which all have 0 0
specified asthe coordinates
for the patch window. Again, Apple does the right thing and
shifts it downan appropriate amount.
Test4: Tried to fool wish on OSX into putting a toplevel underneath the
menubar.Can't do it.
Hypothesis: Something isn't set correctly in pd-gui, but all I can
see(at a glance) are options
that have nothing to do with window position, and some variables:
menubarsize and windowframey.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; pd-list List
Sent: Sunday, August 28, 2011 10:13 PM Subject: Re: [PD] search plugin update
0 0 is problematic on couple platforms. On Mac OS X, the menubar
isalways
there, so it puts the window header behind on menubar. A similar
problem
happens on GNOME.
.hc
On Aug 25, 2011, at 5:33 PM, Jonathan Wilkes wrote:
Ok, fixed the weird resizing issue when the text in the status
area is
larger than the window.
Fixed search window to appear at 0 0 on when it's first
created.
Fixed font sizing bindings.
Fixed minimum font size.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list List
Sent: Sunday, August 7, 2011 5:38 PM Subject: Re: [PD] search plugin update
On Aug 7, 2011, at 2:51 PM, Mathieu Bouchard wrote:
> On Sat, 6 Aug 2011, Hans-Christoph Steiner wrote: > >> - on Mac OS X Cmd-Shift-= (i.e. Cmd-+) is the
standard key for
increasing the size of the text. Currently, its Cmd-=. > > It will break on keyboard layouts that are not QWERTY or
that are
heavily
modified QWERTY. > > When I designed some things in the default DD keyboard
bindings, I
only had
US keyboard and CF-family keyboards in mind (french QWERTY
used in
> Québec) and then someone notified me that I couldn't
distinguish
Alt+Shift+1 from Alt+1 because 1 is already shifted in AZERTY
(it's
Shift-&, whereas & is not shifted). > > German QWERTZ has = on Shift+0 and * on Shift++, meaning
- is
unshifted ;
however, Swiss QWERTZ has + shifted as Shift+1, and then
there are
other QWERTZ
than that...
It'd be something to test, Cmd-+ might work as a
keybinding, and
would then
work on other keyboards. Or perhaps you can just bind to
both
Cmd-Shift-+ and
Cmd-+. For other platforms, its not a big deal since the
keybindings
are not
very consistent. On Mac OS X, they are quite consistent
across OS and
apps, so
people notice wrong bindings a lot more.
.hc
“We must become the change we want to see. - Mahatma Gandhi
<search-plugin.tcl>
All mankind is of one author, and is one volume; when one man
dies, onechapter
is not torn out of the book, but translated into a better
language; andevery
chapter must be so translated.... -John Donne
<search-plugin.tcl>
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
¡El pueblo unido jamás será vencido!
-
Hans-Christoph Steiner -
Jonathan Wilkes -
Mathieu Bouchard