Hi Miller
The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change:
-#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50
which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top ("0 44" from the pd file gets overwritten by "0 50").
I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it?
Roman
Drat..
On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window.
but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a "new" canvas, not when you restored a saved one. Something else must be going wrong.
M
On Fri, Feb 01, 2013 at 08:00:47PM +0100, Roman Haefeli wrote:
Hi Miller
The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change:
-#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50
which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top ("0 44" from the pd file gets overwritten by "0 50").
I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it?
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
This is sorted out in Pd-extended, if you want to compare. I'm not sure what the exact changes are. I think there is platform-specific logic to bump the window down if its in the menu bar.
.hc
On 02/01/2013 02:05 PM, Miller Puckette wrote:
Drat..
On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window.
but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a "new" canvas, not when you restored a saved one. Something else must be going wrong.
M
On Fri, Feb 01, 2013 at 08:00:47PM +0100, Roman Haefeli wrote:
Hi Miller
The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change:
-#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50
which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top ("0 44" from the pd file gets overwritten by "0 50").
I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it?
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Fre, 2013-02-01 at 14:46 -0500, Hans-Christoph Steiner wrote:
This is sorted out in Pd-extended, if you want to compare. I'm not sure what the exact changes are. I think there is platform-specific logic to bump the window down if its in the menu bar.
In Pd-extended it is still set to '0' for non-Mac systems.
Roman
On 02/01/2013 02:05 PM, Miller Puckette wrote:
Drat..
On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window.
but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a "new" canvas, not when you restored a saved one. Something else must be going wrong.
M
On Fri, Feb 01, 2013 at 08:00:47PM +0100, Roman Haefeli wrote:
Hi Miller
The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change:
-#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50
which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top ("0 44" from the pd file gets overwritten by "0 50").
I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it?
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Fre, 2013-02-01 at 11:05 -0800, Miller Puckette wrote:
On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window.
I should have given more context:
#ifdef __APPLE__ #define GLIST_DEFCANVASYLOC 22 #else -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 #endif
So it seems that particular change does not affect Mac OS X. Thus I assume that reverting it wouldn't change the behavior on Macs either.
but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a "new" canvas, not when you restored a saved one. Something else must be going wrong.
Sorry for not being of any help here.
Roman
Found it... firther down in g_canvas.c:
if (yloc < GLIST_DEFCANVASYLOC) yloc = GLIST_DEFCANVASYLOC; if (xloc < 0) xloc = 0;
I'm not sure what the correct foolproofing should be (or indeed if it's a good idea to have foolproofing there at all). But anyhow removing those lines will make it possible for patches to restore themselves wherever they were saved from.
cheers Miller
On Fri, Feb 01, 2013 at 09:10:23PM +0100, Roman Haefeli wrote:
On Fre, 2013-02-01 at 11:05 -0800, Miller Puckette wrote:
On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window.
I should have given more context:
#ifdef __APPLE__ #define GLIST_DEFCANVASYLOC 22 #else -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 #endif
So it seems that particular change does not affect Mac OS X. Thus I assume that reverting it wouldn't change the behavior on Macs either.
but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a "new" canvas, not when you restored a saved one. Something else must be going wrong.
Sorry for not being of any help here.
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I say remove that bit entirely and let the GUI handle figuring out where the window should go. Pd should just relay the unadulterated values from the Pd patch. Only the GUI can figure this out, especially considering all of the variations of window managers and platforms. These days Tk will handle a lot of this stuff for you.
.hc
On 02/01/2013 03:50 PM, Miller Puckette wrote:
Found it... firther down in g_canvas.c:
if (yloc < GLIST_DEFCANVASYLOC) yloc = GLIST_DEFCANVASYLOC; if (xloc < 0) xloc = 0;I'm not sure what the correct foolproofing should be (or indeed if it's a good idea to have foolproofing there at all). But anyhow removing those lines will make it possible for patches to restore themselves wherever they were saved from.
cheers Miller
On Fri, Feb 01, 2013 at 09:10:23PM +0100, Roman Haefeli wrote:
On Fre, 2013-02-01 at 11:05 -0800, Miller Puckette wrote:
On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window.
I should have given more context:
#ifdef __APPLE__ #define GLIST_DEFCANVASYLOC 22 #else -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 #endif
So it seems that particular change does not affect Mac OS X. Thus I assume that reverting it wouldn't change the behavior on Macs either.
but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a "new" canvas, not when you restored a saved one. Something else must be going wrong.
Sorry for not being of any help here.
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Hans-Christoph Steiner -
IOhannes zmölnig -
Miller Puckette -
Roman Haefeli