Prev: Canvas efficiency
Next: bwidget listbox -selectmode multple had a bind missing
From: Uwe Klein on 30 Apr 2010 11:46
Hi everybody.

I have written an absolutely simple minded pager.
that presents selected windows ( incl the same
window with variations in geometry ) from a
set of ~20.

This is done via [wm iconify] / [wm geometry]
The user arranges a view via map/resize/iconify
and then the information for this view is stored.
About a dozend views are supported.

With fvwm2 (the only one i tried) as window manager
I have issues with windows starting to creep around
the screen on iconify and remap. I find it difficult
to reproduce.

It seems to be linked to wm geometry using both: the
values for the embedded window _or_ the values
for the decoration, alternated in a not obvious
fashion.

Any good ideas on how to handle this in a reproducible
way?

G!
uwe
From: Elchonon Edelson on 3 May 2010 12:31
Uwe Klein wrote:
> Hi everybody.
>
> I have written an absolutely simple minded pager.
> that presents selected windows ( incl the same
> window with variations in geometry ) from a
> set of ~20.
>
> This is done via [wm iconify] / [wm geometry]
> The user arranges a view via map/resize/iconify
> and then the information for this view is stored.
> About a dozend views are supported.
>
> With fvwm2 (the only one i tried) as window manager
> I have issues with windows starting to creep around
> the screen on iconify and remap. I find it difficult
> to reproduce.
>
> It seems to be linked to wm geometry using both: the
> values for the embedded window _or_ the values
> for the decoration, alternated in a not obvious
> fashion.
>
> Any good ideas on how to handle this in a reproducible
> way?
>
> G!
> uwe

This is a WM bug, I believe. It's been my experience with some window
managers that [wm geometry . +50+50] will move the decorated window to
the specified location, but [wm geometry .] will report the geometry of
the *undecorated* window. So yes, in any environment where [wm geometry
.. [wm geometry .]] causes the window to move, there's going to be
problems. Unfortunately, I don't know how to work around this issue.
Hmm. Perhaps you could detect it, and apply a correction to all your
window offsets?
From: Uwe Klein on 3 May 2010 13:34
Elchonon Edelson wrote:
> Uwe Klein wrote:
>
>> Hi everybody.
>>
>> I have written an absolutely simple minded pager.
>> that presents selected windows ( incl the same
>> window with variations in geometry ) from a
>> set of ~20.
>>
>> This is done via [wm iconify] / [wm geometry]
>> The user arranges a view via map/resize/iconify
>> and then the information for this view is stored.
>> About a dozend views are supported.
>>
>> With fvwm2 (the only one i tried) as window manager
>> I have issues with windows starting to creep around
>> the screen on iconify and remap. I find it difficult
>> to reproduce.
>>
>> It seems to be linked to wm geometry using both: the
>> values for the embedded window _or_ the values
>> for the decoration, alternated in a not obvious
>> fashion.
>>
>> Any good ideas on how to handle this in a reproducible
>> way?
>>
>> G!
>> uwe
>
>
> This is a WM bug, I believe. It's been my experience with some window
> managers that [wm geometry . +50+50] will move the decorated window to
> the specified location, but [wm geometry .] will report the geometry of
> the *undecorated* window. So yes, in any environment where [wm geometry
> . [wm geometry .]] causes the window to move, there's going to be
> problems. Unfortunately, I don't know how to work around this issue.
> Hmm. Perhaps you could detect it, and apply a correction to all your
> window offsets?

The issue as such is an old aquaintance.
forex xv exhibits jump down/right with each new image.
( using fvwm2 but not in kde_wm )

uwe
From: Elchonon Edelson on 3 May 2010 14:23
Uwe Klein wrote:
> Elchonon Edelson wrote:
>> Uwe Klein wrote:
>>
[snip]
>>>
>>> With fvwm2 (the only one i tried) as window manager
>>> I have issues with windows starting to creep around
>>> the screen on iconify and remap. I find it difficult
>>> to reproduce.
>>>
>>> It seems to be linked to wm geometry using both: the
>>> values for the embedded window _or_ the values
>>> for the decoration, alternated in a not obvious
>>> fashion.
[snip]
>>> G!
>>> uwe
>>
>>
>> This is a WM bug, I believe. It's been my experience with some window
>> managers that [wm geometry . +50+50] will move the decorated window to
>> the specified location, but [wm geometry .] will report the geometry
>> of the *undecorated* window. So yes, in any environment where [wm
>> geometry . [wm geometry .]] causes the window to move, there's going
>> to be problems. Unfortunately, I don't know how to work around this
>> issue. Hmm. Perhaps you could detect it, and apply a correction to all
>> your window offsets?
>
> The issue as such is an old aquaintance.
> forex xv exhibits jump down/right with each new image.
> ( using fvwm2 but not in kde_wm )
>
> uwe

As I said, I believe it's a WM bug. xv's window is jumping because when
it loads a new image, it places itself at it's current location.

Does attempting to detect the window movement and compensate for it work
for you?
From: Uwe Klein on 3 May 2010 14:39
Elchonon Edelson wrote:
> As I said, I believe it's a WM bug. xv's window is jumping because when
> it loads a new image, it places itself at it's current location.
>
> Does attempting to detect the window movement and compensate for it work
> for you?

I have still to find some regularness for "to jump or not to jump".

It seems related to the windows getting touched by user interaction or not.
[ wm positionfrom window .. ] doesn't seem to provide corelating information
either. ( and it is more pronounced when I have turned my back. )
i.e. I have problems reproducing what my user manages to effect.

uwe


 |  Next  |  Last
Pages: 1 2
Prev: Canvas efficiency
Next: bwidget listbox -selectmode multple had a bind missing