Bugs in Example Projects window

[JuhaManninen]

As already mentioned in "Juggling Multiple Lazarus Projects" thread, for me the Example Projects window shows an empty list.
Mysteriously the list is filled when Lazarus is started with a clean configuration. Then after opening any project the list is empty again. This is especially weird as a project's settings should not affect example project management anyhow. It only uses info from the global settings.

My system:
 Manjaro Linux (any Linux should do, this bug is only about paths)
 Lazarus is built from sources in Git development "main" branch, pulled into directory ~/SW/lazarus (/home/juha/SW/lazarus).
 Lazarus is started as "./lazarus &" directly from the source directory.

Example Projects has an option "Directory where Examples go". Its value is : /home/juha/.lazarus/examples_work_dir/
which is correct although it is irrelevant for this bug.

To reproduce :
1. Start Lazarus with a clean configuration, either by --pcp= parameter or by deleting the default config directory (~/.lazarus).
2. Open the Tools -> Example Projects window. The list is filled.
3. Close the Example Projects window. Open ide/lazarus.lpi (or any other project).
4. Open the Example Projects window again. The list is empty.

An alternative step 3.: Open one of the example projects from the window. It opens OK. Then continue with step 4.
Can anybody else reproduce?

There was an issue with the example project path also earlier.
I changed the EnvironmentOptions in commit 9f142eef but had to revert it in commit 9f142eef. See issue :
 https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39671
However opening a project does not affect EnvironmentOptions. This bug is different.

Another issue:
The search or filter edit control sucks. It shows the "Search Here" text also when it gets focus. A user must delete the text first. A TListViewFilterEdit control should be used instead. It is designed for exactly this purpose.
To see it in action, open in Lazarus IDE: Package -> Open Loaded Package ...
It also supports browsing the list with arrow keys while the filter edit has focus.

[JuhaManninen]

It is caused by the global LazarusDirectory setting after all. In Environment options "Lazarus directory (default for all projects)".
At least here it is a relative path always : "../SW/lazarus/". If I try to change it to an absolute path, it gets saved as relative again.
The path is wrong. My current directory is "~/SW/lazarus/". Expanding "../SW/lazarus/" then makes "~/SW/SW/lazarus/".

Adding "Exit('/home/juha/SW/lazarus/');" as a first line in function TExampleData.GetLazDir makes the examples window work.

Earlier (issue #39671) I tried to change the logic for this exact same LazarusDirectory but it caused a regression.
Must study this more ...

[Edit]
I fixed it in commit e723acfe03. Reading LazarusDirectory directly from config XML file was a bad idea. The options interface provides function GetParsedLazarusDirectory which returns the correct path.
I don't know why it is stored in the config file in such a strange way.

I still wonder why nobody else noticed this problem.

[Edit2]
The path is relative to defaultGetPrimaryConfigPath, by default "~/.lazarus", where the environmentoptions.xml is stored.

[dbannon]

Juha, there was a reason why I had to resort to reading the path from the config file, it was definitely not something I wanted to to do, it pulled in xml reading stuff and added quite a lot of code.

I cannot remember why it was done, maybe, tomorrow, I will go back over the forum posts and see what it was ....

Davo

[Aruna]

Another issue:
The search or filter edit control sucks. It shows the "Search Here" text also when it gets focus. A user must delete the text first. A TListViewFilterEdit control should be used instead. It is designed for exactly this purpose.
To see it in action, open in Lazarus IDE: Package -> Open Loaded Package ...
It also supports browsing the list with arrow keys while the filter edit has focus.

Juha please have a look at this, we already have this functionality built in to TListBox: TListBox built-in search+filter functionality

[wp]

The search or filter edit control sucks. It shows the "Search Here" text also when it gets focus. A user must delete the text first.

Such a hint text should not be stored in the Edit.Text itself but in the Edit.TextHint which is displayed in grayed-out style as long as Edit.Text is empty (https://lazarus-ccr.sourceforge.io/docs/lcl/stdctrls/tcustomedit.texthint.html).

[JuhaManninen]

Juha please have a look at this, we already have this functionality built in to TListBox: TListBox built-in search+filter functionality

No we don't. Please see my answer in the other thread. Why do you call it search+filter functionality while it is only a search?

[Aruna]

Juha please have a look at this, we already have this functionality built in to TListBox: TListBox built-in search+filter functionality

No we don't. Please see my answer in the other thread. Why do you call it search+filter functionality while it is only a search?

I thought it was both but I guess I was wrong :-(

[dbannon]

===== LazarusDirectory ======

Earlier (issue #39671) I tried to change the logic for this exact same LazarusDirectory but it caused a regression.

You told me you had fixed it. And from memory, it needed to be fixed. But you did not tell me you reverted that fix.  Thanks very much.

background : Initially, direct access to LazarusDirectory was not available, Getmen eventually either found a way or made a way but by that stage, my code was in the review pipeline.
https://forum.lazarus.freepascal.org/index.php/topic,57680.msg434967.html#msg434967
Clearly I should have gone back to it but I was traveling then and time was a rare commodity. But with a fix applied to the LazarusDirectory name issue, it was not critical. 

I still wonder why nobody else noticed this problem.

Well, in my case I am not using trunk for day to day work anymore because of this https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39540
The problem only shows up if you are using the default location for PCP. Most trunk users have it as a second install and its config is redirected. Certainly in my case.

======= Search Prompt ========

Such a hint text should not be stored in the Edit.Text itself but in the Edit.TextHint which is displayed in grayed-out style as long as Edit.Text is empty (https://lazarus-ccr.sourceforge.io/docs/lcl/stdctrls/tcustomedit.texthint.html).

yes, Martin_fr also mentioned textHint. I quote its extensive documentation -
TextHint fills the TCustomEdit with the value assigned to it, whenever the control's Text property is empty and the control does not have focus.

When the Example Window opens, I want the EditSearch to have Focus. Its the component the end user is most likely to want to use. But when an Edit control has Focus, the TextHint is not shown.

I also found using TextHint seemed to introduce some quite unexpected instabilities. Further research is indicated.

So, I coded the equivalent myself. This is the way most other systems work these days. The 'hint' is show until the user starts typing, on the first press of a character, the Prompt is removed. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40034.  This would a lot more intuitive if I could get that Prompt to be automatically selected when the user clicks back into the control but selecting it in OnEnter fails, I am still trying to find out why.

I think I will make a small dummy app just demonstrating TEdit and see where that leads.

Davo

 

[wp]

But when an Edit control has Focus, the TextHint is not shown.

Yes, this is in the docs, but in fact, the TextHint IS shown for the focused Edit on Windows and cocoa. This is different from Delphi. The TextHint is not shown on gtk2/gkt3, though (did not not test the qt's). It would be better if we'd have a consistent behaviour here.

[dbannon]

But when an Edit control has Focus, the TextHint is not shown.

Yes, this is in the docs, but in fact, the TextHint IS shown for the focused Edit on Windows and cocoa. This is different from Delphi. The TextHint is not shown on gtk2/gkt3, though (did not not test the qt's). It would be better if we'd have a consistent behaviour here.

Thanks WP.
Yes, thats what I have found although only tested on GTK2, Qt5 and Windows so far. Qt5 is OK too so its "only" a GTK2/3 issue.

So, I have some workable code but I am not exactly happy with it. Have to support GTK and drag the others down (or ifdef all over the place).

To make it usable in GTK2/GTK3, IMHO, I need to alter the tab order, have initial focus on the ListView (so the texthint shows) and first tab stop after that is the EditSearch. Thats fine so far, maybe even reasonably intuitive. But then tabbing back to the ListView (from the EditSearch) is hopeless if you have all the checkboxes and buttons as tabstop.

(Please look away now Aruna)
Does anyone seriously try and use these interfaces without a mouse ? Or choose tabbing rather than clicking 'cos its faster ? Using the mouse is flawless.

Anyway, I will graft this new model into my full test install and see if I like it, if I do, I will push another patch up in place of the previous one. Maybe later today unless someone has a better approach to suggest.

Right now, I need to go out and cut some firewood before it gets too hot.

Davo

[dsiders]

But when an Edit control has Focus, the TextHint is not shown.

Yes, this is in the docs, but in fact, the TextHint IS shown for the focused Edit on Windows and cocoa. This is different from Delphi. The TextHint is not shown on gtk2/gkt3, though (did not not test the qt's). It would be better if we'd have a consistent behaviour here.

Thanks WP.
Yes, thats what I have found although only tested on GTK2, Qt5 and Windows so far. Qt5 is OK too so its "only" a GTK2/3 issue.

So, I have some workable code but I am not exactly happy with it. Have to support GTK and drag the others down (or ifdef all over the place).

To make it usable in GTK2/GTK3, IMHO, I need to alter the tab order, have initial focus on the ListView (so the texthint shows) and first tab stop after that is the EditSearch. Thats fine so far, maybe even reasonably intuitive. But then tabbing back to the ListView (from the EditSearch) is hopeless if you have all the checkboxes and buttons as tabstop.

(Please look away now Aruna)
Does anyone seriously try and use these interfaces without a mouse ? Or choose tabbing rather than clicking 'cos its faster ? Using the mouse is flawless.

Anyway, I will graft this new model into my full test install and see if I like it, if I do, I will push another patch up in place of the previous one. Maybe later today unless someone has a better approach to suggest.

Right now, I need to go out and cut some firewood before it gets too hot.

Davo

I looked at the GTK docs. They call them "placeholders", and they do not exist in GTK2 (that I could find). It was introduced in GTK 3.2.

GTK3 is not working because there is no setter implemented for the value. It is even comment as such in the GTK3 bindings. I would file a bug report.

For GTK2, if they did not see fit to implement it - just assign a Hint for the edit control. No need to drag everyone else down because they gave up on GTK 2.

My $.02USD...

[Aruna]

(Please look away now Aruna)
Does anyone seriously try and use these interfaces without a mouse ? Or choose tabbing rather than clicking 'cos its faster ? Using the mouse is flawless.

Davo, listen to me please. The way 'I' see it 'anything' we design and develop will have two human interface devices connected, the keyboard and that mouse correct? All I am saying is whatever one is able to do by pointing and clicking the mouse one should also be able to do using the keyboard. If you are unable to do so to me that is a serious design flaw that needs to be reviewed and rectified.

Think about this. Let's say you are in the middle of the monthly payroll and that mouse decides to die on you.  The most frustrating thing is being in the middle of a payroll run and not being able to click that button using the keyboard to initiate printing payslips.  Consequently, no one gets paid and we have a riot on our hands. Now you see why it is important to have the keyboard be able to do at least the critical things that the mouse is used for. This happened long years ago in Sri Lanka when I was the Data Processing Manager at Blanka Diamonds. I had to rapidly put together a separate module to print the payslips using Clipper+dos lots of fun belive me 900 plus female employees at a Diamond factory were not pleased nor were they willing to wait until the next day. It was a Belgian operation.

Oh btw, I am sulking. First I screwed up by not realizing the example code widows was using a TListView and not a TListBox then I forgot the behaviour I was seeing was native to my gtk2/3 and might not work across all other platforms. Juha set me straight. Then I responded to a docking issue question only to be later enlightened the issue was with the embedded designer and another package was now available. Again Juha pointed this out diplomatically. So now I am sulking. I should have read that second docking issue question twice over carefully but in my haste, I screwed up. Lesson learnt.

[dbannon]

@dsiders - thanks for that. I think the draft I have now is quite usable by all parties except mouse-less users who could muddle through in an emergency. Its not how I would do it it if I was not supporting GTK2 but its not too bad.

All I am saying is whatever one is able to do by pointing and clicking the mouse one should also be able to do using the keyboard.

The issue is not 'able', my current draft will allow you to recover. But its not nice, you need to look very closely to see which component is currently on focus, the checkbox show a small difference as do the buttons. The list view on the other hand has no visible change as it gains focus if a row is already selected. Its definitely not usable on a day to day basis. Thats a GTK2 issue, not my code, not Lazarus.

An alternative way to work would be to unselect a row in the TListView onExit method, then, when you tab back to the ListView, you see a "half highlight" on the last row selected. Unfortunately, while the user can see it, I cannot find out which row it is programmatically. The user has every right to expect an Enter to activate the "half selected" row but thats not possible.

I believe this "half highlight" thing is a bug and will investigate further. I have unsuccessfully tried things at onExit like

Code: Pascal  [Select][+][-]

1.      ListView1.ClearSelection;
2.      ListView1.ItemIndex := -1;

   

In the mean time, to avoid that problem, I force the selection of the first row onEnter - "half highlights" are then cancelled and the user will get what they see if they press Enter then. No surprises. And if they have a suddenly broken mouse, and are very careful and observant, they could continue. But it would be stupid to do so.

....... I forgot the behaviour I was seeing was native to my gtk2/3 .....

Are you referring to the failure to Search While You Type you reported ?  Thats not a gtk2 thing, I do all my dev on gtk2, test on several different platforms, always works for me. I think you are using  six or seven month old source.

Davo

[dbannon]

Oh, so, so annoying.

As I pressed 'Send' for that last message, I realised how easy it is to solve that problem. In the ListView1.onExit, I record its ItemIndex in a 'regional' var, when we tab back in I restore it.

I cannot believe I looked at this for so long without realising there was such an easy fix !

(I still think this "half highlight" thing is a bug, will chase it down.)

Davo

[dsiders]

But when an Edit control has Focus, the TextHint is not shown.

Yes, this is in the docs, but in fact, the TextHint IS shown for the focused Edit on Windows and cocoa. This is different from Delphi. The TextHint is not shown on gtk2/gkt3, though (did not not test the qt's). It would be better if we'd have a consistent behaviour here.

Help topics for TextHint have been updated in commits 901b01e6 and ac088cfc. The updated content is on the documentation preview at:

https://dsiders.gitlab.io/lazdocsnext/lcl/stdctrls/tcustomcombobox.texthint.html
https://dsiders.gitlab.io/lazdocsnext/lcl/stdctrls/tcustomedit.texthint.html
https://dsiders.gitlab.io/lazdocsnext/lcl/groupededit/tcustomabstractgroupededit.texthint.html
https://dsiders.gitlab.io/lazdocsnext/