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 > >>> [email protected] > >>> 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 > > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
