Il 03/10/2012 22:07, Hans-Christoph Steiner ha scritto:
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.
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@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?
Yes! It's solved, Great! :-)
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
Now I'm beginning to understand how tcl works :-) It also works with this:
if {$geometry == "+0+0"} { set x 0 set y 0 } else { set x [ expr $x % $screenwidth - $::windowframex] set y [ expr $y % $screenheight - $::windowframey] }
I'm assuming that a new file has $geometry = "+0+0". Is there another variable/event that can better tell me if the patch I'm about to display is a "new file"?
It's also interesting that $geometry returns "+0+0" if a patch has negative coords values, like "#N canvas -10 -10 384 187 10;"