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

On Fri, 2005-12-30 at 10:19 -0500, Rick Wright wrote:
> 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,

    It might be interesting to see whether your locations are saved
using KDE instead of GNOME. They are persistent for me on FC4 using
KDE.

-- 
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be 
glad of an opportunity to serve others by any invention of ours, and 
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of 
Pennsylvania for his "Pennsylvania Fireplace", c. 1744