Re: [PD-dev] small regression regarding window placement
On 02/01/2013 10:10 PM, Hans-Christoph Steiner wrote: I say remove that bit entirely and let the GUI handle figuring out where the window should go. yes! fgadm IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
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 > ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
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
Re: [PD-dev] small regression regarding window placement
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
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
Re: [PD-dev] small regression regarding window placement
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 > ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
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] small regression regarding window placement
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