Help has improved lately thanks to Andrey Sobol's patches mostly. However a new dependency was added: LazMouseAndKeyInput. On Linux and UNIX systems it pulls in libXtst dependency. LHelp is part of Lazarus BigIde target which is used for releases. Extra dependencies for BigIde should be avoided if possible.

Now I studied how LazMouseAndKeyInput is used in LHelp. Well, it is not used!
LHelpCore has MouseAndkeyInput in its uses section but removing it and the whole package dependency makes no difference.
My analysis: LazMouseAndKeyInput dependency can be removed from LHelp. Am I right?

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210222/1043a833/attachment.html>

Helo Juha,

You excluded this code from lcore.pas

procedure THelpForm.ShowApp();
......
{$IFDEF WINDOWS}
     // Go to TOC TreeView and to get focus on foreground window
     KeyInput.Apply([ssCtrl]);
     KeyInput.Press(VK_T);
     KeyInput.UnApply([ssCtrl]);
{$ENDIF}

Without the code on windows system we can`t get rightly a focus lHelp by an event of restore the window after hide (the window is blinking on an aplication panel sometimes). We should send an user input sentence to the foregroud window from a mouse or from keyboard to get focus (that is windows specific problem).

I see some solutions of that:
1. To rewrite that code by WinApi (that is simple).
2. To exclude the package dependency on Mac system, but I don`t know how?
3. To fix the Application.BringToFront() function at windows to rightly bring a foreground window to a front of a display.

But I don`t see that problem now :). May be the blinkg was also a part of that issue https://bugs.freepascal.org/view.php?id=38276

I redone many pieces after that, that a second round :)

Juha Manninen wrote

Now I studied how LazMouseAndKeyInput is used in LHelp.

Juha,

read this
https://www.codeproject.com/Tips/76427/How-to-bring-window-to-top-with-SetForegroundWindo

That problem was before, but now I don`t see it.

On Mon, Feb 22, 2021 at 3:29 AM Andrey Sobol via lazarus <

Oh, LazMouseAndKeyInput was just for that code.
It created a serious bug. After pressing F1 in source editor the end of current word was cut off.
The reason was that VK_T went to Lazarus IDE, although LHelp sent it to itself, and the default command for VK_T is "Delete to end of word". Didn't you notice the bug?
It was discussed in Lazarus devel mailing list. It should have happened here instead.
Something funny happens in the interprocess communication. How could key VK_T bring LHelp to front if it went to Lazarus' source editor?

Yes, in Windows terminology bringing to front means blinking an icon in Taskbar.
A Lazarus user however wants to see the help window right after pressing F1.

I see some solutions of that:

1. To rewrite that code by WinApi (that is simple). 2. To exclude the package dependency on Mac system, but I don`t know how?

LazMouseAndKeyInput must be fixed for MacOS Cocoa but that is a whole different issue.
Now that problem involves only Windows. A cross-platform package is not needed for that.
The libXtst library dependency pulled in for Linux (and UNIX) was a 100% increase of system dependencies for a Lazarus release, and for absolutely no benefit.
Now Lazarus BigIde depends on just libgtk2.0-dev.

3. To fix the Application.BringToFront() function at windows to rightly

bring a foreground window to a front of a display.

That was my idea, too.
The method name BringToFront() is quite unambiguous. It should bring the application to front. :)
The name is not BlinkAnIconInTaskbar().
If you know how to fix it, please do. I don't use Windows much myself. Does this idea go against some Windows convention?

But I don`t see that problem now :). May be the blinkg was also a part

of that issue https://bugs.freepascal.org/view.php?id=38276 I redone many pieces after that, that a second round :)

I removed the LazMouseAndKeyInput dependency in r64647. Please fix the remaining issues as you see fit (without libXtst dependency for Linux).

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210222/2a10014b/attachment-0001.html>

Ok, that was not accurate. Many other system libraries are pulled in by libgtk2.0-dev.
However in a distro package system level it is the only requirement. Adding dependency for X brings another problem: Lazarus would not work with Wayland display server.
Now it works if the widgetset supports Wayland. Major widgetsets like GTK3 and QT5 do support it. Not sure about GTK2.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210222/02ba3bcf/attachment.html>

YES, this is very important.

I am not looking to weigh in on the issue of how Lazarus help works, but I can say something about Windows and the next comment:.

The name is not BlinkAnIconInTaskbar(). If you know how to fix it, please do. I don't use Windows much myself. Does this idea go against some Windows convention?

Blinking and Bringing to Front are two very distinct ideas in Windows and two different use-cases, though they often coincide. If I recall the Microsoft discussions correctly, the idea wasn't to ever blink when a user clicks the application into the foreground, or for instance pulls up the Help. Blinking the taskbar was only to be done if your application is *in the Background* AND something happens that is important for which you need to grab the User's attention towards it. (If your program is in the foreground/focused, you have carte-blanche on how to flash it or grab attention and don't need a flickering taskbar icon specifically, though *also* doing it isn't a sin)

The event that lead to you needing to blink the taskbar icon may well also require bringing to front, but it might also not (the judgement is left up to the software designer).

A good example is the Lazarus IDE after a debug session in Windows. After running your program (i.e. once your program terminates) Lazarus will both pop to front *and* flash the taskbar icon IF, and only IF, the debugged program was the focused desktop window. If I switch to any other program while the debugged program was running (pushing more apps onto the "focus" stack of the desktrop manager), Lazarus correctly does not "steal" the focus back by popping to front, but it does still flash the taskbar icon to make the user aware.

With the above in mind, I'd say when the user press F1 (or invoke help in any way) there should be a help window popping up/to front/focusing/etc, but no need for any blinking. The user KNOWS/EXPECTS what is coming, no need to try and draw their attention to it.

A final note: Lots of Windows users HATE taskbar icons blinking, they turn it off. (Just search google on how to turn it off, you will find oodles of hate rants).

For more info, see:
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-flashwindowex

Cheers,

Ryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210222/0e47b025/attachment.html>

There is another useless dependency for AvgLvlTree inside IpHtml.pas unit.

It used only for private VisitedList: TStringMap field in TIpHtmlCustomPanel and has no benefits against TStringList.Find()

пн, 22 февр. 2021 г. в 11:52, Juha Manninen via lazarus <