[PD-dev] pd 0.43 test4: Canvas Position

[Roman Haefeli]

On Fri, 2011-01-21 at 18:02 -0500, Hans-Christoph Steiner wrote:
> It was changed to work on GNOME/metacity, which is the default on  
> Fedora, Debian, Ubuntu, Mint, etc.  So it is by far and away the most  
> common.  Since it is going to be different with each window manager, I  
> think it makes sense to have the defaults work for the most people.

Didn't it work for everything before? Or am I even wrong in thinking
that up to 0.42 Pd used to write the window geometry into the patch file
and not the canvas geometry? Sorry to repeat myself: Why was it changed
to storing the canvas geometry?

Roman

> On Jan 21, 2011, at 5:56 PM, Roman Haefeli wrote:
> >
> > Ok. But why was it changed in the first place? Why not switching  
> > back to
> > saving the actual window geometry (as opposed to the canvas  
> > geometry)? I
> > mean, didn't that work well for Pd up to version 0.42?
> >
> > Roman
> 
> > On Fri, 2011-01-21 at 17:04 -0500, Hans-Christoph Steiner wrote:
> >> Its a tricky issue because its different which each window manager.
> >> So I think the best way to address it, in the short run at least, is
> >> for people to figure out the settings that work best with their  
> >> window
> >> manager.
> >>  I guess we should make it possible to set this stuff in a
> >> plugin, so any suggestions of how best to do that would be most
> >> appreciated.
> >>
> >> On Jan 13, 2011, at 4:37 PM, Roman Haefeli wrote:
> >>
> >>> Hi
> >>>
> >>> It seems that since Pd 0.43 a Pd file does not save the window  
> >>> manager
> >>> window position and size anymore (at least on linux), but instead  
> >>> the
> >>> position and the size of the canvas, i.e. the white patching area.
> >>>
> >>> This has some implications. Since window decorations (title bar,
> >>> window
> >>> borders) have different sizes/widths across different window  
> >>> managers,
> >>> but even different sizes across certain themes of certain window
> >>> managers, the patch window of a saved patch doesn't always appear at
> >>> the
> >>> position where it was saved. Even more, the next time the patch is
> >>> saved
> >>> and re-loaded, it's shifted again, etc.
> >>>
> >>> I am usually running fluxbox and with my current theme, the offset  
> >>> is
> >>> x: -3px
> >>> y: -9px
> >>>
> >>> With the Ubuntu Lucid default theme (Gnome), the offset is:
> >>> x: -1px
> >>> y: 0px
> >>>
> >>> Can that be addressed somehow, or is it not possible from tcl/tk to
> >>> know
> >>> the properties of the window decorations?
> >>>
> >>> In fluxbox, there is the side effect, that when xPos or yPos is
> >>> negative, the window is drawn to the next window free area of the
> >>> screen
> >>> instead of the stored position.
> >>>
> >>> Another new issue since 0.43 in fluxbox is, that a second instance
> >>> of Pd
> >>> is always opened on the workspace where the first instance is  
> >>> running.
> >>> This wasn't the case with older versions of Pd (i.e.: it was
> >>> possible to
> >>> start a second instance of Pd in a new workspace.
> >>>
> >>> Is anybody else experiencing similar issues and might have some  
> >>> ideas
> >>> how to resolve this?
> >>>
> >>> Cheers
> >>> Roman
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Pd-dev mailing list
> >>> Pd-dev at iem.at
> >>> http://lists.puredata.info/listinfo/pd-dev
> >>
> >>
> >>
> >> ----------------------------------------------------------------------------
> >>
> >> "Making boring techno music is really easy with modern tools, but  
> >> with
> >> live coding, boring techno is much harder." - Chris McCormick
> >>
> >>
> >>
> >>
> >
> >
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> Looking at things from a more basic level, you can come up with a more  
> direct solution... It may sound small in theory, but it in practice,  
> it can change entire economies.     - Amy Smith
> 
>