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

On 10/02/2012 05:04 AM, Julian Brooks wrote:

Hi Nicola,

Probably not much help but I was having exactly this issue on a Raspbian RPI I was testing with a couple of weeks ago, I'd forgotten until your post reminded me. Not had time to return to the problem atm but would be well up for a solution.

Here's hoping.

Julian

BTW First email came through fine. Gmail doesn't show your sent copy - you have to sit tight and wait for a reply.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

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

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@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

On 04/10/12 04:07, Hans-Christoph Steiner wrote:

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.

wouldn't that make it difficult to put the window outside the screen deliberately ... for example to hide the window decorations off-screen?

I have needed to use this a few times (when making the window properly fullscreen was not possible or appropriate), and it is sometimes a lot easier than trying to work out how to tell a particular window manager not to put decorations on a particular window.

Simon

On 04/10/12 15:54, Claude Heiland-Allen wrote:

On 04/10/12 01:08, Simon Wise wrote:

...

wouldn't that make it difficult to put the window outside the screen deliberately ... for example to hide the window decorations off-screen?

I have needed to use this a few times (when making the window properly fullscreen was not possible or appropriate), and it is sometimes a lot easier than trying to work out how to tell a particular window manager not to put decorations on a particular window.

'devilspie' is what I use for generic window-manager-override tweaking, though I tested it myself with only xfce4 desktop.

yes, I've generally worked it out locally on any linux machine I set up - and devilspie and xfce4 have been useful - but when working on a machine that is not mine to tweak so much, or on OSX in the past, it becomes much simpler to just set the window geometry so that the decorations are hidden off-screen.

Simon

On 10/04/2012 08:11 AM, Nicola Pandini wrote:

Il 04/10/2012 02:08, Simon Wise ha scritto:

...

On 04/10/12 04:07, Hans-Christoph Steiner wrote:

...

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.

wouldn't that make it difficult to put the window outside the screen deliberately ... for example to hide the window decorations off-screen?

I have needed to use this a few times (when making the window properly fullscreen was not possible or appropriate), and it is sometimes a lot easier than trying to work out how to tell a particular window manager not to put decorations on a particular window.

Simon

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Hi Simon, 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] }

You'll keep the standard behaviour of Pd for all the saved patches, only the new ones are forced to be placed to coords 0,0.

Before this kind of change is included in Pd-extended or Pd, it'll need to be tested a lot on all platforms. That's why I never really tackled the issue of all the different WMs. I think a workable approach would be to isolate the bits that need to be changed for the different VMs and stick that into its own Tcl proc (function) while keeping the current logic.

Then it'll be easy to customize this logic without having to come up with the One True Way that will require lots and lots of testing and tweaking. If the above is really all that needs to change, then that can be put into its own proc.

.hc

On 10/09/2012 05:56 AM, Nicola Pandini wrote:

Il 06/10/2012 00:00, Hans-Christoph Steiner ha scritto:

...

On 10/04/2012 08:11 AM, Nicola Pandini wrote:

...

Il 04/10/2012 02:08, Simon Wise ha scritto:

...

On 04/10/12 04:07, Hans-Christoph Steiner wrote:

...

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.

wouldn't that make it difficult to put the window outside the screen deliberately ... for example to hide the window decorations off-screen?

I have needed to use this a few times (when making the window properly fullscreen was not possible or appropriate), and it is sometimes a lot easier than trying to work out how to tell a particular window manager not to put decorations on a particular window.

Simon

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Hi Simon, 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] }

You'll keep the standard behaviour of Pd for all the saved patches, only the new ones are forced to be placed to coords 0,0.

Before this kind of change is included in Pd-extended or Pd, it'll need to be tested a lot on all platforms. That's why I never really tackled the issue of all the different WMs.

You are right, I only wrote to Simon that he won't loose the possibility to place a pd's window outside the screen.

...

I think a workable approach would be to isolate the bits that need to be changed for the different VMs and stick that into its own Tcl proc (function) while keeping the current logic.

Then it'll be easy to customize this logic without having to come up with the One True Way that will require lots and lots of testing and tweaking. If the above is really all that needs to change, then that can be put into its own proc.

Ok, I'll make further tests to confirm the correct behaviour in OpenBox.

Ok, I split out this logic into its own proc, so now it should be easy to override with something like:

rename pdtk_canvas_place_window pdtk_canvas_place_window_original proc pdtk_canvas_place_window {width height geometry} { # do your tricks here return [list $width $height ${width}x$height+$x+$y] }

I also submitted it to Miller for inclusion in Vanilla.

https://sourceforge.net/tracker/?func=detail&aid=3579630&group_id=55...

.hc