[PD-dev] pd 0.43 test4: Canvas Position

[Hans-Christoph Steiner]

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.

.hc

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