Re: [PD-dev] pd 0.43 test4: Canvas Position
On 01/22/2011 12:02 AM, 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. iirc, gnome is only widespread in the US, whereas europe (and esp. german speaking communities) used to favour KDE. this if course it under constant flux, but i wanted to point out that by far and away the most common is a very subjective and usually point of view which i strive to avoid. fgmadrs IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd 0.43 test4: Canvas Position
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@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd 0.43 test4: Canvas Position
(I hope you don't mind if I bring that back to the list) On Sat, 2011-01-22 at 15:50 -0500, Hans-Christoph Steiner wrote: - Original message - On Sat, 2011-01-22 at 15:31 -0500, Hans-Christoph Steiner wrote: - Original message - 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 from my experience, it was not working, that's why I changed it. I didn't realize at the time that it was different on each window manager in X11, I only use GNOME/metacity. Not that I care _that_ much about it, but I still wonder: In what way is it working better now than it was before? I wouldn't call it 'working' when it actually only works with one window manager (metacity). OTOH, I must say that it is quite easy to make it working in non-metacity window managers. Only two numbers need to be adjusted in pd-src/tcl/pdtk_canvas.tcl. Is there a way for tcl/tk to know in which window manager it is running in? If so, a real solution wouldn't be too hard, hopefully. Roman there has got to be a way, at worst you could always ps auxww | grep metacity for each supported WM. I only use the default Debian and Ubuntu setup, so I not the one to take this project on. True. However, I think it's not even tied to the window manager, but to the theme it uses. At least I tested it also on Gnome/Metacity (default theme on Lucid) and it was still off (which might be an indication that your Gnome is different from mine). Also I believe it is dangerous to assume that the default theme uses the same measures on different Ubuntu versions or the measures are the same across different distros (most likely they are _not_). I don't see how it could be solved in a consistent way. I consider the current implementation rather 'broken' than 'working'. This is not a rant, but I think we should be aware of where things might fail. Personally, I am very fine with adjusting two numbers in a file whenever I install Pd. Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd 0.43 test4: Canvas Position
On Jan 22, 2011, at 4:05 PM, Roman Haefeli wrote: (I hope you don't mind if I bring that back to the list) On Sat, 2011-01-22 at 15:50 -0500, Hans-Christoph Steiner wrote: - Original message - On Sat, 2011-01-22 at 15:31 -0500, Hans-Christoph Steiner wrote: - Original message - 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 from my experience, it was not working, that's why I changed it. I didn't realize at the time that it was different on each window manager in X11, I only use GNOME/metacity. Not that I care _that_ much about it, but I still wonder: In what way is it working better now than it was before? I wouldn't call it 'working' when it actually only works with one window manager (metacity). OTOH, I must say that it is quite easy to make it working in non-metacity window managers. Only two numbers need to be adjusted in pd-src/tcl/pdtk_canvas.tcl. Is there a way for tcl/tk to know in which window manager it is running in? If so, a real solution wouldn't be too hard, hopefully. Roman there has got to be a way, at worst you could always ps auxww | grep metacity for each supported WM. I only use the default Debian and Ubuntu setup, so I not the one to take this project on. True. However, I think it's not even tied to the window manager, but to the theme it uses. At least I tested it also on Gnome/Metacity (default theme on Lucid) and it was still off (which might be an indication that your Gnome is different from mine). Also I believe it is dangerous to assume that the default theme uses the same measures on different Ubuntu versions or the measures are the same across different distros (most likely they are _not_). I don't see how it could be solved in a consistent way. I consider the current implementation rather 'broken' than 'working'. This is not a rant, but I think we should be aware of where things might fail. Personally, I am very fine with adjusting two numbers in a file whenever I install Pd. Roman I can just add that I don't think its a good situation, but it was the best I could do at the time. If you check the comments at the top of pdtk_canvas.tcl, you can see a couple notes: #TODO: http://wiki.tcl.tk/11502 # MS Windows #wm geometry . returns contentswidthxcontentsheight+decorationTop +decorationLeftEdge. #and #winfo rooty . returns contentsTop #winfo rootx . returns contentsLeftEdge It would be great if someone who uses X11 with different window managers could take this on so that it does work on all platforms. .hc Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd 0.43 test4: Canvas Position
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. .hc 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@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd 0.43 test4: Canvas Position
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. 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 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@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
