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

Rick Wright riwright at vt.edu
Fri Dec 30 10:19:53 EST 2005


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



More information about the Linux-audio-user mailing list