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 <[email protected]> > To: Jonathan Wilkes <[email protected]> > Cc: Mathieu Bouchard <[email protected]>; pd-list List <[email protected]> > 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 <[email protected]> >>> To: Jonathan Wilkes <[email protected]> >>> Cc: Mathieu Bouchard <[email protected]>; pd-list List > <[email protected]> >>> 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 <[email protected]> >>>>> To: Mathieu Bouchard <[email protected]> >>>>> Cc: Jonathan Wilkes <[email protected]>; pd-list List >>> <[email protected]> >>>>> 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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
