[Lazarus] Form ordering problem on tiling window manager

Sven Barth pascaldragon at googlemail.com
Fri Feb 1 21:32:24 CET 2013


On 01.02.2013 07:19, zeljko wrote:
> On Thursday 31 of January 2013 22:44:33 Mattias Gaertner wrote:
>> On Thu, 31 Jan 2013 22:15:26 +0100
>>
>> Sven Barth <pascaldragon at googlemail.com> wrote:
>>> On 31.01.2013 09:39, Mattias Gaertner wrote:
>>>> On Wed, 30 Jan 2013 21:24:38 +0100
>>>>
>>>> Sven Barth <pascaldragon at googlemail.com> wrote:
>>>>> [...]
>>>>> But rather often something happens (I don't know what exactly and I'd
>>>>> like to find this out) and then I can click on the window and I use
>>>>> the switching window keyboard shortcut all I want and nothing
>>>>> happens. This even goes so far that modal dialogs (exception windows,
>>>>> open/save dialog) are opened behind(!) all other windows. So I first
>>>>> need to move the IDE and other windows out of the way before I can
>>>>> work in that dialog. I need to restart the IDE to revert to the
>>>>> original behavior again (for a while...).
>>>>> For now I've only achieved this problem with the IDE, not with a
>>>>> custom program. It would be nice if someone had an idea what I could
>>>>> test to narrow this problem down (the console output does not print
>>>>> anything useful).
>>>>
>>>> If you have trouble with ShowModal, then it is a bug in the LCL gtk2
>>>> interface or below.
>>>> ShowModal had in the past some problems with other window managers
>>>> too.
>>>> Please update to 40085, compile with -dVerboseTransient, then run
>>>> again. When it happens again look at the end of the output for 'DEFINE
>>>> transient'.
>>>
>>> I've done as you proposed (it's an IDE with virgin settings and without
>>> docking, just in case) and I've attached two debug outputs. In both
>>> cases I have started the IDE and opened the File Open dialog with
>>> Ctrl+O. In the "normal" case I've closed the dialog using "ESC" in the
>>> "problem" case I've first used "Win+k" to switch to a different window
>>> of the IDE (which wasn't moved to front of course, but the windows
>>> manager nevertheless marked the windows as focused) and then I've closed
>>> the dialog. After this forceful switch the behavior described in my
>>> original mail appeared (reproduceable).
>>>
>> >From the output: The LCL gtk2 interfaces sets the right order.
>>
>> TOpenDialog on top of OI on top of MainIDE on Form1 on SrcNB on
>> MsgView.
>> So, the question is what does this WM need more than
>> gtk_window_set_transient_for.
>> http://developer.gimp.org/api/2.0/gtk/GtkWindow.html#gtk-window-set-transie
>> nt-for
>
> Maybe an trial with same behaviour as for 'kwin' wm.
> TGtk2WidgetSet.Create
> ...
>    if (GetWindowManager = 'kwin') or (GetWindowManager='YOURWM') then ...
>
> With that part I've fixed transient windows behaviour under kwin (KDE).
>
> Real name you can find with DebugLn(GetWindowManager).

With that extension (Note: I used a variable instead of calling 
GetWindowsManager twice) the behavior is now like this:
* when a modal dialog is open and you click(!) on a non-modal window 
than this window is brought to the front, but you can not interact with 
it (this does not happen if you just move the mouse onto that window to 
focus it)
* after the dialog is closed (and a another window was brought to the 
front while the dialog was open) I can still bring windows to the front 
by focusing them (and if I open a modal dialog again it's shown at the 
top of the other windows)

So while it's unnice that windows can be brought to the front while a 
modal dialog is open it at least solves the problem that I can't bring 
any windows to the front anymore...

I'll now also try Qt and report back...

Regards,
Sven





More information about the Lazarus mailing list