Re: [PD] Pd-extended 0.43 and Openbox
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=detailaid=3579630group_id=55736atid=478072
.hc
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
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.
Thanks
--
Nicola
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
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. http://burtonini.com/blog/computers/devilspie https://live.gnome.org/DevilsPie http://www.foosel.org/linux/devilspie Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
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? Thanks -- Nicola ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
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
Re: [PD] Pd-extended 0.43 and Openbox
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. -- Nicola ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
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.
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?
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;
--
Nicola
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.43 and Openbox
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
Re: [PD] Pd-extended 0.43 and Openbox
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
Re: [PD] Pd-extended 0.43 and Openbox
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
