Re: [linux-audio-user] QJackCtl window position consistency?

Rui Nuno Capela wrote:

> pirrone wrote:
>
>> pirrone wrote:
>>
>>> Rick Wright wrote:
>>>
>>>>
>>>> pirrone wrote:
>>>>
>>>>> <snip>
>>>>> So, Fedora Core 3 fully updated with CCRMA and all core apps,
>>>>> Fluxbox 0.9.13, QJackCtl 0.2.15 results in the expected behavior.
>>>>>
>>>>> Frank
>>>>>
>>>>>
>>>> Thanks, Frank.
>>>>
>>>> That would be the expected behavior, just not what I'm seeing.....
>>>> I'm using the latest version of QJC: 0.2.19a.
>>>>
>>>> Rick
>>>
>>> I understand that Rick. If I get a chance later I'll try the
>>> version you are using. What we now know is there is either a
>>> difference in behavior from x.15 to x.19a or there is an interaction
>>> between the way the program manages windows and your wm/desktop
>>> resulting in those inconsistencies.
>>>
>>> Frank
>>>
>> OK Rick, did the upgrade and the behavior is the same. Open app,
>> open windows with buttons, toggle windows with buttons, close app
>> with windows open, close app with windows toggled off - all result in
>> the windows being right where they were left.
>>
>
> This is one example I can remember that one window will NOT remember
> its position:
>
> 1. move the window from position P0 to P1.
> 2. close that window with the dreaded [X] WM button.
> 3. quit application.
>
> Thats it, when you later relaunch QJC, the subject window will surely
> reappear on the older P0 position, instead of that last P1 which is
> bluntly forgotten.

Rui, I can confirm that this is the behavior here too when using the WM
X button. However, in all of my previous testing, I only closed the
child windows by using the buttons on the main window. One of the most
suspicious cases is when I move a window, toggle it off, then
immediately toggle it back on and it doesn't come back where I left it.
Here, the WM does seem involved, though as the window seems to come back
in a location that is either one of the cascaded locations (though no
window is present for it to cascade from) or it comes back adjacent to
and top aligned with another child window. Maybe this is a clue?

Also, trying to find some other consistent behavior to report, I can
only confirm one repeatable case: A quit/restart (having left child
windows open) and finding the windows where I left them (which does
sometimes happen, but <50% of the time), that immediately repeating this
quit/restart (doing nothing else) always results in some windows (no
noticed consistency as to which windows) appearing cascaded from the top
left and others where I left them.

The window sizes and open/close status does work persistently here.
Also, when a window does change positions on a subsequent reopen, it
seems that the new position is always at the top left, or in the case
where multiple windows relocate (which always seems to include the main
window), they come up in the cascaded layout, where each top layered
window is shifted down and right about the distance of the top-right
icon dimensions in the title bar of the underneath window.

I wish I could find more consistency to report. I am happy to go
through any procedures you may wish tested and report results.

Frank, what desktop/version are you using for testing this behavior?

Rick
Received on Fri Dec 30 20:15:09 2005