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

Rick Wright wrote:
>
> pirrone wrote:
>
>> Rick Wright wrote:
>>
>>> Lee Revell wrote:
>>>
>>>> On Thu, 2005-12-29 at 16:00 -0500, Rick Wright wrote:
>>>>
>>>>
>>>>> Lee Revell wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Thu, 2005-12-29 at 14:46 -0500, Rick Wright wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Rui Nuno Capela wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Rick Wright wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> I'd like the qjackctl windows (i.e. the control window,
>>>>>>>>> messages, connections, status) to open for a subsequent
>>>>>>>>> executation in the same screen locations as I had them at
>>>>>>>>> shutdown from the last execution. Is this possible? I can't
>>>>>>>>> seem to find an option for this.
>>>>>>>>>
>>>>>>>>> All (and only those) windows that were visible from the
>>>>>>>>> previous execution do indeed appear on the subsequent
>>>>>>>>> application run (which is good), but the window positioning
>>>>>>>>> appears to be forgotten.
>>>>>>>>>
>>>>>>>>> Rui, if this is not currently supported, would it be possible
>>>>>>>>> to add this feature?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Window positioning persistence is already featured and is
>>>>>>>> default behavior, for quite some time. AFAICS its been ever
>>>>>>>> since ;). Problem is that behavior may vary, with some glitches
>>>>>>>> depending on your particular WM. It is well known, at least to
>>>>>>>> me, that window positions aren't remembered very well if you
>>>>>>>> stick to use the WM close button on those window titles, usually
>>>>>>>> the ones labeled as [X]. OTOH if you use qjackctl main window
>>>>>>>> control buttons, to toggle child window visibility and to quit
>>>>>>>> application, all seems to work just fine ;) or so I believe and
>>>>>>>> been told.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I am finding inconsistency in the window positioning
>>>>>>> persistence. Sometimes the windows appear in the same position,
>>>>>>> sometimes they don't. This has been tested using only the QJC
>>>>>>> main window control buttons as recommended above.
>>>>>>>
>>>>>>> Leaving the windows open (only testing using 4 of them: main,
>>>>>>> status, messages, connections) upon shutdown (quit on main
>>>>>>> window) and restarting QJC sometimes gives the same locations and
>>>>>>> sometimes not, but it seems that the windows don't like the
>>>>>>> presence of other windows (i.e. an xterm from which to start
>>>>>>> QJC!) and the most prevalent offender is the main window.
>>>>>>> Actually, it seems that upon the first restart of QJC, the
>>>>>>> positions are remembered, but without moving any windows, a
>>>>>>> second quit/restart results in some windows appearing cascaded
>>>>>>> from the top left of the desktop. Window sizes are always
>>>>>>> remembered.
>>>>>>>
>>>>>>> Can anyone else reproduce this?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> What desktop environment and window manager are you using and which
>>>>>> version?
>>>>>>
>>>>>> Lee
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Reply try #3.....
>>>>>
>>>>> Running an up-to-date FC4/GNOME (2.6.10) system.
>>>>>
>>>>> Rick
>>>>>
>>>>>
>>>>
>>>>
>>>> OK, I just reproduced this on my Ubuntu Breezy system, Gnome
>>>> 2.12.0. If
>>>> I run qjackctl, open the Messages window, move it, open the Connect
>>>> window, move that, then close the main window by clicking the X, next
>>>> time I run it the Messages window has moved back to where it started.
>>>>
>>>> Surely this is a WM bug, the app can't be responsible for remembering
>>>> the position of its windows?
>>>>
>>>> Lee
>>>>
>>>>
>>>>
>>>>
>>> Rui seemed to indicate that if you close those windows by toggling
>>> the associated button on the main window (rather than the X as you
>>> did) that the positions should persist. For me, they all do *except*
>>> the messages window. That doesn't seem like a WM bug to me.
>>>
>>> Try this: open the app, open the message and status windows and move
>>> them somewhere. Then, simply toggle the buttons and see where they
>>> reappear.
>>>
>>> I just tried this again with the patchbay window (my first test with
>>> patchbay) and it shows the same non-persistence behavior as the
>>> messages window.
>>>
>>> As far as closing the app with the quit button and then restarting,
>>> the results are mixed as I described above. It seems that the window
>>> positions persist (mostly) upon the first restart, but without moving
>>> any windows, a subsequent quit/restart seems to lose window position
>>> information. This seems app related too, no?
>>>
>>> Rick
>>>
>>>
>> Rick et al.,
>>
>> Been off doing some Web work but glad to see this thread working its
>> way along. Here's my latest results with your latest scenario:
>>
>> Open QJC, open Messages and Status, observe they open right where I
>> set them when I first tested and replied to your posting, move them
>> around, toggle those two windows with their respective buttons and
>> they persist right where I just moved/left them. Rinse, repeat...
>> works as expected.
>>
>> Same with Patchbay.
>>
>> Then, I closed down QJC with those windows still opened and
>> re-launched it to find the windows in the same place they were when I
>> closed it.
>>
>> Then, I closed down QJC with those windows toggled closed and
>> re-launched it to find that when I toggled the windows back open they
>> were in the same place I left them when I toggled them off before
>> closing QJC.
>>
>> 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

Just as a side note: QjackCtl's window positioning code path hasn't
changed since its dawn... but, as said before, WM differences might be
getting in between. KDE's seems pretty predictable to me ;) YMMV. OK,
just as an example hint: when you close a window with the provided WM's
X button, the GUI user program code usually gets notified only _after_
the proper window close, so asking for window extents as for later
remembrance is straight WrongProcedure(tm).

Anyhow, I'll appreciate any thoughts and others practical knowledge
about this whole issue. It might just happen that I'm doing it plain
wrong, rightly wrong from the start :)

Any help on this would be highly appreciated, as always.
Cheers.

-- 
rncbc aka Rui Nuno Capela
rncbc@email-addr-hidden