[PD] Pd-extended 0.43 and Openbox

Hans-Christoph Steiner hans at at.or.at
Wed Oct 3 22:07:01 CEST 2012


On 10/03/2012 03:47 PM, Nicola Pandini wrote:
> Il 03/10/2012 18:44, Hans-Christoph Steiner ha scritto:
>> On 10/03/2012 07:49 AM, Nicola Pandini wrote:
>>> Il 02/10/2012 16:43, Hans-Christoph Steiner ha scritto:
>>>> The problem is caused by how Tk and X11 measures window frames: it
>>>> measures it including all of the chrome around the window (the
>>>> button/title bar on the top, any framing on the bottom, etc.)  The
>>>> window framing/chrome varies a lot depending on which window manager,
>>>> etc. you are using.
>>>>
>>>> http://wiki.tcl.tk/11502
>>>>
>>>> Pd-extended places windows based on how things measure using a
>>>> standard GNOME install, since GNOME is the default on most distros.
>>>>
>>>> So what you need to do is write a plugin that sets custom values for
>>>> your window manager.  I think these are the variables you need, but
>>>> look in pd/tcl/pdtk_canvas.tcl for more info:
>>>>
>>>> set ::windowframex 5   (play with the numbers to get it right)
>>>> set ::windowframey 5
>>>>
>>>> Once you get it working, post it to the puredata.info/downloads page
>>>> so others can download it if they're using the same window manager.
>>>> There are lots of other things you can customize too, so you could
>>>> make a plugin that makes Pd feel as native as possible.
>>>>
>>>> .hc
>>>>
>>> Thanks for the help.
>>> I made some experiments with ::windowframex and ::windowframey and I
>>> found out the following things:
>>> With ::windowframex = 1 and ::windowframey = 49, a loaded patch is
>>> displayed correctly in the position previously saved. That's beacause
>>> 49 is the sum of the heights of the wm's title bar and the pd's menu
>>> bar, and 1 is the width of the wm frame.
>>> But with those settings the "new file" create a window outside the
>>> screen (x = -1, y = -49).
>>> To fix that, I have to set ::windowframex and ::windowframey to 0, but
>>> that makes the loading of a saved patch incorrect again (49 pixels
>>> below and 1 pixel to the left of the saved position).
>>>
>>> Is there different procedures to menage the "new file" and "open file"?
>> Look at pdtk_canvas.tcl, that's where this is happening.  The difference
>> is that with a new file, Pd is generating the x,y coords to place the
>> window, and with open file, its reading them from the first line of the
>> patch.
>>
>> I use GNOME, so I am not well versed in all these issues.  But I'm happy
>> to help you figure this out so that we can easily support all the
>> various WMs that people want to use.
>>
>> .hc
>>
>>
>> _______________________________________________
>> Pd-list at iem.at  mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list
>
> Hi, I'm happy too to be able to contribute, in a very small way, to Pd
> ;-)
> I'm not very familiar with Tcl, but I found that the lines that set
> the x-y coords are:
> set x [ expr $x % $screenwidth - $::windowframex]
> set y [ expr $y % $screenheight - $::windowframey]
> After some testing, I found outthat those lines generate the coords
> for both "new file" and  "open file"
>
> I also made some tests with ::windowframey=200 on Openbox and Gnome
> Shell: On Openbox, that value places a patch outside the screen (y =
> -200), but in Gnome Shell the same value places the patch right below
> the gnome bar (y = 0).
> It seems that only Openbox allows a patch's window to be placed
> outside the screen, while Gnome Shell sets every negative value of x
> and y to 0.
>
> For what I understand, to fix it, it needs to be used:
> set x [ expr $x % $screenwidth - $::windowframex]
> set y [ expr $y % $screenheight - $::windowframey]
> only for "open file", and
>
> set x 0
> set y 0
> for "new file".
>

Sounds like this should actually be:

set x [ expr max($x % $screenwidth - $::windowframex, 0)]
set y [ expr max($y % $screenheight - $::windowframey, 0)]

That would ensure that x and y are always >= 0. Does changing that in
pdtk_canvas.tcl solve your issue?

The tricky part here is that this would then break how Pd strictly sets
the position of existing patches based on the values on the first line
of the patch file.

.hc



More information about the Pd-list mailing list