[PD] Pd-gui bug (was Re: search plugin update)

[Jonathan Wilkes]

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 at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: Mathieu Bouchard <matju at artengine.ca>; pd-list List <pd-list at 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 at.or.at>
>>>  To: Jonathan Wilkes <jancsika at yahoo.com>
>>>  Cc: Mathieu Bouchard <matju at artengine.ca>; pd-list List 
> <pd-list at 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 at.or.at>
>>>>>    To: Mathieu Bouchard <matju at artengine.ca>
>>>>>    Cc: Jonathan Wilkes <jancsika at yahoo.com>; pd-list List
>>>  <pd-list at 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
>>>>    <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
>