Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-05

usability: please not focus the messages window, only bring to front

33 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Bernd

Has it always behaved this way? Currently if I invoke Identifier completion with Ctrl+Space and the code tools encounter an error because of a typo they fail to parse the code (often in immediate reach of where I am currently typing, so I could easily reach it with cursor keys) it will highlight the error and then focus the messages window. Then I am always forced to use the mouse and click to focus again.

I am not sure if this has always been so (and haven't tested older versions yet), It just seems to me that it only recently started to annoy me big time. Consider this:

procedure TTor.KillIfAlreadyRunning;
var
OldPid: THandle:
PidFile: TFileSt <-- cursor is here, pressing Ctrl+Space, want it to autocomplete TFileStream

I have accidentally put : instead of ; after the THandle and now when invoking Ctrl+Space in the last line it will complain, move the cursor to the error right after THandle (which is perfectly ok because I need to fix it exactly here) but then it will focus the message window and I am interrupted in my typing, I have to take the hands off the keyboard, find the mouse and give focus back to the source editor window again (and if I hadn't focus follows mouse I would even have to click exactly the correct location in order to not move the cursor away from its already ideal position).

It would be nice if it would instead behave like this:
* print the error to the message window
* move the cursor in the source to the error
* (optional) bring the messages to the front (its often overlapped on small screens) but do NOT change active focus in any way. Pulling away the focus from under my fingers is not nice behavior.

Compiling:

Also the option (and functionality) to focus messages on compile should be changed to only bring the message window to the front but never change the focus. Is there actually any suitable use case where one would really want the focus in the message window at all?

I often invoke the compiler with the keyboard shortcut only to see if it still compiles (or if it compiles again after some heavy refactoring) without wanting to leave the source editor, I only want to see the message window, not interact with it. Currently the behavior is quite strange:

"focus messages after compilation" unchecked:
* compiling without errors leaves the focus alone
* compiling with error focuses the message window (wrong! now I have to use the mouse)

"focus messages after compilation" checked:
* compiling without errors focuses the messages
* compiling with error focuses the source. (exactly the opposite of what it says)

I would like to have an option where it will simply always focus the source, no matter what happens and maybe optionally bring the messages to front if it is overlapped by other windows. I don't see any use in messages ever having the focus, it does not provide any meaningful keyboard interaction anyways.

Bernd

Reply by email

Mattias Gaertner
to Bernd
Show quoted text 7 lines
Has it always behaved this way? Currently if I invoke Identifier completion with Ctrl+Space and the code tools encounter an error because of a typo they fail to parse the code (often in immediate reach of where I am currently typing, so I could easily reach it with cursor keys) it will highlight the error and then focus the messages window. Then I am always forced to use the mouse and click to focus again.

Focus should be in source editor.
It works here.

Can you find the revision that breaks it?

Mattias

Reply by email

Bernd
to Mattias Gaertner

2012/5/21 Mattias Gaertner :

Focus should be in source editor. It works here.

Maybe it depends on the window manager. I have recently switched to Xubuntu. I am observing this since months and I'm not really sure if it changed because Lazarus changed or because it does not work because of xfwm4.

Are there any explicit focus switches in the code or does it simply rely on the fact that the window manager might do the "right" thing on its own? Can you point me to the places in the code where this would have to happen, so I can do some experiments and maybe explicitly force the focus back to the source editor at the right moment? I am willing to patch it because this has reached a level of annoyance for me that it totally distracts me from solving my actual coding problems.

Bernd

Reply by email

Martin
to Bernd
Bernd wrote 9 lines
2012/5/21 Mattias Gaertner: > Focus should be in source editor. > It works here. Maybe it depends on the window manager. I have recently switched to Xubuntu. I am observing this since months and I'm not really sure if it changed because Lazarus changed or because it does not work because of xfwm4.

Have you checked the options?

There is an option, that if set will focus the message window.

Options / Desctop

Reply by email

Bernd
to Martin

2012/5/21 Martin :

Show quoted text 5 lines
Have you checked the options? There is an option, that if set will focus the message window. Options / Desctop

See my original message. It tried both. It does not do what the option says in both cases (checked or unchecked)

Reply by email

Unknown author
to Bernd
Bernd wrote 9 lines
2012/5/21 Martin : > Have you checked the options? > > There is an option, that if set will focus the message window. > > Options / Desctop See my original message. It tried both. It does not do what the option says in both cases (checked or unchecked)

In my experience, focus handling of the IDE on linux is seriously messed up. It has never worked decently. I spend a lot of time looking for all the various IDE windows :/ (and that's on a Kubuntu, not Xubuntu)

Michael.

Reply by email

zeljko
to Unknown author
Show quoted text 14 lines
On Mon, 21 May 2012, Bernd wrote: > 2012/5/21 Martin : >> Have you checked the options? >> >> There is an option, that if set will focus the message window. >> >> Options / Desctop > > See my original message. It tried both. It does not do what the option > says in both cases (checked or unchecked) In my experience, focus handling of the IDE on linux is seriously messed up. It has never worked decently. I spend a lot of time looking for all the various IDE windows :/ (and that's on a Kubuntu, not Xubuntu)

Kubuntu ? Have you tried focus stealing prevention on/off ?

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120521/3cdebf3d/attachment.html>

Reply by email

Unknown author
to zeljko
zeljko wrote 17 lines
On Monday 21 of May 2012 16:41:34 wrote: > On Mon, 21 May 2012, Bernd wrote: >> 2012/5/21 Martin : >>> Have you checked the options? >>> >>> There is an option, that if set will focus the message window. >>> >>> Options / Desctop >> >> See my original message. It tried both. It does not do what the option >> says in both cases (checked or unchecked) > > In my experience, focus handling of the IDE on linux is seriously messed > up. It has never worked decently. I spend a lot of time looking for all > the various IDE windows :/ (and that's on a Kubuntu, not Xubuntu) Kubuntu ? Have you tried focus stealing prevention on/off ?

Never tried. But now I set it to 'off'.

At first sight, it does not change anything.

I expect that if I activate the main Lazarus window, that all other windows are also activated. This is not so (although I'm not sure it is supposed to happen in Lazarus ?).

In each case, when compiling, the messages window is neither raised nor focused.

Michael.

Reply by email

zeljko
to Unknown author
Show quoted text 26 lines
On Mon, 21 May 2012, zeljko wrote: > On Monday 21 of May 2012 16:41:34 wrote: >> On Mon, 21 May 2012, Bernd wrote: >>> 2012/5/21 Martin : >>>> Have you checked the options? >>>> >>>> There is an option, that if set will focus the message window. >>>> >>>> Options / Desctop >>> >>> See my original message. It tried both. It does not do what the option >>> says in both cases (checked or unchecked) >> >> In my experience, focus handling of the IDE on linux is seriously messed >> up. It has never worked decently. I spend a lot of time looking for all >> the various IDE windows :/ (and that's on a Kubuntu, not Xubuntu) > > Kubuntu ? Have you tried focus stealing prevention on/off ? Never tried. But now I set it to 'off'. At first sight, it does not change anything. I expect that if I activate the main Lazarus window, that all other windows are also activated. This is not so (although I'm not sure it is supposed to happen in Lazarus ?).

Are you joking ? If you activate main lazarus window then only active window is lazarus main window. There's no chance to have 2 active windows of same application at the same time (we'll it is if TCustomForm.Active says that it's active but really it isn't).

In each case, when compiling, the messages window is neither raised nor focused.

Qt and gtk2 raises active window and they will not focus anything explicitly. If LCL says please focus that control, then control will be focused.BUT if you focus message window (eg. by mouse click) and next time when it's raised it's possible that it'll grab focus, but again because of lcl I guess.

zeljko

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

Reply by email

Bernd
to Unknown author: In my experience, focus handling of the IDE on linux is seriously messed up. It has never…

There must be some explicit SetFocus() calls hidden somewhere deep inside the code. I don't know where exactly the code is located that

* writes the compiler error messages and then (sometimes) sets focus
* writes the code tools errors and then (sometimes) sets focus

I would have to figure out how to trace it back with the debugger somehow if I figure out where to set the breakpoint (would a breakpoint in in TMessagesView.FormActivate() give me a useful stack trace?), maybe I have to grep the entire code for SetFocus().

Now out of sheer desperation I have patched my local copy as follows:

in msgview.pp for the event OnActivate:

procedure TMessagesView.FormActivate(Sender: TObject);
begin
  SourceEditorManagerIntf.ActiveSourceWindow.SetFocus;
end;

Now the message window cannot have the focus anymore at all, it will immediately focus back to the source editor whenever something activates it but this unknown "something" in the code that is doing this is the real root of the evil, I need to find it.

Bernd

Reply by email

Unknown author
to zeljko: Are you joking ? If you activate main lazarus window then only active window is lazarus…
zeljko wrote 32 lines
On Monday 21 of May 2012 17:02:49 wrote: > On Mon, 21 May 2012, zeljko wrote: >> On Monday 21 of May 2012 16:41:34 wrote: >>> On Mon, 21 May 2012, Bernd wrote: >>>> 2012/5/21 Martin : >>>>> Have you checked the options? >>>>> >>>>> There is an option, that if set will focus the message window. >>>>> >>>>> Options / Desctop >>>> >>>> See my original message. It tried both. It does not do what the option >>>> says in both cases (checked or unchecked) >>> >>> In my experience, focus handling of the IDE on linux is seriously messed >>> up. It has never worked decently. I spend a lot of time looking for all >>> the various IDE windows :/ (and that's on a Kubuntu, not Xubuntu) >> >> Kubuntu ? Have you tried focus stealing prevention on/off ? > > Never tried. But now I set it to 'off'. > > At first sight, it does not change anything. > > I expect that if I activate the main Lazarus window, that all other windows > are also activated. This is not so (although I'm not sure it is supposed to > happen in Lazarus ?). Are you joking ? If you activate main lazarus window then only active window is lazarus main window. There's no chance to have 2 active windows of same application at the same time (we'll it is if TCustomForm.Active says that it's active but really it isn't).

I should have been more careful in my wording:

I don't want the others to be active (I know only one window can be active), but I do want them to be raised over non-lazarus windows.

I have typically one or more terminals, a browser and a VMWare open besides lazarus.
I can raise the main lazarus window, but then I must still go and look for other IDE windows. By automatically raising these when the main window becomes active, this would reduce my search time :-)

(I already started working with 1 terminal with many tabs, just to reduce the number of open windows on my desktop)

Show quoted text 7 lines
> In each case, when compiling, the messages window is neither raised nor > focused. Qt and gtk2 raises active window and they will not focus anything explicitly. If LCL says please focus that control, then control will be focused.BUT if you focus message window (eg. by mouse click) and next time when it's raised it's possible that it'll grab focus, but again because of lcl I guess.

The original question was about raising/focusing the messages window when compiling. On my PC neither happens, so the value of the abovementioned checkbox in the settings dialog becomes meaningless ?

Michael.

Reply by email

Bernd
to Unknown author

Does anybody know where is the code located that is executing when I compile something and that is writing the messages to the messages window? I only need some starting point so I can try to step throuhg it but the codebase is so uge that I just can't find it.

On compilation when there occurs an error it is definitely trying to focus the message window, exactly at the moment the error occurs. My window manager does definitely NOT focus things on its own, something must call setfocus but I can't find it.

Reply by email

Mattias Gaertner
to Bernd
Show quoted text 9 lines
Does anybody know where is the code located that is executing when I compile something and that is writing the messages to the messages window? I only need some starting point so I can try to step throuhg it but the codebase is so uge that I just can't find it. On compilation when there occurs an error it is definitely trying to focus the message window, exactly at the moment the error occurs. My window manager does definitely NOT focus things on its own, something must call setfocus but I can't find it.

ide/main.pp
function TMainIDE.DoBuildProject

  IDEWindowCreators.ShowForm(MessagesView,EnvironmentOptions.MsgViewFocus);

Mattias

Reply by email

zeljko
to Unknown author: I should have been more careful in my wording: I don't want the others to be active (I…
Show quoted text 9 lines
> Are you joking ? If you activate main lazarus window then only active > window is lazarus main window. There's no chance to have 2 active > windows of same application at the same time (we'll it is if > TCustomForm.Active says that it's active but really it isn't). I should have been more careful in my wording: I don't want the others to be active (I know only one window can be active), but I do want them to be raised over non-lazarus windows.

You already started to worry me :)))))

Show quoted text 6 lines
I have typically one or more terminals, a browser and a VMWare open besides lazarus. I can raise the main lazarus window, but then I must still go and look for other IDE windows. By automatically raising these when the main window becomes active, this would reduce my search time :-)

Yes, I think there's already an issue about it. You want all lazarus forms to be on top of other terminals,browsers etc etc. Maybe it can be implemented in TApplication as property, so you can choose behaviour of your app ... but implementing that in IDE only doesn't smell good.Qt and Gtk can do that under X11, but I don't know how it can (or does it work at all) under Carbon and others.

The original question was about raising/focusing the messages window when compiling. On my PC neither happens, so the value of the abovementioned checkbox in the settings dialog becomes meaningless ?

If you're talking about "Focus messages after compilation" then it works here (qtlcl, KDE). It does exactly what label says. But that focuses messages form, so that's why I don't use that option, I would like that messages form just changes Z-order (no matter if it's active) to be on top of other non-modal laz forms.

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

Reply by email

Benito van der Zander
to Bernd: There must be some explicit SetFocus() calls hidden somewhere deep inside the code. I…

I had the same problem with jump-to-next-error/ctrl+f8 (on xfce), and fixed it somewhere else:

http://bugs.freepascal.org/view.php?id=21706

But my change is just as ugly as yours

Bernd wrote 32 lines
There must be some explicit SetFocus() calls hidden somewhere deep inside the code. I don't know where exactly the code is located that * writes the compiler error messages and then (sometimes) sets focus * writes the code tools errors and then (sometimes) sets focus I would have to figure out how to trace it back with the debugger somehow if I figure out where to set the breakpoint (would a breakpoint in in TMessagesView.FormActivate() give me a useful stack trace?), maybe I have to grep the entire code for SetFocus(). Now out of sheer desperation I have patched my local copy as follows: in msgview.pp for the event OnActivate: procedure TMessagesView.FormActivate(Sender: TObject); begin SourceEditorManagerIntf.ActiveSourceWindow.SetFocus; end; Now the message window cannot have the focus anymore at all, it will immediately focus back to the source editor whenever something activates it but this unknown "something" in the code that is doing this is the real root of the evil, I need to find it. Bernd -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply by email

Bernd
to Mattias Gaertner: On Mon, 21 May 2012 18:27:19 +0200 ide/main.pp function TMainIDE.DoBuildProject…

2012/5/21 Mattias Gaertner :

?IDEWindowCreators.ShowForm(MessagesView,EnvironmentOptions.MsgViewFocus);

This does not focus the window. Its happening later. It is raising an exception:

#0 fpc_raiseexception(0xac8b9b20, 0xad22c760, 0xbfffe928) at /home/bernd/lazsvn/fixes_2_6/rtl/inc/except.inc:191 #1 OUTPUTFILTER_TOUTPUTFILTER_$__RAISEOUTPUTFILTERERROR$ANSISTRING at :0 #2 ?? at :0
#3 OUTPUTFILTER_TOUTPUTFILTER_$__READLINE$ANSISTRING$BOOLEAN at :0 #4 OUTPUTFILTER_TOUTPUTFILTER_$__EXECUTE$TPROCESSUTF8$TOBJECT$TIDEEXTERNALTOOLOPTIONS$$BOOLEAN at :0
#5 COMPILER_TCOMPILER_$__COMPILE$crc831BB2E1 at :0 #6 TMAINIDE__DOBUILDPROJECT(CRBUILD, [PBFCLEANCOMPILE], <error reading variable>) at main.pp:12271
#7 TMAINIDE__ONPROCESSIDECOMMAND(0xad25cf10, 1402, true, <error reading variable>) at main.pp:3344
#8 TSOURCENOTEBOOK__PROCESSPARENTCOMMAND(0xac853920, 1402, '', 0x0, true, <error reading variable>) at sourceeditor.pp:7496 #9 TSOURCEEDITOR__PROCESSUSERCOMMAND(0xac647e90, 1402, '', 0x0, <error reading variable>) at sourceeditor.pp:3230
#10 TCUSTOMSYNEDIT__DOONPROCESSCOMMAND(1402, '', 0x0, <error reading variable>) at synedit.pp:6578
#11 TCUSTOMSYNEDIT__COMMANDPROCESSOR(1402, '', 0x0, <error reading variable>) at synedit.pp:5973
#12 TCUSTOMSYNEDIT__KEYDOWN(0, [], <error reading variable>) at synedit.pp:2732 #13 TWINCONTROL__KEYDOWNBEFOREINTERFACE(0, [], <error reading variable>) at ./include/wincontrol.inc:5540
#14 TWINCONTROL__DOKEYDOWNBEFOREINTERFACE({MSG = 48384, CHARCODE = 0, UNUSED = 0, KEYDATA = 4653057, RESULT = 0}, false, <error reading variable>) at ./include/wincontrol.inc:5669
#15 TWINCONTROL__CNKEYDOWN({MSG = 48384, CHARCODE = 0, UNUSED = 0, KEYDATA = 4653057, RESULT = 0}, <error reading variable>) at ./include/wincontrol.inc:6960
#16 _$SYSTEM$_Ll5512(void, <error reading variable>) at /home/bernd/lazsvn/fixes_2_6/rtl/inc/objpas.inc:592 #17 RAISELOOP(0xbffff224) at ./include/wincontrol.inc:6870 #18 TWINCONTROL__WNDPROC({MSG = 48384, WPARAM = 0, LPARAM = 4653057, RESULT = 0, WPARAMLO = 0, WPARAMHI = 0, LPARAMLO = 1, LPARAMHI = 71, RESULTLO = 0, RESULTHI = 0}, <error reading variable>) at ./include/wincontrol.inc:5298
#19 TCUSTOMSYNEDIT__WNDPROC({MSG = 48384, WPARAM = 0, LPARAM = 4653057, RESULT = 0, WPARAMLO = 0, WPARAMHI = 0, LPARAMLO = 1, LPARAMHI = 71, RESULTLO = 0, RESULTHI = 0}, <error reading variable>) at synedit.pp:5560
#20 DELIVERMESSAGE(0xac647e90, void) at lclmessageglue.pas:117 #21 DELIVERMESSAGE(0xac647e90, void) at ./gtk2/gtk2proc.inc:3591 #22 DELIVERKEYMESSAGE(0xac647e90, void, 0xbffff244) at ./gtk2/gtk2proc.inc:1958 #23 HANDLEGTKKEYUPDOWN(0x95c8110, 0x956aa38, 0xad25cf10, true, true, 0x8b7023c 'key-press-event') at ./gtk2/gtk2proc.inc:2342 #24 GTKKEYPRESS(0x95c8110, 0x956aa38, 0xad25cf10) at ./gtk2/gtk2callback.inc:822 #25 ?? at :0
#26 g_closure_invoke at :0
#27 ?? at :0
#28 g_signal_emit_valist at :0
#29 g_signal_emit at :0
#30 ?? at :0
#31 gtk_propagate_event at :0
#32 gtk_main_do_event at :0
#33 ?? at :0
#34 g_main_context_dispatch at :0
#35 ?? at :0
#36 g_main_context_iteration at :0
#37 TGTK2WIDGETSET__APPWAITMESSAGE(<error reading variable>) at ./gtk2/gtk2widgetset.inc:2402
#38 TAPPLICATION__IDLE(true, <error reading variable>) at ./include/application.inc:417
#39 TAPPLICATION__HANDLEMESSAGE(<error reading variable>) at ./include/application.inc:1281
#40 TAPPLICATION__RUNLOOP(<error reading variable>) at ./include/application.inc:1413
#41 TWIDGETSET__APPRUN(0x80a6730 <TAPPLICATION__RUNLOOP>, <error reading variable>) at ./include/interfacebase.inc:60 #42 TAPPLICATION__RUN(<error reading variable>) at ./include/application.inc:1401
#43 :116

and then I am somewhere deep inside some FPC RTL exception code and for some reason not able to continue stepping to the point where thsi exception is actually handled. I suspect where this exception is handled there is also the code that actually prints the lines into the message window and that also focuses the message window.

When I provoke an error with the code tools it will also raise an exception. I suspect I need to find where this exception is handled so I can continue to investigate what is actually printing the lines into message window.

I'm looking for the code that does the printing of the error messages into the message window.

Reply by email

Mattias Gaertner
to Bernd
Show quoted text 5 lines
2012/5/21 Mattias Gaertner : > ?IDEWindowCreators.ShowForm(MessagesView,EnvironmentOptions.MsgViewFocus); This does not focus the window. Its happening later.

Maybe

ide/main.pp
function TMainIDE.DoJumpToCompilerMessage

"if FocusEditor then begin"

Mattias

Reply by email

Juha Manninen
to Unknown author: In my experience, focus handling of the IDE on linux is seriously messed up. It has never…
Show quoted text 5 lines
In my experience, focus handling of the IDE on linux is seriously messed up. It has never worked decently. I spend a lot of time looking for all the various IDE windows :/ (and that's on a Kubuntu, not Xubuntu)

GTK2 bindings have problems with both Z-order and focus handling. QT bindings behave much better.

Bernd, you didn't even mention your widgetset when building Lazarus. Did you try both GTK2 and QT ?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120521/7b4425fd/attachment.html>

Reply by email

Martin
to Mattias Gaertner: On Mon, 21 May 2012 19:19:40 +0200 Maybe ide/main.pp function…
Mattias Gaertner wrote 14 lines
On Mon, 21 May 2012 19:19:40 +0200 Bernd wrote: > 2012/5/21 Mattias Gaertner: > >> IDEWindowCreators.ShowForm(MessagesView,EnvironmentOptions.MsgViewFocus); > This does not focus the window. Its happening later. Maybe ide/main.pp function TMainIDE.DoJumpToCompilerMessage "if FocusEditor then begin"

I did set a break in TCustomForm.Activate; And forced a codetool error message.

    procedure TMainIDE.DoJumpToCodeToolBossError;
calls
       IDEWindowCreators.ShowForm(MessagesView,true);
followed by
       SourceEditorManager.ShowActiveWindowOnTop(True);

both calls activate the window.

On windows the WM_ACTIVATE messages are handled immediately (during the call) and therefore they obey the order.
No idea, maybe GTK re-orders the events?

After all, those calls are the same for win and gtk2. So there must be something in the widgetset

Reply by email

Mattias Gaertner
to Martin
Show quoted text 32 lines
On 21/05/2012 18:33, Mattias Gaertner wrote: > On Mon, 21 May 2012 19:19:40 +0200 > Bernd wrote: > >> 2012/5/21 Mattias Gaertner: >> >>> IDEWindowCreators.ShowForm(MessagesView,EnvironmentOptions.MsgViewFocus); >> This does not focus the window. Its happening later. > Maybe > > ide/main.pp > function TMainIDE.DoJumpToCompilerMessage > > "if FocusEditor then begin" > I did set a break in TCustomForm.Activate; And forced a codetool error message. procedure TMainIDE.DoJumpToCodeToolBossError; calls IDEWindowCreators.ShowForm(MessagesView,true); followed by SourceEditorManager.ShowActiveWindowOnTop(True); both calls activate the window. On windows the WM_ACTIVATE messages are handled immediately (during the call) and therefore they obey the order. No idea, maybe GTK re-orders the events? After all, those calls are the same for win and gtk2. So there must be something in the widgetset

Probably a combination.
It works here with gtk2 + lightdm. Docked and not docked.

Mattias

Reply by email

Bernd
to Bernd

oki. As far as compiling error messages is concerned the attached patch fixes it. Apparently the mere act of bringing the window to the front is already enough to steal the focus.

This should always be called with false. The reason is if I have configured that i want it in the front then it is already at the front at this moment and if not then I don't want to have it popping up now.

The next thing will be the messages after code tools errors, I suspect it is doing the same thing here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: focus.patch
Type: application/octet-stream
Size: 654 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120521/1a8bd5fd/attachment.obj>

Reply by email

Bernd
to Bernd

Undo the last patch and apply this one instead. It will fix all my problems and it does not change intended behavior. After an error the Source is in front (was it already before) and now its also focused. Codetools errors never change focus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: focus1.patch
Type: application/octet-stream
Size: 1282 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120521/780887cd/attachment-0001.obj>

Reply by email

Martin
to Bernd
Bernd wrote 5 lines
Undo the last patch and apply this one instead. It will fix all my problems and it does not change intended behavior. After an error the Source is in front (was it already before) and now its also focused. Codetools errors never change focus.

Except, this patch will alter behaviour that currently works. If the msg window is buried behind lots of other IDE window, it will currently end up 2nd (on windows) with only the source editor on top. That is useful. And worxs (on w32)

So the real bug is in gtk2 widgetset code. Which in your case for some reason does not handle multiply window changes....

Reply by email

Bernd
to Martin

2012/5/21 Martin :

Except, this patch will alter behaviour ?that currently works. ?If the msg window is buried behind lots of other IDE window, it will currently end up 2nd (on windows) with only the source editor on top. That is useful. And worxs (on w32)

Ok, i have another patch (undo the other one and apply this one instead). It puts an Application.ProcessMessages between the two window manipulations. Now it does not change behavior and this also fixes all my bugs.

So the real bug is in gtk2 widgetset code. Which in your case for some reason does not handle multiply window changes....

It seems it has to do with the window manager. I just tried with OpenBox and there it works without the patch while with xfwm4 which is the default window manager for XFCE it seems it does not like the way the windows are switched here.

(Unfortunately I cannot use any other window manager because xfwm4 is the only window manager that does 2d hardware compositing which makes any other wm feel slow and unresponsive compared to xfwm4 on my old hardware)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: focus2.patch
Type: application/octet-stream
Size: 753 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120522/2b8253b9/attachment.obj>

Reply by email

zeljko
to Bernd
Bernd wrote 18 lines
2012/5/21 Martin : > Except, this patch will alter behaviour that currently works. If the > msg window is buried behind lots of other IDE window, it will currently > end up 2nd (on windows) with only the source editor on top. > That is useful. And worxs (on w32) Ok, i have another patch (undo the other one and apply this one instead). It puts an Application.ProcessMessages between the two window manipulations. Now it does not change behavior and this also fixes all my bugs. > So the real bug is in gtk2 widgetset code. Which in your case for some > reason does not handle multiply window changes.... It seems it has to do with the window manager. I just tried with OpenBox and there it works without the patch while with xfwm4 which is the default window manager for XFCE it seems it does not like the way the windows are switched here.

Then it will be better to find out what's needed to be changed inside widgetset.There's already routine which checks wm name, so eg. if GetWM = 'xfwm' then do

  somethingElse();

Also best would be to create example (if possible) which reproduces problem - then it won't be hard to fix I guess.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120522/4fc4dd52/attachment.html>

Reply by email

Martin
to zeljko
zeljko wrote 26 lines
On Tuesday 22 of May 2012 03:16:42 Bernd wrote: > 2012/5/21 Martin : > > Except, this patch will alter behaviour that currently works. If the > > msg window is buried behind lots of other IDE window, it will currently > > end up 2nd (on windows) with only the source editor on top. > > That is useful. And worxs (on w32) > > Ok, i have another patch (undo the other one and apply this one > instead). It puts an Application.ProcessMessages between the two > window manipulations. Now it does not change behavior and this also > fixes all my bugs. >

...

Show quoted text 12 lines
Then it will be better to find out what's needed to be changed inside widgetset.There's already routine which checks wm name, so eg. if GetWM = 'xfwm' then do somethingElse(); Also best would be to create example (if possible) which reproduces problem - then it won't be hard to fix I guess.

+1

The problem with a global ProcessMessages is, that it processes all messages. Under heav load, that can include the next key-stroke, and the method can be re-entered.

as far as I can see that, somewhere the GTK-interface is sending the "activate win" connamd to gtk2. At this point, it might need to handle certain (but not all) messages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120522/c01a9692/attachment.html>

Reply by email

Bernd
to Martin

I have made a demo application that demonstrates the problem reliably on my machine.

The problem occurs when the form that is supposed to end up on top already had the focus at the beginning. It seems xfwm4 for some reason thinks the focus never went away and just ignores the second focusing. The z-order of windows is always correct, only the focus is wrong.

Attached is a demo program with instructions how to use and what to observe.

Bernd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: focustest.tar.bz2
Type: application/x-bzip2
Size: 2674 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120522/e7c74ff0/attachment.bin>

Reply by email

Bernd
to Bernd

with Qt it is even worse. A single ProcessMessages is not enough, I have to *wait* until the other window actually has received focus before I am allowed to proceed to issue the next focus change.

procedure TForm1.DoItBetter;
begin
  F1.ShowOnTop;
  while not F1.Active do begin;
    writeln(FormatDateTime('ss.zzz', Now));
    Application.ProcessMessages;
  end;
  F2.ShowOnTop;
  WriteLn('done');
end;

53.055
53.056
53.057
53.058
53.058
53.058
53.058
53.058
53.058
53.058
53.058
53.058
53.058
53.058
done

It takes a few milliseconds with other window managers too but with xfwm4 I really have to wait. Other WMs do not require me to wait, with xfwm4 I have to wait until OtherFom1 is actually officially active until I may proceed with activating OtherForm2.

Reply by email

zeljko
to Bernd
Bernd wrote
with Qt it is even worse. A single ProcessMessages is not enough, I have to *wait* until the other window actually has received focus before I am allowed to proceed to issue the next focus change.

You tested with example from previous mail ?

zeljko

Show quoted text 40 lines
procedure TForm1.DoItBetter; begin F1.ShowOnTop; while not F1.Active do begin; writeln(FormatDateTime('ss.zzz', Now)); Application.ProcessMessages; end; F2.ShowOnTop; WriteLn('done'); end; 53.055 53.056 53.057 53.058 53.058 53.058 53.058 53.058 53.058 53.058 53.058 53.058 53.058 53.058 done It takes a few milliseconds with other window managers too but with xfwm4 I really have to wait. Other WMs do not require me to wait, with xfwm4 I have to wait until OtherFom1 is actually officially active until I may proceed with activating OtherForm2. -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120522/6ce3766b/attachment-0001.html>

Reply by email

Bernd
to zeljko

Sorry, this mail did not go to the list, hit the wrong reply button, here it is again:

2012/5/22 zeljko :

You tested with example from previous mail ?

Yes, I just compiled the same example with Qt and then none of the buttons in OtherForm2 work anymore (they arrange the z-order correctly but leave focus on the wrong form). Clicking the buttons in Form1 works.

I'm trying to experiment with all kinds of things I could do in the DoItBetter() method (tried such hacks as disabling the left form before bringing it to the top, and similar things. but doesn't work)

Reply by email

zeljko
to Bernd: with Qt it is even worse. A single ProcessMessages is not enough, I have to *wait* until…
Bernd wrote
with Qt it is even worse. A single ProcessMessages is not enough, I have to *wait* until the other window actually has received focus before I am allowed to proceed to issue the next focus change.

Lucky you, your example raises problem on my machine which is not so slow Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz + 8 GB ram (qtlcl). Running xfwm in another screen (startx -- :1) - focus stays at form1 all the time :), under kwin and metacity it works perfect. Seem that xfwm makes some lag when switching focus, so I have to dig into xfwm sources and see what's up and then fix qt and gtk2.

Show quoted text 40 lines
procedure TForm1.DoItBetter; begin F1.ShowOnTop; while not F1.Active do begin; writeln(FormatDateTime('ss.zzz', Now)); Application.ProcessMessages; end; F2.ShowOnTop; WriteLn('done'); end; 53.055 53.056 53.057 53.058 53.058 53.058 53.058 53.058 53.058 53.058 53.058 53.058 53.058 53.058 done It takes a few milliseconds with other window managers too but with xfwm4 I really have to wait. Other WMs do not require me to wait, with xfwm4 I have to wait until OtherFom1 is actually officially active until I may proceed with activating OtherForm2. -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

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

Reply by email

zeljko
to Martin: ... +1 The problem with a global ProcessMessages is, that it processes all messages.…
Martin wrote 39 lines
On 22/05/2012 06:50, zeljko wrote: > On Tuesday 22 of May 2012 03:16:42 Bernd wrote: > > 2012/5/21 Martin : > > > Except, this patch will alter behaviour that currently works. If > > > the > > > > > > msg window is buried behind lots of other IDE window, it will > > currently > > > > end up 2nd (on windows) with only the source editor on top. > > > > > > That is useful. And worxs (on w32) > > > > Ok, i have another patch (undo the other one and apply this one > > > > instead). It puts an Application.ProcessMessages between the two > > > > window manipulations. Now it does not change behavior and this also > > > > fixes all my bugs. ... > Then it will be better to find out what's needed to be changed inside > widgetset.There's already routine which checks wm name, so eg. > > if GetWM = 'xfwm' then do > > somethingElse(); > > Also best would be to create example (if possible) which reproduces > problem - then it won't be hard to fix I guess. +1 The problem with a global ProcessMessages is, that it processes all messages. Under heav load, that can include the next key-stroke, and the method can be re-entered.

That's why I'm against unneeded processMessages inside IDE or LCL. Problem is inside xfwm4 (XFCE window manager) .... just reproduced it on my machine with Bernds example.
just simple code:
SetActiveWin(Form1);
SetActiveWin(Form2);
does not work under xfwm4.
Form1 is activated, but Form2 is never activated in this case.Must be processmessages between those ops (or some reasonable delay) to get it work. SyncX also does not help.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120522/74d5c0a0/attachment-0001.html>

Reply by email