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


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