Re: [PD-dev] small regression regarding window placement

2013-02-01 Thread IOhannes zmölnig

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

2013-02-01 Thread Hans-Christoph Steiner

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

2013-02-01 Thread Miller Puckette
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

2013-02-01 Thread Roman Haefeli
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

2013-02-01 Thread Roman Haefeli
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

2013-02-01 Thread Hans-Christoph Steiner

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

2013-02-01 Thread Miller Puckette
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

2013-02-01 Thread Roman Haefeli
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