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