I am occasionally using Lazarus on my Linux box with KDE running on it and normally I have set the windowmanager to change focus when I only move the mouse without needing to click.

When I edit code in Lazarus and the autocomplete list pops up and the mouse cursor is not by chance exactly at the place where the list pops up it will immediately lose focus and I cannot scroll in the list anymore. I also cannot type anymore until I move my mouse over the list to give it the focus again.

I there any window style that can be given to this list or any other simple fix that will prevent this behavior? (I have not checked the latest snapshots for some weeks now, so maybe it might already be fixed)

lazarus revision ?
widgetset ?
widgetset library version ? eg. gtk2-2.18.XX, qt-4.6.3 etc ..

zeljko

I don't think there is a simple fix for it. Actually in the latest revision it the auto complete will probably even close itself in this case. It behaves like a menu would do => loose focus => close

How does any other window work for you, if the window manager keeps steeling the focus?

Let's say you open the option dialog, from the menu => then the mouse is where the menu was => so it is not over the just opened option dialog. Do you need to move the mouse over the option dialog, so you can use the option dialog?

what about: find, replace, goto-line dialogs? They all can be opened via keyboard, and they all want to be focused onced opened. (even if they are not under the mouse).

Martin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin wrote

I don't think there is a simple fix for it. Actually in the latest revision it the auto complete will probably even close itself in this case. It behaves like a menu would do => loose focus => close

I will try the latest snapshot later when I find some time. Currently I have 0.9.29-0-20100326.

How does any other window work for you, if the window manager keeps steeling the focus?

Of course I have to move the mouse over the other windows to use them too, but this is not a problem, this is how it is supposed to be with every other Application too, also I would not call this "stealing" the focus, it is the way focus is switched between top level windows.

This is a quite common way how many users who are used to *ix-based Dektops have done focus switching for decades and have configured their desktops accordingly, so I wonder why nobody has found this behavior of Lazarus annoying yet. I have a few other applications with similar popup lists that I often use, also based on GTK while running under KDE that will not get confused by this. For example PyCrust, a Python shell/ide that is also using GTK2 has an autocomplete list but somehow this list is not a top level window it acts as a control of the editor window. It will not lose focus or need focus removed from the editor window. As long as the editor as a whole has focus it just works like any other control also (menus for example).

If I open the Options dialog or other dialogs I must of course move my moue anywhere inside this window before I can use it, this is absolutely OK and suppoed to be this way but inside this window the mouse position alone does of course not influence the focus of the individual controls in any way, except I intentionally click on one of them.

The problem is the autocomplete list popping up as a completely separate top level window with its own top level focus and not as a control of the editor window. This will *interrupt* my typing and I have to move the hand away from the keyboard to the mouse and carefully position the mouse. If I enter the list and move the mouse too far and leave the list again, giving focus back to the editor the list will close.

This is not like for example menus work, a menu does not have its own top level focus, it is a control of the containing window like all the other controls and does not require focus being taken away from its parent to be used.

Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFMO0EvxT6R4jlFoh0RAgY2AJ9Aqb9Ghp9vfHJZGGKC8sUl51kchwCeLQWQ lPjOTlf1mx97IK4zIPFwh24=
=5VRi
-----END PGP SIGNATURE-----

....

There currently is no solution to it, so updating will not solve it either.

I am not sure how easy this can be

2010/7/12 Martin :

There currently is no solution to it, so updating will not solve it either. I am not sure how easy this can be , I invested some time now to see what I can do and I think the

symptoms can be solved by tweaking my settings of the window manager a bit:

I don't know why I did not immediately see (and try) this but at least with kwin (which is the KDE window manager) there are a few different modes for the focus switching behavior, one is the focus will *always* be swiched to whatever window currently *is* below the cursor and the other one is it will switch focus only on the *event* of moving the mouse and *entering* a different window.

I had for some reason I cannot remember the first option enabled which under almost all circumstances for all my other use cases behaves effectively almost the same but does not work with Lazarus. Switching it to the other mode has solved this problem for me.

This means whoever has started wasting brain-power on this problem: Stop thinking about it, it is not really a problem anymore, it could be solved by my desktop settings. Maybe it is the elevated temperature of 40?C here that kept me from trying hard enough to solve my problem before I posted to the list, I hereby want to apologize for any inconvenience.

Bernd

The 2nd one, is what I would have expected.

The first one will conflict with any app, that moves the focus itself, or any attempt to move focus by keyboard. Since focus would always return immediately to where the mouse is.

It would make kind of sense, if focus would return to the window under the mouse, if and only if the mouse moves (even if it doesn't leave/re-enter the window).

BTW, out of interest: does (in the 1st mode) the focus also lock down to the window under mouse, if the mouse cursor is hidden/invisible? Lazarus has an option, to hide the mouse if you type.

Martin

2010/7/12 Martin :

The first one will conflict with any app, that moves the focus itself, or any attempt to move focus by keyboard. Since focus would always return immediately to where the mouse is.

Yes, this is true. but for some reason I did never use any programs that move the focus to another window *and* would then be unusable with this mode. Somehow everything worked for me and I did not consciously notice the few occasions where I had to manually move the mouse to a dialog window. The only app that really did not work in this mode and caused major annoyance was Lazarus and I simply was not aware that i could chose between these two different modes.

BTW, out of interest: does (in the 1st mode) the focus also lock down to the window under mouse, if the mouse cursor is hidden/invisible? Lazarus has an option, to hide the mouse if you type.

Just tried it and it makes no difference. The mouse is invisible but it is still there and causes the focus switch.

I also experience this using KDE and GTK build. It seems that the auto-complete opens a new window that does not accept the focus, but keeps it on the editor window.

When I use a single window button on the task bar, I do not remember it happening at all (I hope I'll have some time over the weekend to test it).

It's been there for a month or so, but I do not have the time at this moment to look at the code and offer a patch for it.

Ido

http://ik.homelinux.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100713/f35f648d/attachment.html>

2010/7/13 ik :

I also experience this using KDE and GTK build.? It seems that the auto-complete opens a new window that does not accept the focus, but keeps it on the editor window.

http://docs.kde.org/development/en/kdebase-workspace/kcontrol/windowbehaviour/index.html

in the window behavior settings try changing it from "focus under mouse" to "focus follows mouse". This is what solved it for me.