Re: [Lazarus] LHelp and LazMouseAndKeyInput package

2021-02-23 Thread Sergey Bodrov via lazarus
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 <
lazarus@lists.lazarus-ide.org>:

> On Mon, Feb 22, 2021 at 3:29 AM Andrey Sobol via lazarus <
> lazarus@lists.lazarus-ide.org> wrote:
>
>> 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}
>>
>
> 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?
>
>
>
>> 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).
>>
>
> 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
>
> --
> ___
> lazarus mailing list
> lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>


-- 
*Bodrov Sergey*
software development, IT consulting
http://www.serbod.com
*Phone (Belarus):* +375(25)794-21-58
*Skype:* sergey.bodrov1
*e-mail:* ser...@gmail.com, oxot...@yandex.ru
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] LHelp and LazMouseAndKeyInput package

2021-02-22 Thread R.Smith via lazarus


On 2021/02/22 10:52, Juha Manninen via lazarus wrote:


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.


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


-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] LHelp and LazMouseAndKeyInput package

2021-02-22 Thread Juha Manninen via lazarus
On Mon, Feb 22, 2021 at 10:52 AM Juha Manninen 
wrote:

> 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.
>

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
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] LHelp and LazMouseAndKeyInput package

2021-02-22 Thread Juha Manninen via lazarus
On Mon, Feb 22, 2021 at 3:29 AM Andrey Sobol via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> 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}
>

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?



> 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).
>

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
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] LHelp and LazMouseAndKeyInput package

2021-02-21 Thread Andrey Sobol via lazarus

On 22.02.2021 1:45, Juha Manninen via lazarus 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.

--
Andrey Sobol.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] LHelp and LazMouseAndKeyInput package

2021-02-21 Thread Andrey Sobol via lazarus

On 22.02.2021 1:45, Juha Manninen via lazarus wrote:

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




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 :)

--
Andrey Sobol
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] LHelp and LazMouseAndKeyInput package

2021-02-21 Thread Juha Manninen via lazarus
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
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus