Lazarus

Using the Lazarus IDE => Debugger => Topic started by: Martin_fr on September 17, 2022, 10:12:10 pm

Title: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 17, 2022, 10:12:10 pm
A question that reached me about that dialog.
Described at https://wiki.lazarus.freepascal.org/DWARF


Quote
My problem with this is that the window width becomes sum of button widths, that is some of their caption widths plus some.
What do you think about reimplemented the dialog into TRadioGroup instead ?

A few points in advance. None meant to be against a change, but for completeness sake.

1)
I am not sure if this is a standard/generic multi-button dialog, or a specially made one.
If it is some generic, that wouldn't stop a new special made one, but it would mean, that the generic one might need improvements because such issues could arise for any other use of it too.

2)
Also, while I am of the opinion that by default design needs to accommodate translations, that is not always true. E.g. status bar text, is by design limited. Translators need to be aware.
And even putting radio buttons on, translators need to look at how long the text will be.

3)
If it were to be changed, then there are other options to consider: ListBox, ComboBox.
- Buttons have the "one click" advantage
- Others allow a preselection


 
Quote
Also i wonder if "don't ask again" should be made and explicit checkbox, reflected in the Project Options too.
Is this dialog INTENDED to be shown only once or on every run ? If only once, then "cancel" button is to be renamed into something positive, like "Run without debugger"

IIRC, "Cancel" allows not to run. And then go to project options, or choose an existing build mode rather than changing the current.

Otherwise the dialog changes the project settings. It is only shown again, if project settings need this. (diff project, or settings changed by user)


There is a general need to rework how this all works.
I.e. ideally project settings could be correct by default and the dialog would not be needed at all (a different warning dialog could appear if a user had changed settings to be incompatible).

However that is likely a bigger chunk of work.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 17, 2022, 10:57:28 pm
1) that the generic one might need improvements because such issues could arise for any other use of it too.

It is hard to do in general case. You can not "fix the multi-button dialog" but you can design a "yet another, better generic dialog"

Bad news:
If programmer thinks he "just needs buttons" - then you can not replace it without rethinking the user actions flow. IOW, you just can not fix it in LCL.

Like in the example of this DWARF dialog, the "Cancel" buton, what should it do???

1) Run the application for now, but show the warning again on the next run?
2) Run the application and show the dialog never again. You were warned, now you know what you do.
3) Cancel the compilation and do not run the applicaiton.

All the interpretation are valid. I do not think then automatic conversion to "ragiogroup + OK/Cancel buttons duo" is possible without re-thinking user story.

IOW, the existing generic dialog probably better left what it is.

Now, good news. Cheer up, Microsoft already thought it out for you! Microsoft introduced generic "Task Dialogs" in Windows Vista.

The dialogs were not ideal for every use case (generic dialogs can hardly be), but they were good enough and they quickly became familiar to desktop users.
Then Delphi programmers started making implementations for them for pre-Vista Windows soon, so they would not have to compile different code for XP and Vista.
One of the team who did this was French mORMot project (shamelessly kissing up and promoting).
Later they disagreed with Delphi/LLVM direction and chosen FPC as their future base. And NewPascal fork, just teasing :-)

So, see the screenshots here from the 2011 - https://synopse.info/forum/viewtopic.php?pid=2770#p2770
And i think those dialogs do work in FPC/LCL today.
At least i do see {$IfDef FPC} in d:\fpcupdeluxe\ccr\mORMot\SynTaskDialog.pas
...but not in mORMot2 library yet, so maybe they extracted it into a separate UI-only package, or will do later.

Quote
And even putting radio buttons on, translators need to look at how long the text will be.

Works both way. Shortening text without making it incomprehensible is not always possible.
What if the only way to squeeze text into small button would be making it terse cleaw meaningless for all users but most seasoned?

There is a reason why commercial vendors like Windows and Delphi did not go GetText way but instead made translation libraries capable of re-arranging window layout.

Quote
3) If it were to be changed, then there are other options to consider: ListBox, ComboBox.
- Buttons have the "one click" advantage

Bound to the question should it be "show once" or "show every run".

If only once - it is the opposite, it is advantage of forcing user to pay attention by requiring two clicks.

Quote
- Others allow a preselection

....which effectively mean there is no "click twice" penalty, after the first time.

The first time the dialog is shown - the radiogroup should have no selection, so the useris unable to click-through without actually thinking and making decision.

If the dialog would get shown away - the last choice is preselected, so the only thing left is to hit ENTER key.

----

I'm of the opiniong that ideally the "[ x ] Don't show again" checkbox is called for here.  But this opens more questions:
1) to save the choice in the project options file? or to start afresh when Lazarus is restarted or closed and re-oened the project?
2) i the used set the "don't show again" check and then regeretted it - the Project Option should provide to undo it in the Debugger section.
3) what about switching target architectures or debugger back-ends? The content of this dialog is said to be dependent upon both compiler target and chosen debugger back-end. Basically, it is the intersection between what compiler can emit for the target, and what debugger engine can consume. So, if i, for example, made a choice while working with FpDebug, and the switched to GNUDebug - how should Lazarus determine if to show this dialog now or not ? Maybe then the Project Options dialog should be able to immediately trigger this dialog when saving options with new debugger back-end ?

Then, the radio group can have two negative options.

=====================
(*)  Debug Format 1
(*)  Debug Format 2
(*)  Debug Format 3
.....empty space, visual cue between positive and negative choices
(*) Run without debugger now, ask me again next time
(*) Run without debugger always, don't ask again

[ OK ]    [ Cancel ]
=============

You can not avoid having Cancel button, because there is Esc key, Alt+F4 key and [ X ] button in the window caption bar. 
So, the third negative option "cancel  thecompilation" can not be had in the radiogroup.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 17, 2022, 11:03:38 pm
Also, should this thread be kept a separate one, or merged into the stycky one?

https://forum.lazarus.freepascal.org/index.php/topic,58745.0.html
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 17, 2022, 11:28:56 pm
Oh, i forgot one more argument for RadioGroup

Think is, you say about "translator job" - but it was not translator job at all...

Remember we found an inconsistency: the dialog says "DWARF 2 with sets" and the Project Options sais "DWARF with sets" -  forgetting to add 2, so it looks as DWARF 1 instead.

The proper design would have one source for both data, one single function kind of : GetAvailableDebugInfoFormats(const ProjecT:TProject = CurrentProject): TStringList

Such a "single source" should be used to populate both Program Options and this SWARF dialog and any other GUI element or even some imaginary HTML report about current project.

Now, it would be easier to populate `TComboBox.Lines` and `TRadioGroup.Items` form such a list, then to expand it iinto a multipele of TButton :-)
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 17, 2022, 11:37:51 pm
Also, should this thread be kept a separate one, or merged into the stycky one?

https://forum.lazarus.freepascal.org/index.php/topic,58745.0.html
I think we keep them separate. The other one is a quick help how to deal with the current dialog. Not a "how to replace"
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 18, 2022, 12:15:33 am
Quote
Bound to the question should it be "show once" or "show every run".
Kinda: "Show once - for each new project".
Unless you save yourself a new project template, and then it only shows, if you disable dwarf for your project.

It's a show every time, if you switch the project options back to stabs after each run... (I.e. if you have a VCS and reset the lpi/lps after each run)



There are several individual issues to deal with

1) reduce the width of the current dialog
Because we don't know when it will be removed/replaced entirely

2) remove/replace it.
From memory, when last I looked into it....

There is a reason (maybe outdated, but there are lots of targets, and use-cases to check) why the default is -g
It means FPC can choose an option that works, with whatever other settings there; as well as for the target and environment.

A "magical option" that uses -g only if supported by the debugger would be create. But packages (that should be included by this) are prebuild from Makefiles, and they don't follow some IDE magic.


3)
Your mention to refactor how the resource strings are retrieved to make them unique across all of the IDE.
Yes that is a 3rd and completely independent issue.

4) "don't show again"




The first point wont break anything.
So if someone has time to work on it => great.

All we need is to roughly pre-agree on a new layout.


I don't know about that new MS dialog.... This isn't (currently) a restyle of the entire IDE (if it was, it would never be a hopefully quick-ish fix).
And I don't know if its style is fitting outside the Windows world. (maybe it is? no idea)

Quote
e "[ x ] Don't show again"
Nope. Though if someone wants to contribute it, based on the assumption that it will be longer till the dialog can be replaced (and the work be obsolete), yes fine.
But if so, that would be a separate issue, because we would need to add a new option-storage for that, and an option to reset it.
Also it would need a diff name, because it would mean that all future projects would be "changed" without notification. (Or alternatively the project template would be updated, and it affects only new projects, which is less aggressive)
And it would need to recognise if the user did undo those changes for the current project, in which case it must show again, since there was a user action.

Quote
(*) Run without debugger now, ask me again next time
I do like this one.
Not sure how much extra code change it needs. (So, if a merge request is contributed, would be nice to have it as a 2nd commit)








Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: zamtmn on September 18, 2022, 12:17:33 pm
Please make DWARF as an automatic format for windows, this will remove 99% of the views of this dialog
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 18, 2022, 02:45:46 pm
2) A "magical option" that uses -g only if supported by the debugger would be create. But packages (that should be included by this) are prebuild from Makefiles, and they don't follow some IDE magic.

"Sufficiently smart" IDE would detect compiler flags did not match and would re-build those .PPUs and .OBJs in the project's local folder


Quote
I don't know about that new MS dialog.... This isn't (currently) a restyle of the entire IDE (if it was, it would never be a hopefully quick-ish fix).
And I don't know if its style is fitting outside the Windows world. (maybe it is? no idea)

Ths shoots down the whole "extend generic dialog" idea :-)

However, if you are okay to make a custom one-purpose dialog here, then "IDE style" is not a problem - for this specific place.
Granted, you would not want to sneakily make vanilla IDE dependent upon an out-of-the box library, so SynTaskDialog is still out of this topic.

So, a custom one-purpose dialog is what remains on the table.

Quote
Quote
e "[ x ] Don't show again"
Nope. Though if someone wants to contribute it, based on the assumption that it will be longer till the dialog can be replaced (and the work be obsolete), yes fine.
But if so, that would be a separate issue, because we would need to add a new option-storage for that, and an option to reset it.
   ...

Yep, it opens a whole can of worms on spec-making stage. The implementation would probably be not that hard, but spec-making... oooh...

And my recurring topic for you, is that questions even unresolved have their own merit, so thees notes of "problem that would arise if we go this way" better be written down in ome easy to stumble-upon place.

But again, we seem to both agree this nice-to-have would hardly be imlpemented, given few manhours we actually have for it.


Quote
Quote
(*) Run without debugger now, ask me again next time
I do like this one.

However, since we stroke out the previous negative option - then have a single negative option in the radiogroup does not look nice.

At this point, hence, least bad GUI design i see would be this option made into mrIgnore button, along OKAY and Cancel buttons. Maybe with custom caption, maybe even with vanilla one.

And RadioGroup only having actual debuginfo formats, hopefully filtered by target  and backend capabilities.

Another quesiton if there also should be a HELP button, launching user, for example, into that sticky forum thread, unleast something better made?
That would be polite thing to users. But that also would mean 4 buttonsin bottom panel, which feels a bit too many.

Then again, OK/CANCEL/IGNORE/HELP - are subset of standard LCL TButtonsPanel. Hopefully thet would have free i18n, free mantainance, etc

UPD. Ouch, there is no IGNORE button in the standard panel. There is CLOSE instead, and that sounds much less self-explanatory here.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 18, 2022, 03:18:13 pm
I wish LCL TStaticText could marry autosize and multi-line text (WordWrap) as JediVCL's one can...


That's a GUI propoisal, request for comments
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 12:29:06 am
Please make DWARF as an automatic format for windows, this will remove 99% of the views of this dialog

That is the (long term) plan. Just not sure when and how.

You can go to "project options", set one of the dwarf options, and check (bottom left corner) "save as default" => then all new projects will have the correct settings. Old projects that don't have them need to be updated once.

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 01:22:04 am
Quote
I don't know about that new MS dialog.... This isn't (currently) a restyle of the entire IDE (if it was, it would never be a hopefully quick-ish fix).
And I don't know if its style is fitting outside the Windows world. (maybe it is? no idea)

Ths shoots down the whole "extend generic dialog" idea :-)

Don't get that wrong, that is my opinion. I don't single handedly make all the decisions. There is team that I am part of.

So, I can get some feedback... But what next? If it would turn out acceptable from a design point, there needs to be an LCL implementation for all platforms. Who will do that? And if there is code in another project, what are the licenses? ....

Quote
And my recurring topic for you, is that questions even unresolved have their own merit, so thees notes of "problem that would arise if we go this way" better be written down in ome easy to stumble-upon place.
In an ideal word, I would agree...
In this world, in which there is way to often not even time to write down doc for existing things, it is not plausible to write down every detail on things that could exist or could be done. And also this would be on the off chance that out of the hundreds of things that I write down, maybe one day someone will pick ONE single item, and make use of the one (out of hundreds) docs.... Sorry, but no.
Yes, it is a good idea to invest into getting new contributors, but this way is a very bad investment.

People have in the past contributed. And when they start to prove that they are serious (e.g. by showing they read existing code) they have received plenty of help. And if you look to https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39880 => I did provide details on the implementation. (Sorry not going to re-enter that discussion for the sake of the discussion itself / I pointed do a concrete way how it can be solved. If there is code produced and shown to attempt it that way, and issues arise, then their is a base for further talk)

I joined the project to write code for certain features. I am nowadays doing way more than that. But it's still my spare time. I set the limits of how far I go.

Quote
RadioGroup
A listbox might be look well too. It may be closer to the MS-dialog, since the entire selected row is highlighted.
On the other hand it isn't common for that kind of dialog...

Maybe others can opine....

Anyway the kind of control is easily exchangeable.

Quote
Another quesiton if there also should be a HELP button, launching user, for example, into that sticky forum thread, unleast something better made?
It would have to be the wiki.

Initially I thought "if nothing else in the IDE has them..." But actually some forms do. So, help button is fine.

There is a "help system" in the IDE, and a file with all the links in the docs folder.
The help button has to use that existing system.

ide\codetemplatesdlg.pas
LazarusHelp.ShowHelpForIDEControl(Self);

Quote
I wish LCL TStaticText could marry autosize and multi-line text (WordWrap) as JediVCL's one can...
Don't label do?


About the proposed form.

There is a bit of feedback I am waiting for.... But in the meantime, from my opinion:

"Please choose ... otherwise it will run without debugger"
That paragraph should go.

There can be a radio for "run without", but a choice must be made, or it will "abort" / not run at all. (Hence no "Ignore" either)

And IMHO, the vertical spacing between the radio items it to much....




Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: 440bx on September 19, 2022, 05:32:18 am
I joined the project to write code for certain features. I am nowadays doing way more than that. But it's still my spare time. I set the limits of how far I go.
and thank you for that.  I am quite sure I am not the only one who appreciates it and is thankful for your efforts.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: zamtmn on September 19, 2022, 09:51:43 am
>>And i think those dialogs do work in FPC/LCL today.

It include in LCL see  lazarus\lcl\lcltaskdialog.pas
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 01:20:02 pm
>>And i think those dialogs do work in FPC/LCL today.

It include in LCL see  lazarus\lcl\lcltaskdialog.pas

Cool, so then that can be used.
It's radio too, but ok.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: PascalDragon on September 19, 2022, 01:29:25 pm
>>And i think those dialogs do work in FPC/LCL today.

It include in LCL see  lazarus\lcl\lcltaskdialog.pas

To be precise it's available as TTaskDialog in unit Dialogs. Unit LCLTaskDialog contains the low level implementation.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 01:31:34 pm
Quote
Ths shoots down the whole "extend generic dialog" idea :-)

Don't get that wrong, that is my opinion. I don't single handedly make all the decisions. There is team that I am part of.

Okay, let me be verbose then
.
This idea is too general for the scope of this topic, enhancing debugger GUI. So in the context of this thread - it is dead on arrival.

By "standard generic dialogs" you probably meant  CreateMessageDialog and friends.
https://lazarus-ccr.sourceforge.io/docs/lcl/dialogs/createmessagedialog.html

They were borrowed from Delphi, and they have a pretty standard layout that dozens of programs are using for decades.
Changing their layout - and doing so departing from Delphi's behavior and from expectations of all the lagayc rpojects developers - is not an easy step. It can not be made in the "enhance debugger" thread.

Maybe the team as whole would decide to re-style LCL and IDE, maybe not, but it is out of this scope.

For the purpose of this topic, and change in standard dialogs is change of style we can not do on our own, and for the narrow purpose of this topic - that idea is dead.

---

...there needs to be an LCL implementation for all platforms.

The project used stock VCL controls to implement it on non-Vista systems, i believe it uses stock LCL controls now. Otherwise why have {$ifdef FPC} inside.
But if you really want to spend toyr time - you can download that unit and check yourself. I think it was a stand-alone one and could work without reest of mORMot lib, or at least without most of it.
The license was Mozilla or LGPL or something.


Quote
And my recurring topic for you, is that questions even unresolved have their own merit, so thees notes of "problem that would arise if we go this way" better be written down in ome easy to stumble-upon place.
In an ideal word, I would agree...
In this world, in which there is way to often not even time to write down doc for existing things...
I did provide details on the implementation...
[/quote]

And i re-iterate too. I do not say "make new texts", i say may the texts you ALREADY wrote here and there persist, don't make the effort you spent writign extensive explanations in forum or tracker potentially get wasted, as geological residue. That was always my point, not "make new docs" but "make sure the quasi-docs you already made will float"

Quote
I joined the project to write code for certain features. I am nowadays doing way more than that.

That's how it happens. When RxLib died they officially donated to JediVCL, so i learned of it. I tried it on my Delphi 5 - and despite docs it did not work that well. I went their NNTP forum - and they said "ooops, bug in documentation. None of thus have D5 and it is no more supported". And i was like "NOOOO! don't!!!" - and then it was several years of my doing that "don't" :-)

Quote
Quote
RadioGroup
A listbox might be look well too. It may be closer to the MS-dialog, since the entire selected row is highlighted.

styling a la MS-dialog is not the goal as of yet.  And RadioButtons convay "you can select only one" much better than more generic listview


Quote
Quote
Another quesiton if there also should be a HELP button, launching user, for example, into that sticky forum thread, unleast something better made?
Initially I thought "if nothing else in the IDE has them..." But actually some forms do. So, help button is fine.

But where the Help button has to be then? I do not remember those windows, i just was mimicking LCL TButton Panel

Quote
Quote
I wish LCL TStaticText could marry autosize and multi-line text (WordWrap) as JediVCL's one can...
Don't label do?

I'll check later, indeed. I put the StaticText as i was expecting to use its built-in borders. But i did not in the end, so no reason not to change it to simple TLabel indeed.

Quote
from my opinion:

"Please choose ... otherwise it will run without debugger"
That paragraph should go.

The top banner is... verbose indeed. But there still would be a need to make it clear to novices what they are expected of, and what they can expect

Quote
There can be a radio for "run without", but a choice must be made, or it will "abort" / not run at all. (Hence no "Ignore" either)

With this approach i don't like that the sole negative option would get mixed in positive options and would be visually indifferent form them.
You won't believe, i was even thinking about patching TRadioGroup, so it would treat an empty line as a command to insert visual separation rather than an anonymous button.

With horizontal menu there is "from now on - stick to the right window edge" flag. I want something similar then between positive and negative actions.

We can drop RadioGroup and instead use a panel and create checkboxes in runtime instead, but then we would loose simplicity of "Anyway the kind of control is easily exchangeable." and the lingua franka of populating formats  via "Control.TStrings.Assign(source.TStrings)"

It can be reimplemented adding a TStrings property to the form, but the boilerplate would be significant. Maybe it would be worth doing after finalizing design, but not before.

Alternatively "Run without debugger this time" can be a checkbox below the radiogroup...

Sweet thing about removing Ignore button is that TButtonPanel cna be used then

Quote
And IMHO, the vertical spacing between the radio items it to much....

I want to make this dialog generic, so it would not be pixel-sized to have exactly 4 lines in the radiogroup. I expect it to be reused by all debugger back-ends, in that "intersection of sets" fashion.

I also do not want to implement elaborate auto-sizing for it. I am not sure i just can set AutoSize to the RadioGroup and to the form - and it would be automagic on all the platforms and all the font sizes. At least in Delphi autosizing rarely works reliably.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 01:54:15 pm

Well, lets conclude it.

- TTaskDialog is fine.
- all captions from resource strings (check how other dialogs do it)
- I accept radio buttons on it.
- Help button is fine (normal layout, I pointed you to how to implement it in code / see menu: Tools > Code Templates)
   (Ctrl-Shift-F1 while the dialog is active, and you can edit the http link)

"run without debugging" can be added, when a solution is found. Assigning it to something like "ignore" will certainly go wrong. Too many people will expect that this would still work as debug, because they didn't read the text. So it must be a more explicit choice.

You can find the current implementation the same way I would: search for the button text (it's a resource string), then search the resource string identifier, and you will find were the dialog is called.

So will you do it / and make a git merge-or-pull request (based on current 2.3) of it?

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 01:58:34 pm
Just got some feedback. The current one click is seen as desirable.

So maybe use the vertical stacked buttons in the task dialog (not sure, some combination of the flags should get you this... / I've seen while checking out the component, but didn't take note of the settings)
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 02:05:01 pm
Okay... At least inside the IDE on Windows with default fonts autosizing seem to work. Not sure about runtime and other environmemt conditions.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 02:14:55 pm
Just to reiterate ....
Eventually this dialog may be removed, or changed entirely (i.e. not looks, but functionality).

But until then, ok.


Background...
Not only is the current solution unfriendly (as suggested by this very topic)....

==> The current solution is broken <==
As in it may limit functionality (though with current FPC, most platform will be ok-ish)

The dialog only affects project settings. But not packages. So, if fpc for some platform still does stabs (unlikely), then there is no debugging into packages. And if it does use a lower dwarf version, then the debug-quality may suffer.
However this isn't a quick fix thing. If people have projects with different debug info, then it must still work each time they change project. Yet if packages are set to either one of the settings, then what would change them... Currently: nothing. So that needs a new approach. Adaptations to the settings and build system. And then that breaks how the Makefiles work, .... But some people need the exact pre-build ppu from the installer. So we can't just break that.... I don't remember the whole tail of issues that there is, I have to start digging myself (but not now).....
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 02:20:54 pm
Okay... At least inside the IDE on Windows with default fonts autosizing seem to work. Not sure about runtime and other environmemt conditions.

Nice, but (as of the feedback I collected) it has to be "one click buttons"

TTaskDialog can do them vertically stacked. (TODO: check on non Windows)
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 02:21:45 pm
- TTaskDialog is fine.
- Help button is fine (normal layout, I pointed you to how to implement it in code / see menu: Tools > Code Templates)
   (Ctrl-Shift-F1 while the dialog is active, and you can edit the http link)

Would look into it, but as of now i fear those points would be mutually exclusive. TaskDialog makes their own standard layout. If we go TaskBar - then actually all the talks below about fine details of custom layout are moot. That is either "generic" or "custom".

Quote
Too many people .... didn't read the text
Quote
The current one click is seen as desirable.

Again, mutually exclusive.

In my book RadioGroup (with -1 itemindex) has the advantage that it DOES NOT allow single click, so it INCITES people to read the text.
Also, the fact that this dialog is only shown once per project makes need to do two clicks and a bit of thinking less of penalty IMHO.

Would this dialog be obsessively popping up on every run i'd maybe think differently. But here we want to make the user fix the project settings, not mindlessly speed-click next-next-next-finish.

But anyway, the decision is to be made. Either we consider "user's don't read" a problem to try to overcome, or we consider it virtue to be benefitted from.
The latter suggests "single click" design.
The former suggests "non-initializes radio-group forcing two clicks click"

Alternatively, you may select some "all-round" format to be always pre-selected, like asked by zamtmn
I am not sure how this "default format" should be marked in the API though.
But if it is, then we have both radio-group AND single-click (or, rather, just tap ENTER on keyboard).

Again, if the generic TaskDialog aproach gets decided upon, then this fine-tuning is moot.

Quote
You can find the current implementation the same way I would: search for the button text (it's a resource string), then search the resource string identifier, and you will find were the dialog is called.

I'll see if i can, but agreed upon design first, implementation attempts later.

If i do, i would do it agaisnt Fixes_2_2 then cherry pick it into Main, as i did with TCheckBox patches
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 02:40:09 pm

Quote
Too many people .... didn't read the text
Quote
The current one click is seen as desirable.

Again, mutually exclusive.


"run without debugging" can be added, when a solution is found. Assigning it to something like "ignore" will certainly go wrong. Too many people will expect that this would still work as debug, because they didn't read the text. So it must be a more explicit choice.
Context.... Talking about an "Ignore" button doing something you would not know if you had not read some text somewhere else on the form.

Having vertically stacked buttons (one click), one of them can have "run without debugging" as caption.
Reading the caption is different from reading some text somewhere...



Will answer the rest asap.

Still checking out some radio vs button stuff
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 03:05:17 pm
Attached is a quick draft of radio-buttons based TaskDialog in Delphi XE2

A good brief article wih examples is at https://specials.rejbrand.se/TTaskDialog/

1. No help button can be made. Microsoft intends HTML hyper-links to be used instead. I am not sure if it would be easy to make a "custom hyperlink", triggering some action inside Lazarus (launching LHelp) rather than launching browser. There should be some way, but it needs investigation. Delphi has it, but Lazarus does not seem to have.

Meanwhile, as there is no LHelp topics for this dialog - it is moot point yet. But it might become important later if the dialog is chosen as a "strategic path"

Actually, in Delphi even standard http hyperlinks would only run through the event, and would do nothign without events. So i have doubts if in Lazarus tfEnableHyperlinks would do anything at all, except for vidual decorations of text

2. In Delphi you can assign integer Help Context and it would be used if the user striked F1 key. Still, no visual Help button.

Lazarus stock dialog misses that property, so probably no reaction to F1 is possible. But given no visual button it is not big miss.

Not sure about mORMot implementation.

3. There are more things present in Delphi XE2 but lacking in Lazarus.

3.1 The custom buttons in Delphi (used for "Run with no debug") can be enabled or disabled, in Lazarus they are always enabled.
3.2 There is only one event, OnButtonClicked, in Lazarus. There are MANY events in Windows/Delphi

In particular, there is "OnHyperlinkClicked" event, that provides for custom links implementation (thus, linking the dialog into LHelp). Lazarus lacks it.

Delphi does not document those events though https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Dialogs.TTaskDialog_Events
Most are obvious by their names, but OnNavigated is a puzzle....

The LCL documentation is at https://wiki.freepascal.org/TTaskDialog - i can't help noticing how weridly was checkbox positioned there... Glaly, if the debugger interface would be decided to be TaskDialog - there is no need for the checkbox.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 03:17:03 pm
The same dialog from Lazarus

Sadly, it is true, hyperlinks just do not work, they only show blue text, and that's it.

Code: Pascal  [Select][+][-]
  1. object dlgDWARF: TTaskDialog
  2.   Buttons = <  
  3.     item
  4.       Caption = 'Run with no debugger'
  5.       ModalResult = 100
  6.     end>
  7.   Caption = 'Running your application with debugger'
  8.   Flags = [tfEnableHyperlinks, tfAllowDialogCancellation]
  9.   FooterIcon = tdiInformation
  10.   FooterText = 'This choice can be later changed in Project Options / Compiler Options / Debugging window.'
  11.   MainIcon = tdiWarning
  12.   RadioButtons = <  
  13.     item
  14.       Caption = 'DebugInfo Format #1'
  15.     end  
  16.     item
  17.       Caption = 'DebugInfo Format #2'
  18.     end  
  19.     item
  20.       Caption = 'DebugInfo Format #3'
  21.     end  
  22.     item
  23.       Caption = 'DebugInfo Format #4'
  24.     end>
  25.   Text = 'Debugger can only run your application when it was compiled with Debug Information enabled. <a href="https://forum.lazarus.freepascal.org/index.php/topic,58745.0.html">Click here for more info.</a>'
  26.   Title = 'Choose Debug Information format'
  27.   Left = 493
  28.   Top = 454
  29. end
  30.  
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Josh on September 19, 2022, 03:28:41 pm
Whichever is used, i think it should display text explaining advantages/dissadvantage of each option...

Also a bug i think, create new project, run it, asks you which debugger, choose whatever to start the app, close the app, now go project options and create release/debug modes.
compile/run for release build, your asked again which debugger to use, even though debugger is deactivated in project options,

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 03:42:12 pm
Whichever is used, i think it should display text explaining advantages/dissadvantage of each option...

Unrealistic. You can not stick a short article into a confirmation dialog. The essense of the dialog would be lost between walls of text.

I agree that a choice without information is confusing, but such an information certainly belongs to documentaiton, not dialog.

Also, as Martin is working on backends the set of cons and pros is probably not fixed in stone but is being changed. Fixing it in the Lazarus sources then would maybe be worse, than haveing it in everchangiing wiki.

---------------------

Martin, at this point i do not think i can be of further help. At least yet.

I pointed to the TaskDialog (mORMot, but turned out LCL had a stock one), i also outlined some custom designs and outlined the reasons i believe important to put into this design. Everyone perhaps need to "sleep over with those ideas".

If task dialog gets okayed - then you have pre-set component above, copy-paste it into the form or make Pascal sources ouf of it, both are trivial. The lack of reaction to hyperlinks is problematic, but the current DWARF dialog does not have it either, so you miss nothing.

If anyone gets interested to evaluate their code and maybe copy it into LCL, then
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.pas - "licensed under a MPL/GPL/LGPL tri-license; version 1.18"
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.rc


If the task dialog gets rejected and custom window is demanded instead, then we can return to it then. Albeit i feel that plumbing any pre-designed and okayed dialog would be trivial still, so you would spend less effort just throwing it in than the probably back-and-forth with my patches until i would fully capture your vision. It is possible, but i sincerely believe what is left would be simpler for you just to kick it into Lazarus than kick it into my head.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 04:03:29 pm

Nice, but (as of the feedback I collected) it has to be "one click buttons"

TTaskDialog can do them vertically stacked. (TODO: check on non Windows)

See setting the tfUseCommandLinks flag (in Flags) - and probably remove the tfAllowDialogCancellation flag then. Also Make the CommmonButtons an empty set then

Below is the Dialog in Delphi (sorry, but usabiltiy does make difference (https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39919)) with tfUseCommandLinks and the rest was the same.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 04:09:12 pm
Offoptic, but

Unless you save yourself a new project template, and then it only shows, if you disable dwarf for your project.

I fear that checkbox mightily.

I would want to only make one specific setting default, and the chckbox would dump dozens and dozens of them instead.
Or so it looks.

I would not touch that checkbox with a flagpole, probably.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 06:51:39 pm
The latest looks ok to me.

I think a radio button should be pre-selected (a preference could be derived from the backend)

This would also solve, that not all people are sure what to select.
And as a side effect keep it one-click for the default.

--------------
The "ok" button may better be called "run / debug" if it is next to a "run without debug"

-- OR --
maybe the "run without" can be moved into the "buttons" list, and then (with the correct flags set / useCmdLinks) be a button in the main part of the form, separate from the normal flow (a separation you mentioned yourself).
Doesn't look too good... I haven't worked out the styling between the various flags across OS....
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 07:42:03 pm
no Martin, they meant that that all RadioButtons had to be removed, and inserted as Buttons insetad (AKA CommandButtons)

i believe one-click is BAD goal, but whatever

at least in Delphi you also would have to include tfUseCommandLinks flag, otherwise you would again end with a smimilar ultra-wide kind of dialog we started with

also, like said above, ControlButtons had to be empty set

but the biggest issue for now i believe would be inability to link to Help because LCL TaskDialog did not implemented events but one.

while you can implement it i believe it would be re-inventing the wheel and the better course would be to find a better implementation. Hopefully mORMot, coming from Windows, did more complete implementatoin, and given compatiblie license (hopefully) they can be asked to donate.

Here is XE2 component copied, but converting clipboard DFM to LFM or to Pascal source shold not be hard

Code: Pascal  [Select][+][-]
  1. object TaskDialog1: TTaskDialog
  2.   Buttons = <
  3.     item
  4.       Caption = 'DebugInfo Format #1'
  5.       ModalResult = 201
  6.     end
  7.     item
  8.       Caption = 'DebugInfo Format #2'
  9.       ModalResult = 202
  10.     end
  11.     item
  12.       Caption = 'DebugInfo Format #2'
  13.       ModalResult = 203
  14.     end
  15.     item
  16.       Caption = 'DebugInfo Format #4'
  17.       ModalResult = 204
  18.     end
  19.     item
  20.       Caption = 'Run with no debugger'
  21.       CommandLinkHint =
  22.         'If you continue running without Debug Info selected - the debugg' +
  23.         'er would not be enabled, and this question would reappear next t' +
  24.         'ime you run your application.'
  25.       ModalResult = 100
  26.     end>
  27.   Caption = 'Running your application with debugger'
  28.   CommonButtons = []
  29.   Flags = [tfEnableHyperlinks, tfNoDefaultRadioButton, tfUseCommandLinks]
  30.   FooterIcon = 3
  31.   FooterText =
  32.     'This choice can be later changed in Project Options / Compiler O' +
  33.     'ptions / Debugging window.'
  34.   HelpContext = 10
  35.   MainIcon = 1
  36.   RadioButtons = <>
  37.   Text =
  38.     'Debugger can only run your application when it was compiled with' +
  39.     ' Debug Information enabled. <a href="https://forum.lazarus.freep' +
  40.     'ascal.org/index.php/topic,58745.0.html">Click here for more info' +
  41.     '.</a>'
  42.   Title = 'Choose Debug Information format'
  43.   Left = 504
  44.   Top = 272
  45. end
  46.  

As for pre-selecting radio-button i don't mean this is on the table.

1) it would require serious rework of infrastructure to communicate the available choices and the best choices ot the dialog.
In short term - that is not there. We can just do fast drop-in replacement to what is there already.

Frankly, once-click vertical-aligned pushbutotns-only dialog is as close to drop-in  as possible.  In this your team peers are spot on.

2) and when you do - in long term - this dialog would probably be no more needed and be removed

zamtmn does have a point. If Lazarus does know what thebest choice is - do not preselect the radiobutton, just update project options and do not bug novices
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 08:25:18 pm
You can mix the button and the radio

Either

- radios for various debug info / default selected
- button (in main part of dlg)for without debug

OR
- radios for various debug info / default selected
- run without in the button panel, but "run / debug" instead of "ok"

Just making sure the main action to run with the debug info is not put into shadows by a more visible "run without dbg" button next to it.

---
It was established the help button can be used....


Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 08:49:45 pm
You can mix the button and the radio
Just making sure the main action to run with the debug info is not put into shadows by a more visible "run without dbg" button next to it.

I believe the mixed dialog at https://forum.lazarus.freepascal.org/index.php/topic,60624.msg454194.html#msg454194
is exactly th example how button overshadows radiobuttons, and it can not be helped

i believe it is wasting effort now

- You team peers believe in one-push approach,
- the existing right now infrasturcture does not provide for pre-selectin (or does it ?)
- after the infrastructure get evolved and generalized - there is big chance this dialog would be outright removed

So, make the simplest possible drop-in with array of vertical "command buttons" and with no "OK" and 'Cancel" buttons at all in the low panel of standard buttons. Okay, maybe with a single "Abort" button doesn there.

It is fast, simple, fits as drop-in replacement, and is what your peers prefer. Seems a bingo.

Would anyone ever provide help to the dialog, before this dialog removed at all? Then he would patch TTaskDialog to have it, or would take more developed component.

Quote
It was established the help button can be used....

What it means? You were given green light to add it? Or you were promiced it can be added ?

There is NO such "CommonButton", everyone went Internet and Microsoft discarded it, instead urging to provide hyperlinks.  Twice so since you can have only one Help button but multiple links.

You can add custom Command Button indeed - but... Then it still will close the dialog EVEN if you set zero ModalResult.
Non-modal buttons in modal dialogs are considered harmful :-D And honestly, MS has a point here.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 08:53:00 pm
or just re-enable closing the dialog with Esc or [ X ] - and that would be your "abort" options.

Include( Flags, tfAllowDialogCancellation )

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 09:08:13 pm
You can mix the button and the radio
Just making sure the main action to run with the debug info is not put into shadows by a more visible "run without dbg" button next to it.

I believe the mixed dialog at https://forum.lazarus.freepascal.org/index.php/topic,60624.msg454194.html#msg454194
is exactly th example how button overshadows radiobuttons, and it can not be helped
yes, sorry I missed we had that before. Looks good.


Quote
i believe it is wasting effort now

- You team peers believe in one-push approach,
- the existing right now infrasturcture does not provide for pre-selectin (or does it ?)
- after the infrastructure get evolved and generalized - there is big chance this dialog would be outright removed
It will be
- 1 new enum (listing the options)
- about 5 lines of code per backend (and some backends inherit, and don't need it)
  (if the backend has requirements / currently 2 of them)
- virtual in the base class

1) procedure declaration
2) procedure in implementation
3) begin
4) the value
5) end

Between 30 seconds and a minute per backend.

Have you looked at the current code calling the dialog, and where it gets the list from?

Code: Pascal  [Select][+][-]
  1. class function TFpDebugDebugger.RequiredCompilerOpts(ATargetCPU, ATargetOS: String): TDebugCompilerRequirements;
  2.  

Quote
Quote
It was established the help button can be used....

What it means? You were given green light to add it? Or you were promiced it can be added ?

It already exist in some dialogs, so its not a new concept, so it can be used here too.

Invoking help is done by the single line of code, I posted earlier.

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 09:28:56 pm
Between 30 seconds and a minute per backend.

Have you looked at the current code calling the dialog, and where it gets the list from?

It already exist in some dialogs, so its not a new concept, so it can be used here too.

1. Ok, good if it is so. Rehash API and we'll see.

Sad point, i tried to cherry-pick your commits into Fixes_2_2 and got conflicts... Maybe because my Fixes_2_2 is dirty

2. No, like i said, fixing design first. I do not want to make elaborate work only for it to be discarded and said to be not-Lazarish. One time is enough. Agreement on design first, implementing later.
Besides i spent fair deal of braincells and time on LCL today debugging ActiveX failure (https://forum.lazarus.freepascal.org/index.php/topic,60606.msg454212/topicseen.html) with undocumented library.

3. The concept is not new, but it was deliberately removed from MS TaskDialog.
So, we are back to square one - either drop TaskDialog and design custom window, or drop Help button, that never was there to start with.

Personally i believe hyperlink is no worse to the button,  but LCL does not have them either. The sources clearly show they did not implement tdfEnableHyperLinks - it just is included to execute Delphi code unchanged, but does not work.

So, neither Help button nor hyperlinks in the task dialog.
If you need them - then make custom window instead.

P.S.  ...i should just had looked into LCL, lol

Code: Pascal  [Select][+][-]
  1.  
  2.  
  3. unit LCLTaskDialog;
  4.  
  5. {                            LCLTaskDialog.pas
  6.                             -----------------
  7.  
  8.  Implement TaskDialog window (native on Vista/Seven, emulated on XP).
  9.  This unit was originally a part of the freeware Synopse mORMot framework,
  10.  licensed under a MPL/GPL/LGPL tri-license; version 1.19.
  11.  
  12.     Synopse framework. Copyright (C) 2016 Arnaud Bouchez
  13.       Synopse Informatique - http://synopse.info
  14.  
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 09:33:52 pm
It seems some of the discussed items are going in cycles now.

So maybe there are misunderstandings? If I did lack clarity somewhere then I am sorry for that.
Also to point out: Some of my later statements included (implied) withdrawals of prior questioning of ideas.

Also apparently for some items the separation of their context to the context of other items in the message where I introduced them (or even other messages), may not have been made clear enough. E.g. the question of the help button had been made based on the expressed assumption of mine that such a help button would be a new concept and was not yet present anywhere. I then found my assumption wrong (i.e., help buttons are already in use) and hence withdraw my concerns. The context of checking with the team had been as mentioned based on this being a fundamentally new concept, and that even though not explicitly mentioned had been discovered not to be the case. Again, sorry about this.



So to remove any doubt:

This https://forum.lazarus.freepascal.org/index.php/topic,60624.msg454194.html#msg454194
=> radio + one embedded "link button" for "run without dbg"

With the addition that one radio must be preselected.

The link to become a help button.

Is 100% ok.

I will merge/apply this.
No backsies on this.

As mentioned all captions must be initialized from resource strings (IIRC unit LazarusIdeStringConst)



I also stand by my prior word, that for this one patch/merge-request I will accept it against fixes branch, if it can be cherry picked to main without major merge conflicts. (tree conflicts/ chunks of more than a dozen lines conflicting)
It will very most likely only appear in the main branch.

I am happy to assist further with the help system, or the new debugger procedure, as soon as I see a first patch against actual IDE code (I.e. not just the form, but IDE code actually creating/calling that form.)


Hope that covers it.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 19, 2022, 09:42:50 pm
overlapped with my previous post...

Sad point, i tried to cherry-pick your commits into Fixes_2_2 and got conflicts... Maybe because my Fixes_2_2 is dirty

Which commits? And cherry pick to where?
Normally all commits in fixes are in main, and where picked from there.


Quote
2. No, like i said, fixing design first. I do not want to make elaborate work only for it to be discarded and said to be not-Lazarish. One time is enough. Agreement on design first, implementing later.
Ok, then simply set the first radio to be the default.

Quote
3. The concept is not new, but it was deliberately removed from MS TaskDialog.
So, we are back to square one - either drop TaskDialog and design custom window, or drop Help button, that never was there to start with.
Ok here we have miscommunication.
I am missing completely what you mean?

Which concept?
And are we talking about the TTaskDialog in the LCL? (Which I hope (not tested) to work on all platforms....)
Or something else?


Quote
So, neither Help button nor hyperlinks in the task dialog.
If you need them - then make custom window instead.
Try a button and tfUseCommandLinks  with the LCL control.
At least on Windows that shows radios, and a flat-button-like




It seems the main missing issue is, that no one checked yet what will happen on other OS.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 19, 2022, 10:03:19 pm
Which commits? And cherry pick to where?

i'll check tomorrow on vanilla Fixes_2_2, mine is polluted currently

Quote
Normally all commits in fixes are in main, and where picked from there.

I am not Lazarus hacker, not yet at least. I am user who contributes when he can.

Quote
Quote
3. The concept is not new, but it was deliberately removed from MS TaskDialog.
So, we are back to square one - either drop TaskDialog and design custom window, or drop Help button, that never was there to start with.
Ok here we have miscommunication.
I am missing completely what you mean?

Which concept?

concept of having non-modal HELP button in an otherwise modal TTaskDialog.

ANY button would close the dialog, even if ModalResult = 0

Quote
And are we talking about the TTaskDialog in the LCL? (Which I hope (not tested) to work on all platforms....)

Both. VCL dialog is wrapper over Windows Vista API
LCL dialog is wrapper over Vista API when it present, and re-imlpementation of SUBSET of Windows API otherwise.

This means, on Windows LCL dialog would look exactly as VCL or any other Windows-native.
BUT will miss some behavior functonality.

The pieces that mORMot did not re-implement in cross-platform way - they did not expose in API.

In particular that is hyperclick link - yes it is RENDERED on Windows, but it has noi any aciton to it, because LCL TTaskDialog did not implement the required events in x-platform way.
And implementing it in x-platform way would require limited HTML rendered inside LCL. Which would not happen soon.

So,

- non-closing HELP button would not be in Taks Dialog, because Microsoft deliberately precludes it.
- Hyperlink would not work in LCL TaskDialog, because it is not implemented.
- Even if hyperlink worked on Windows alone - it still would not be usable on non-Windows, so could not be relied upon
- Now, you can do a dirty trick: add the Help button, that would close dialog and then immediately show it again

Code: Pascal  [Select][+][-]
  1. Choice: TModalResult;
  2.  
  3. repeat
  4.    Choice := TaskDialog1.Execute();
  5.    if Choice <> mrHelp then exit;
  6.    // command to show LHelp or WWW help
  7. until false;

Would you want SUCH a hack?

If not - you have a binary choice.

Either give up on TTaskDialog, or give-up on help (button or hyperlink - both don't work) in the task dialog.
This - or that.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 12:32:23 am
All in all, if you want to extend TTaskDialog to make it x-platform - that is a noble goal, but i believe it is outside FpDebug scope.
Let's create a separate thread and talk there.

The immediate things would be

- reach Arnaud and ask if they gave up on Task Dialog or not. Is mORMot TaskDialog upstream or LCL is ? PErsonally i'd rather hack on mORMot with its Delphi compatibility, than FPC-only LCL. But in the end it is about "who is upstream now".

- persuade LCL team to include any simple fast HTML renderer into the core. We did not have to have fast and flexible solution, like thta commercial Delphi HTML components. We probaly would not even need as much as THtmlFrame. But ascending JediVCL HTML Label or something of equaly complexity would be called for.

D:\fpcupdeluxe\ccr\jvcl\run\JvCtrls\jvhtcontrols.pas
D:\fpcupdeluxe\ccr\jvcl\run\JvNet\jvhtmlparser.pas

Or anything similar. Google shows https://github.com/jackdp/DzHTMLText2 and https://laptrinhx.com/delphi-and-lazarus-html-label-component-4127787442/

Officially Microsoft only accepts HTML A-tag and nothing else. But implementing ad-hoc anchor-only parser, and then rendered to supplement it, should we really do it? https://learn.microsoft.com/en-us/windows/win32/api/commctrl/ns-commctrl-taskdialogconfig

This is probably worth doing, but the amount of time and energy to to make it ascend into LCL core would be.... substantial. Hence would be past the timeline you set to FPDebug enhancement. Albeit on its own merit that seems a worthy task.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 20, 2022, 02:09:07 am
Quote
Which concept?
concept of having non-modal HELP button in an otherwise modal TTaskDialog.

Code: Pascal  [Select][+][-]
  1. procedure TForm1.TaskDialog1ButtonClicked(Sender: TObject;
  2.   AModalResult: TModalResult; var ACanClose: Boolean);
  3. begin
  4. end;
  5.  
Looks promising.

Tested on Linux and Windows, it works.
Not tested on Windows (nor Mac)

The other Issue => there is no build in "help" button. => and if the custom buttons where to go up into the main area => then how to get a help button.
Also that means there would be no way for a "help" button on the left side, with all other buttons aligned towards the right side.

Or did I miss something.


Quote
Quote
And are we talking about the TTaskDialog in the LCL? (Which I hope (not tested) to work on all platforms....)

Both. VCL dialog is wrapper over Windows Vista API
LCL dialog is wrapper over Vista API when it present, and re-imlpementation of SUBSET of Windows API otherwise.

This means, on Windows LCL dialog would look exactly as VCL or any other Windows-native.
BUT will miss some behavior functonality.

Tested under Linux. Mostly ok.
Only the buttons (if tfUseCommandLinks*) is set,  will always be above the radios.

Not yet looked at MacOs.

Quote
All in all, if you want to extend TTaskDialog to make it x-platform - that is a noble goal, but i believe it is outside FpDebug scope.
It may already be... With tiny differences/limits...


Quote
- reach Arnaud and ask if they gave up on Task Dialog or not. Is mORMot TaskDialog upstream or LCL is ? PErsonally i'd rather hack on mORMot with its Delphi compatibility, than FPC-only LCL. But in the end it is about "who is upstream now".
Even if, that will be a hold back. And I wont be able to mediate all of that.
Lets see how far we can get with what is there. Then lets see what needs adding.


Quote
- persuade LCL team to include any simple fast HTML renderer into the core. We did not have to have fast and flexible solution, like thta commercial Delphi HTML components. We probaly would not even need as much as THtmlFrame. But ascending JediVCL HTML Label or something of equaly complexity would be called for.
There is one for the IDE hints ...IPro... package
But same as above.


That might mean to defer the Help button => but the initial goal to reduce the width would be reached.
Also: a run without debug.

And even if the pre-select is not smart to begin, that will be easy to add, and help the user with the choice.


// Tests for Mac assumed to succeed.

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: PascalDragon on September 20, 2022, 09:50:05 am
If anyone gets interested to evaluate their code and maybe copy it into LCL, then
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.pas - "licensed under a MPL/GPL/LGPL tri-license; version 1.18"
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.rc

Please note that this license is not compatible with the license used with the LCL cause the LCL uses LGPL-with-static-linking-exception, but mORMot uses the unmodified LGPL.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 11:42:02 am
If anyone gets interested to evaluate their code and maybe copy it into LCL, then
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.pas - "licensed under a MPL/GPL/LGPL tri-license; version 1.18"
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.rc

Please note that this license is not compatible with the license used with the LCL cause the LCL uses LGPL-with-static-linking-exception, but mORMot uses the unmodified LGPL.

Oh, way too many licenses out there...
But anyway, after i checked LCL sources belatedly, they already donated their to LCL. So, moot point from my part it was.

Now, i think TaskDialog talk here goes vicious circle.

Should LCL x-platformly re-implement missed HTML+hyperlinks funcitonality of TaskDialog? Maybe.But it is beyond FpDebug talk andis worth a separate backburner thread.

Should FPDebug use TaskDialog or custom one ? Depends whether adding "visible HELP button" functionality is required or "quick drop-in replacement" is preferred. Both are fine by me, but the choice has to be made by Team Lazarus.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 11:46:52 am
Quote
- persuade LCL team to include any simple fast HTML renderer into the core. We did not have to have fast and flexible solution, like thta commercial Delphi HTML components. We probaly would not even need as much as THtmlFrame. But ascending JediVCL HTML Label or something of equaly complexity would be called for.
There is one for the IDE hints ...IPro... package

"for the IDE" - irrelevant. TTaskDialog is for desktop user's apps, outside of IDE. Whatever new code TTaskDialog would use - would have to be moved to RTL/LCL/whatever core *runtime* packages end-user apps must use anyway.

The CanClose thing i missed, maybe indeed it can do

----

One more thing missed in LCL/mORMot rather that pure Win32 wrapper

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 12:03:46 pm
Default choice in "pushbutton" mode, native Win32, Delphi vs LCL

To me, Default rendering with CommandButtons is VERY faint, and is less pushy" then mere mouse-hover effect.
On the fence, whether that is good or bad thing.

Personally i am against default choices, so it is good.
But "pure one-click" solution would ask to get rid of radiobuttons at all and only use veritcally stacked pushbuttons, then "faint default" would be bad

Then again, the lack of extended hint in LCL is... disturbing.  I too kit for granted.
To me "Run no debug" without immediately visible extended hint seems a big loss.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: zamtmn on September 20, 2022, 12:25:26 pm
Arioch
Show how these dialogs will look in other widgesets. I'm afraid we will have a bad surprise((
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 01:05:29 pm
Arioch
Show how these dialogs will look in other widgesets. I'm afraid we will have a bad surprise((

i can not - https://forum.lazarus.freepascal.org/index.php/topic,60531.msg453747.html#msg453747

also, ATM i am more inclined to recall the TTaskDialog idea and rather do separately with short-term custom window for FPDebug immediate need and slow long term enhancement of TaskDialog for the "greater good"
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: wp on September 20, 2022, 03:46:49 pm
Show how these dialogs will look in other widgesets. I'm afraid we will have a bad surprise((
Played with the LCL TaskDialog and tried to create an adapted version of the screenshot in reply #27. Here's my result for Win11, Linux-Mint-gtk2, mac Mojave, and for comparison Delphi XE 10.4 (on Win 11). They are all pretty much the same (except for Delphi which does not have the option tdiQuestion for the FooterIcon). (The order of the OK and Cancel buttons (or all buttons?) should be reworked in the non-Windows version of the LCL Taskdialog).
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 20, 2022, 05:23:23 pm
also, ATM i am more inclined to recall the TTaskDialog idea and rather do separately with short-term custom window for FPDebug immediate need and slow long term enhancement of TaskDialog for the "greater good"

Sorry, but no.


I made a clear statement what will be accepted

So to remove any doubt:

This https://forum.lazarus.freepascal.org/index.php/topic,60624.msg454194.html#msg454194
=> radio + one embedded "link button" for "run without dbg"

With the addition that one radio must be preselected.

The link to become a help button.

Is 100% ok.

I will merge/apply this.
No backsies on this.

As mentioned all captions must be initialized from resource strings (IIRC unit LazarusIdeStringConst)



I also stand by my prior word, that for this one patch/merge-request I will accept it against fixes branch, if it can be cherry picked to main without major merge conflicts. (tree conflicts/ chunks of more than a dozen lines conflicting)
It will very most likely only appear in the main branch.

I am happy to assist further with the help system, or the new debugger procedure, as soon as I see a first patch against actual IDE code (I.e. not just the form, but IDE code actually creating/calling that form.)

Re-reading it: "The link to become a help button." refers to the "<a>" embedded link in the text.

I further stated:
2. No, like i said, fixing design first. I do not want to make elaborate work only for it to be discarded and said to be not-Lazarish. One time is enough. Agreement on design first, implementing later.
Ok, then simply set the first radio to be the default.




It seems the main missing issue is, that no one checked yet what will happen on other OS.

On the last point: If any part is not possible, leave it out for now. I have concrete ideas (based on the LCL TaskDialog) how to solve them. But I will not go there, before I do have code that can be successfully applied to the IDE.

For now (more than) enough options were explored: It is "whatever of the above is possible with the existing LCL TaskDialog" as first step.





Tested under Linux. Mostly ok.
Only the buttons (if tfUseCommandLinks*) is set,  will always be above the radios.



That might mean to defer the Help button => but the initial goal to reduce the width would be reached.
Also: a run without debug.

And even if the pre-select is not smart to begin, that will be easy to add, and help the user with the choice.


If a help button has to be deferred it goes into stage 2.

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 05:37:39 pm
Taskdialog itself: https://forum.lazarus.freepascal.org/index.php?topic=60652.new#ne
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 05:43:10 pm
I patched LCL to never use native API, even on Windows. I confirm the reversed opsitioning of command buttns vs radiobutotns.

https://forum.lazarus.freepascal.org/index.php?action=dlattach;topic=60652.0;attach=50880;image

The event hack to prevent closing on Hepl button works, so given this is pure-LCL button should work on every platform.

But the non-implementaiton of "command hints" (lesser, secondary button caption), makes warning user about non-closing behavior of Help impossible.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 20, 2022, 05:53:40 pm
As I said, I have ideas how to resolve that. But I wont bother writing them up, until I have code that runs in the IDE for those parts that do work (I.e just the radios...)
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 06:06:05 pm
Can you fix the radiobuttons vs common buttons placement ?

needs just swapping two if-blocks around.

can you apply to both main and Fixes_2_2 ?
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 20, 2022, 06:16:40 pm
It's based on one of the flags (use...links).

Can be done. Once their is a need. I.e. once there is code.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 06:19:45 pm
That being said,

1)  would you prefer

a) no push-button for Help at all (no help function at all)
b) Help Button 

2) positioning of buttons, horizontal or vertical ?

3) if vertical - with "arrow" pictures or without? I found no way to make pictures different.
IMHO "arrow" on help button reinforces wrong impression

4) if vertical, should "help" be the last (bottom) one, or go between radio-buttons and "run with no debug" ?
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 06:23:54 pm
It's based on one of the flags (use...links).

Can be done. Once their is a need. I.e. once there is code.

Guess you missed the point.

Compare three pictures, focus on radiobuttons and "big buttons". Which are top and which are below

Windows native (on the right) - https://forum.lazarus.freepascal.org/index.php?action=dlattach;topic=60624.0;attach=50866;image
Current LCL - https://forum.lazarus.freepascal.org/index.php?action=dlattach;topic=60624.0;attach=50882;image
After the patch - https://forum.lazarus.freepascal.org/index.php?action=dlattach;topic=60624.0;attach=50884;image

The implementation was wrong, flags don't fix it, only the patch (trivial, swapping two code blocks)
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 20, 2022, 06:43:51 pm
Once their is a need. I.e. once there is code.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 07:07:01 pm
oookay, then i go with the 1st variant, horizontal small buttons
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 20, 2022, 07:28:32 pm
oookay, then i go with the 1st variant, horizontal small buttons
Ok
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 07:29:02 pm
There is a "help system" in the IDE, and a file with all the links in the docs folder.
The help button has to use that existing system.

ide\codetemplatesdlg.pas
LazarusHelp.ShowHelpForIDEControl(Self);

This won't do....
There is no any control to call the help over.

The original code was
Code: Pascal  [Select][+][-]
  1.       case IDEQuestionDialog(lisEnableOptionDwarf,
  2.           Format(lisTheProjectDoesNotUseDwarf, [DebugClass.Caption]),
  3.           mtConfirmation, [1 {mrOk}, lisEnableOptionDwarf2Sets,
  4.                            12, lisEnableOptionDwarf2,
  5.                            13, lisEnableOptionDwarf3,
  6.                            mrCancel])
  7.  

Here is one more parameter const HelpKeyword: string = '') - unused

All the calls in D:\fpcupdeluxe\lazarus_deb\ide\main.pp also lack this parameter.  And rightfully so....

Code: Pascal  [Select][+][-]
  1. function QuestionDlg(const aCaption, aMsg: string; DlgType: TMsgDlgType;
  2.   Buttons: array of const; const HelpKeyword: string): TModalResult;
  3. begin
  4.   // TODO: handle HelpKeyword
  5.   Result := QuestionDlg(aCaption, aMsg, DlgType, Buttons, 0);
  6. end;

Basically, you just do not have it in IDE Help system to call help over some (potentially extensible) string ID


Can you debug CallStackDialog and find how it does open WWW wiki window?
Is there at  least some semi-official semi-unified way or a total ad hoc ?
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 07:54:08 pm
i am out for house chores for about an hour

meanwhile, i see no immediate way to make normal "run no debug info"


D:\fpcupdeluxe\lazarus_deb\ide\main.pp
function TMainIDE.DoInitProjectRun: TModalResult;

line 7319

tried to do

Code: Pascal  [Select][+][-]
  1.   // Setup debugger
  2.   if not SkipDebuggerThisTime then
  3.     if not DebugBoss.InitDebugger then begin
  4.       debugln(['Info: (lazarus) [TMainIDE.DoInitProjectRun] DebugBoss.InitDebugger failed']);
  5.       Exit;
  6.     end;
  7.  

But this causes IDE to throw error running debugger error and then stuch is some half-=responsive state (responses to mouse, etc - but can not exit and is stuck in "debugging..." state (ToolStatus := itDebugger;) - no exit from it)

Simplest way would be just to run debugger with incompatible debug info - but does not feel right

Probably i can hook into

Code: Pascal  [Select][+][-]
  1. function TMainIDE.DoRunProject: TModalResult;
  2. var
  3.   Handled: Boolean;
  4. begin
  5.   DebugLn('Hint: (lazarus) [TMainIDE.DoRunProject] INIT');
  6.  
  7.   if (DoInitProjectRun <> mrOK)
  8.   or (ToolStatus <> itDebugger)
  9.   then begin
  10.     Result := mrAbort;
  11.     Exit;
  12.   end;
  13.   debugln('Hint: (lazarus) [TMainIDE.DoRunProject] Debugger=',DbgSName(EnvironmentOptions.CurrentDebuggerClass));
  14.  

and make a custom mrResult code for it

this code anyway has ot be fixed, it is obviously wrong...

GUI-only patch attached
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 20, 2022, 07:55:59 pm
Well, I see.

For now directly call

unit HelpIntfs // LCL
function ShowHelpOrError(const URL, Title, MimeType: string  ): TShowHelpResult;


  ShowHelpOrError(URL,  'Help for debug info selection','text/html');

url: https://wiki.lazarus.freepascal.org/DWARF

In the end that is where the help system ends up.




Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 07:57:29 pm
...or not

Quote
D:\fpcupdeluxe\lazarus_deb\components\debuggerintf\dbgintfdebuggerbase.pp
components\debuggerintf\dbgintfdebuggerbase.pp (1948,44) See main.pp 12188 function TMainIDE.DoInitProjectRun: TModalResult;
D:\fpcupdeluxe\lazarus_deb\ide\debugmanager.pas
ide\debugmanager.pas (2671,15) if (MainIDE.DoInitProjectRun <> mrOK)
ide\debugmanager.pas (2686,15) if (MainIDE.DoInitProjectRun <> mrOK)
ide\debugmanager.pas (2701,15) if (MainIDE.DoInitProjectRun <> mrOK)
ide\debugmanager.pas (2718,15) if (MainIDE.DoInitProjectRun <> mrOK)
ide\debugmanager.pas (2741,15) if (MainIDE.DoInitProjectRun <> mrOK)
ide\debugmanager.pas (3091,15) if (MainIDE.DoInitProjectRun <> mrOK)
ide\debugmanager.pas (3135,15) if (MainIDE.DoInitProjectRun <> mrOK)

And they all seem equally broken  :-/
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 20, 2022, 08:06:38 pm
The first question is which places call DoInitRunProject.
Do they all want that option? I.e. Starting a project with "step in" (ignoring it does not work for FpDebug) => should it allow to run without debugger.
Let's say: yes (it does no harm).

The DoInitRunProject can call TMainIDE.DoRunProjectWithoutDebug and then exit + return mrCancel (mrNone since it differs from cancel / assuming all callers accept that).

Otherwise each relevant caller needs to be updated.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 10:40:44 pm
> The DoInitRunProject can call TMainIDE.DoRunProjectWithoutDebug and then exit

okay, perhaps it is a really easiest way

and in general there maybe has to be some ARC token (TInterfaced object, record with memory management handlers, etc)  so that user actions would make it flow across the IDE, including some compilation token, etc

each token then would have their destructor as a de facto cross-procedure finally-section

this realyl looks a stupid mistake...

Code: Pascal  [Select][+][-]
  1.   if (DoInitProjectRun <> mrOK)
  2.   or (ToolStatus <> itDebugger)
  3.   then begin
  4.     Result := mrAbort;
  5.     Exit;
  6.   end;

What is result was NOT mrOK, yet ToolStatus == itDebugger ?
We exit without resetting ToolStatus - and no one would ever do it, and user interface stuck in mostly disabled state? Looks like that...

----

there was a condition i suspectedm but did not have time to test. Patch is recalled
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 20, 2022, 11:12:08 pm
is DebugClass.Caption supposed to be localised? Should it even be included to user-level messages ? is so, why is it not included into compilation warning - texts much more techie than confirmation dialogs?

okay, updated patch here
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 20, 2022, 11:47:40 pm
The localization of DebugClass.Caption needs to be solved in each backend.

But yes it should be included. It refers to what debugger you have chosen (either in the IDE config or project config).

E.g. if the user things he setup to use the gdb based debugger and stabs, then the dialog would be confusing to him.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 21, 2022, 06:00:22 pm
Thanks,  I merged the patch:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/network/a4a24bc66bbd2630cdd353b5e9e6979d0dac2d6f

I did make the dialog a local var. No need to burden the class with it.


If you like, we can now look at other steps

- fix, that the dialog is also shown, when the debug-info is switched off entirely
- include the check/change for the "external info" flag

- Add, fetching the default  from the backend

- Add "help" to the footer buttons (like ok,cancel) - requires non-native dialog
  (allows to move "run without" up into the main part of the dlg)

---

Add a checkbox (as is avail in the dialog) to modify the "project template". So new projects will have the chosen setting too, and not show the dialog.
I would need to search myself, where that code is ....



As I saw you generated the patch from a git clone.

Ideally you can do further contribution based on the main branch? (There was a small merge conflict for this one...)
And maybe even have a fork and do pull or merge requests? (patches are fine too)




Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 21, 2022, 06:48:52 pm
Like i said, at least for today, i am Lazarus user not Lazarus hacker.

I am "eating my own dog food" and doing so hit my thumbs over things sticking out of Lazarus. Then i try to fix/report/workaround them.

This means i generally work with stable Lazarus, and if i want to look into some dusty corner, destabilizing it in process, i would do it in a limited, localized (as in locality, not locale) fashion.

You probably, over the course of years of your involvment, elaborated gut feeling which parts of Lazarus do what and how good. I don't have it. Trying to wrap my mind over some pieces inside LCL or IDe or FPC - i want to feel secure that all other parts are as stable as can be.

What future can bring - no one knows, up to WW3 and total sharding of once global internet to tightly secured blocks.

However, for now i am a user, of stable Lazarus, willing to contribute what i can and to extent i can, but not above it.

There is only so much of unstable, bleeding edge things one can handle. For now i think, erroneously or not, that Lazarus would be one too many for me.



> did make the dialog a local var. No need to burden the class with it.

i actually had a feeling you would do or demand it :-)

it is only a single pointer of a burden.
granted, the time penalty of creating/destroying is miniscule too.

i just did what i usually do, without having strong opinion about it

> - Add, fetching the default  from the backend

implement a generic API shared by all the back-ends, it should not be hard

however... i repeat my opinion that this qould call for removal of the dialog. If back-end knows which format to set - just do it.
If you feel uneasy about covert data changed - ask user a yes/no (or actually ok/abort) question.

i believe zamtmn was spot on here. If developer is newb - don't bug him with choices he can not make. The only think newbs need is a a single button "do me an all-round good". If developer is seasoned - inform him of the change done, or ask for permission to do. If he has opinion - he knows how to open and navigate Program Options. Both ways, this dialog is obsoleted as soon as back-end knows what it wants. It was a stopgap measure.

Well, maybe "apply default" / "cancel run" / "abort run and open Project Options" is the best possible choice for user.



> - include the check/change for the "external info" flag

this sounds a creeping featurism to me. We would end sucking in the whole Project Options / Debug panel. But it already exists.

Frankly, it feel like you grow more emotionally attached to this dialog than i was. This was always a stopgap before "debugging infrastructure knows better", which was the correct solution. If you implemented the latter, the dialog "outlived its usefulness".

> - fix, that the dialog is also shown, when the debug-info is switched off entirely

with the phrase like that i am always lost, what is (bad) observed behavior, and what is (good) goal.

is it that a dialog is shown and it should not be? or the opposite?

as for the correct design from user's perspective, i believe it should be this way:

1. The project starts with either undefined (NULL in SQL terms) back-end, or with "default" all-round good backend pre-selected. Again, if IDE knows what back-end and what format are soft spot for today - just use that knowledge. Laz devs know it, newb doesn't. Asking newb would bring nothing except F.U.D.
2. The explicit "no debug info" either is different state than "undefined", or there is no "undefined" at all (the new project always pre-selects most good format and back-end)
3. there can be however a case, when there was a good match of info format and backend, then the user changed back-end, and the new back-end can not consume the priorly selected format. THAT is the case i believe the prompt is warranted.
4. when a "no debug info" was explicitly selected - the correct behavior would be not to show a prompt, but to make debug-related funcitons fidabled in IDE

Well, here is when you can throw "don't bother newbs" back at me.
VCL (and probably LCL) does not provide for making a control disabled, yet with explanation WHY disabled. Even .ShowHint in VCL is ignored on disabled controls.

Still my gut feeling is that having "Run with debug" "Step in" and similar actions diabled would be better choice.



did you notice how we are sliding into spec-making, BTW ? oh, okay, techwriting sucks, i know :-)

Quote
Add "help" to the footer buttons (like ok,cancel) - requires non-native dialog

No it does not.

I always did screenshots from the same Windows machine, and it rendered all four horizontal buttons (help, run no debug, ok, cancel) in native Win7 dialog.

Quote
  (allows to move "run without" up into the main part of the dlg)

Now this IS impossible, but it is a different thing.
It seems exactly what i asked about yesterday, in the post wit hthree screenshots. « on: 2022-09-20, 18:19:45 » - refresh those questions and screenshots please.

TaskDialog operates either in "command buttons" mode or not.

In commands button mode all buttons are large, vertically arranged, have (sadly not in LCL) two captions (or, in other words, caption and immediately rendered hint). There is no panel to have "horizontally-arranged ubttons", or should not be.

In non-c-b mode, all buttons are small, horizontally aranged, and have no hints. But then there is no "big buttons"

In the API it is one and the same "array of butotns" that is being arranged horizontally or vertically.

----

Surely you can extend the dialog to break out of Microsoft guidelines, and add whatever customization. But that would be designing custom window, that you IDE team decided against.

If you want to switch to vertical alignment - it takes a single line change, about Flags property.

If you want to have vertical alignment for "run no debug" yet a separate HELP widget - then it should be HTML-esque "link".

If you to modify TTaskDialog anyway, for implementing non-standard "split buttons" mode, it feels better to invest into implementing standard "hyperlink" mode instead.

Quote
Add a checkbox (as is avail in the dialog) to modify the "project template". So new projects will have the chosen setting too, and not show the dialog.
I would need to search myself, where that code is ....

The code should be simple, just put the checkbox caption into TTaskDialog.VerificationText sting property. After mrOK execute - check .Flags for verificaiton-something

The problem - i think google told me there is or was a bug, that made the state of that checkbox not returned into TTaskDialog.Flags and people were looking for a work-around.
This may be false memory about a different problem, or a bug fixed long-ago. But beware.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 22, 2022, 10:52:09 pm
Sorry, bit slower in responding right now. Some other stuff. Also gonna be offline in a bit....

About the future of the dialog.
At some point a way needs to be found, so the default can be set in such way that no dialog is needed....

But, even then a user can change defaults. In that case the dialog will likely still appear. Especially since the source of the change may not be in the users control (shared project).
However the dialog will then be the exception.
Until then....


> - Add, fetching the default  from the backend

implement a generic API shared by all the back-ends, it should not be hard

however... i repeat my opinion that this qould call for removal of the dialog. If back-end knows which format to set - just do it.
If you feel uneasy about covert data changed - ask user a yes/no (or actually ok/abort) question.
Well, it wouldn't want to go the "covert" way.
So then some dialog remains.

Yes/no vs full-selection => IMHO matter of view.

With a pre-selection set, the text becomes "Click ok to enable the default settings. Or chose an alternative setting" (something along those lines.)


Quote

i believe zamtmn was spot on here. If developer is newb - don't bug him with choices he can not make. The only think newbs need is a a single button "do me an all-round good". If developer is seasoned - inform him of the change done, or ask for permission to do. If he has opinion - he knows how to open and navigate Program Options. Both ways, this dialog is obsoleted as soon as back-end knows what it wants. It was a stopgap measure.

And I think, that a correctly advertised default, is ok for a newbie. Yet keeping the best of both worlds, people with more experience can make other choices.

Quote
Well, maybe "apply default" / "cancel run" / "abort run and open Project Options" is the best possible choice for user.
Would be an option too.


Quote
> - include the check/change for the "external info" flag

this sounds a creeping featurism to me. We would end sucking in the whole Project Options / Debug panel. But it already exists.

Frankly, it feel like you grow more emotionally attached to this dialog than i was. This was always a stopgap before "debugging infrastructure knows better", which was the correct solution. If you implemented the latter, the dialog "outlived its usefulness".
Not really. I actually consider that a quick fix, aka workaround (if indeed it can be done quick).
It reduces the occurrences of the dialog, until a final solution is found.

Though I don't know if it will be easy enough to do... And hence it might not be done.

Quote
> - fix, that the dialog is also shown, when the debug-info is switched off entirely

with the phrase like that i am always lost, what is (bad) observed behavior, and what is (good) goal.

is it that a dialog is shown and it should not be? or the opposite?

In project options, uncheck the "generate debug info" => the effect is that the debugger want work.
But in my tests the dialog wasn't shown.

And again, while it should not happen in first. If it does happen the user should be told. (before he has to wonder why his breakpoint doesn't work)


Quote
4. when a "no debug info" was explicitly selected - the correct behavior would be not to show a prompt, but to make debug-related funcitons fidabled in IDE
Ok, good point. Agreed.

Though, any idea how to give the user the hint, what he needs to do to turn it on?

Quote
Well, here is when you can throw "don't bother newbs" back at me.
VCL (and probably LCL) does not provide for making a control disabled, yet with explanation WHY disabled. Even .ShowHint in VCL is ignored on disabled controls.

Still my gut feeling is that having "Run with debug" "Step in" and similar actions diabled would be better choice.
50/50...

If the button is enabled, yet debugging info is disabled => Display an explanation, with the option to "open the project options"
But if doing so, then having a few "quick fixes" (like the current dialog) in place would be good.

Quote
did you notice how we are sliding into spec-making, BTW ? oh, okay, techwriting sucks, i know :-)
I'd call it collecting ideas...

Quote
Quote
Add "help" to the footer buttons (like ok,cancel) - requires non-native dialog

No it does not.

I always did screenshots from the same Windows machine, and it rendered all four horizontal buttons (help, run no debug, ok, cancel) in native Win7 dialog.
But then the "run without debugger" also goes into the footer. And it is desirable to have that in the main part.

If it is in the footer it seriously impacts the visibility of  the "ok" button.  As one might rather expect a "debug" ("run WITH debug") button instead.


Quote
Quote
  (allows to move "run without" up into the main part of the dlg)

Now this IS impossible, but it is a different thing.
It seems exactly what i asked about yesterday, in the post wit hthree screenshots. « on: 2022-09-20, 18:19:45 » - refresh those questions and screenshots please.
Hence it was lets get some code first (because if we continued without creating a base, we might never get anywhere).

Now we have something, we can (if we want) finetune. (e.g. add the "help" as I suggested)


Quote
Surely you can extend the dialog to break out of Microsoft guidelines, and add whatever customization. But that would be designing custom window, that you IDE team decided against.
It already happens for that dialog. And on Mac and Linux it definitely is so.

Also, I may not have been clear when I discouraged "custom".
There are (at least) 3 levels
- custom, done in the APP (just for this app, or just in one place of the app)
- kinda "custom", yet also not: LCL provided.
- OS provided.

Most things go as given by each OS.
Though there are non OS variants in some places.

So this avenue is open.


Quote
If you to modify TTaskDialog anyway, for implementing non-standard "split buttons" mode, it feels better to invest into implementing standard "hyperlink" mode instead.
Matter of view (in regards to the "help" for this instance of the dialog)
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 23, 2022, 01:15:26 am
After WP implemented "Test dialog" in IDE testing look and feel could be done without coding IMHO.

Sorry, bit slower in responding right now. Some other stuff. Also gonna be offline in a bit....

That's okay, we all have lives to live. Me today paid almost no time to Laz too.

Quote
At some point a way needs to be found, so the default can be set in such way that no dialog is needed....

It just need to make a difference between "unselected" (SQL NULL,  TCombobBox.ItemIndex < 0, TCheckBox.State = csIndeterminate, etc) and explicit "no info".
If new project is creates with "NULL" then debug infrastructure gets free reign to select format (and maybe back-end to) as sees fit.
Maybe with prompt to the user, but not sure: for newbs it would be technobabble, and veterans know well where to customize it.

Quote
But, even then a user can change defaults. In that case the dialog will likely still appear. Especially since the source of the change may not be in the users control (shared project).

When should the dialog pop up then? I only identified one case, user switches the back-end in the Project Options, but then such a dialog can be given immediately, instead of closing PO with inconsistent setup. No need to defer it until actual run attempt.

Now, the nuances of FPC packages is totally beyond me now, so i don't have opinions or even any image of it.
Disclaimer. Here is no covert request for teaching implied

Quote
Quote
4. when a "no debug info" was explicitly selected - the correct behavior would be not to show a prompt, but to make debug-related funcitons fidabled in IDE
Though, any idea how to give the user the hint, what he needs to do to turn it on?

Sadly, no.

Adding reactiong to mouse hovering would probably require serious changes in LCL menu handling...
...at very least. It can also happen that the platform prohibits it whatever you do.
Should LCL be re-implementing menu engines of Windows and MacOS X ?

GTK has a nice trick on menus - they could be detached and made into floating Windows. Later Microsoft Office 2003 (give or take) borrowed that trick.
So we may say full-custom implementation of menu has a good precedent. But still feels too much work on LCL for a feature no one requests.

I thought about creating a submenu "Disabled because Debug Info OFF", which would have "why? what to do?" top row, then a splitter, and then all debug-related items moved into it.
But... a user accustomed to see the menu row in the specific position - would not register this new submenu, he would jsut see "item disappeared" which is not betetr than "item disabled".
Also, a user accustomed to strike F7/F8/F9 keys would not even open menu, at least not immediately.

Then, we could add "[DISABLED] " to the start of caption, pale out the icon, and make the menu action display warnings or help pages.
But such a change then should be made globally accross IDE, feels exotic if not ugly, and... and does not differ much from just throwing the DWARF dialog.  Back to the starting point.

Quote
Quote
Still my gut feeling is that having "Run with debug" "Step in" and similar actions diabled would be better choice.
50/50...

If the button is enabled, yet debugging info is disabled => Display an explanation, with the option to "open the project options"
But if doing so, then having a few "quick fixes" (like the current dialog) in place would be good.

....and we made full circle.

That said, F9 hotkey changing the meaning from "run with debug" to "Run without debug" seems reasonable option.
But F7/F8/Shift-F9/etc - not so much, there is no plausible chaneg of function, it is either do debug or fail.

Maybe the dialog (with accordingly changed explanation text) remains the least bad choice.

Quote
Quote
I always did screenshots from the same Windows machine, and it rendered all four horizontal buttons (help, run no debug, ok, cancel) in native Win7 dialog.

But then the "run without debugger" also goes into the footer. And it is desirable to have that in the main part.

Vertical layout are "one click" designs and make OK/Cancel button no more needed. You would need to add a panel just for on Help button. This would look both weird and unfamiliar. IF you realyl into unconventional design, then perhaps TForm.BorderIcons += biHELP would do... At least GUI-wise. Not sure though. It is not always visible, i no more remember exact conditions though, and would be platform-dependent anyway.

"run without debugger" can be made into one of radiobuttons though. You can do it right now just changing "Buttons.Add" "RadioButtons.Add" in the sources creating that button :-)

Quote
If it is in the footer it seriously impacts the visibility of  the "ok" button.  As one might rather expect a "debug" ("run WITH debug") button instead.

I am not totally convinced, because OK/Cancel buttons still retain the position well-known for all Windows users. And captions are too.

Sorta-kinda.

But then, as long as "horizontal design" is retained, you can just prohibit OK and Cancel in the "CommonButtons" and add "Run with debugger" in exactly the same way we added "Help" and "Run no debug"

"Run with debug info" instead of OK would be confusing, if there are radiobuttons.
Currently it is very clear that "Run without debug" is very different from OK and nullifies the radiogroup selection.

When you have no OK, but "Run with debug info" aside "Run without debug"  - how they relate to radiobuttons is not intuitively clear any more.

So, after some hesitation i decided to go with standard OK/Cancel even if "OK" is so much shorter a caption and this indeed makes it less visible.

----

This way we go back to one-click design having only vertically aligned buttons and no radiobuttons.
Then having "usuall dull gray" help button - even if posisble - without other "usual dull" OK/Cancel and along new "fancy" "Select DWARF2 and run" buttons

----

Then, different platforms have different customs. Buttons could be aligned to left, right or at center. OK/Cancel on Windows and KDE or Cancel/OK on MacOS and Gnome?

Different spacing between buttons - extreme case was to align Help button to the opposite size of the window - can be done in custom dialogs, but not in TTaskDialog.

This is though more appropriate to TTaskDialog general thread.

----

However, lack of HELP in the TTaskDialog.CommonButtons to me looks like a very clear intention by Microsoft - and it is now enshrined by experience of many Windows users and to some degree all WWW surfers.

Quote
Quote
Surely you can extend the dialog to break out of Microsoft guidelines, and add whatever customization. But that would be designing custom window, that you IDE team decided against.
It already happens for that dialog. And on Mac and Linux it definitely is so.

ATM we are abusing the standard API to create a non-closing button. But remain within that API.
Adding custom widgets over OS-rendered dialog would be a different, more intrusive, comple and fragile, level of breaking.
Though there were libraries for Delphi doing exactly that, not x-platform though.

Quote
Quote
If you to modify TTaskDialog anyway, for implementing non-standard "split buttons" mode, it feels better to invest into implementing standard "hyperlink" mode instead.
Matter of view (in regards to the "help" for this instance of the dialog)

We just could not add help action a normal (intended my Microsoft) way.

That said, if there was an API to open Project Options immediately on the Debugging tab - maybe this could be used instead of HELP button?
Contra: if user feels already confused and need Help - would he want to go into yet more complex full-featured config dialog?
Pro: such button would normally close the DWARF dialog so fits well "vertical design", and then help can be opened from taht dialog.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 23, 2022, 03:07:17 am
Quote
At some point a way needs to be found, so the default can be set in such way that no dialog is needed....

It just need to make a difference between "unselected" (SQL NULL,  TCombobBox.ItemIndex < 0, TCheckBox.State = csIndeterminate, etc) and explicit "no info".

It may turn out a lot of work... Maybe not. It will be a bit to actually establish that.

The current state are
- OFF
- default (-g) => that is the default as chosen by FPC
- user set (stabs, dwarf ....)

To allow the IDE to chose: A new state (entry in the dropdown of debug info formats) is needed "Debugger-backend default" . 
And all new projects, would have that by default.

Sounds easy enough.

When last I tried, I run into issues how to handle this value, if set to a package. Because the IDE can create Makefiles for packages (and must do so, in order for the IDE to be build from sources, when you don't yet have an IDE). Only that flag can not be represented...
And there is a reason for prebuild ppu, because there are 3rd party packages without source, that only work with the prebuild ppu. (No, I don't have details).

As I am writing that; yes the flag could be excluded from packages. Of course that makes package un-debugable => well they already have the issue.
(At least potentially - I have no list if and when FPC produces stabs, which would lead to the issue / or a lower dwarf, which may degrade experience / It may be now have changed and packages may by pure chance be ok, or "only degraded" / on the major platforms)

So then all the work is really just to get rid of the dlg. But leave the big part (packages) of the problem unfixed.
Possible. (Not nice, but possible)

In any case. Even "just the project" gets a new setting => it needs to be done.
And right now (and for some foreseeable future) that time does not seem to be free on my schedule.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 23, 2022, 03:29:34 am
Quote
But, even then a user can change defaults. In that case the dialog will likely still appear. Especially since the source of the change may not be in the users control (shared project).
When should the dialog pop up then? I only identified one case, user switches the back-end in the Project Options, but then such a dialog can be given immediately, instead of closing PO with inconsistent setup. No need to defer it until actual run attempt.
- User changed backend in IDE, and opens project after that
- User opens project that was synced via git/svn/... and project has changed
- user changed build mode (e.g. to "release" / may not be named release, IDE may not know if or if not it is meant as release....)

probably more ways

Quote

Quote
Quote
4. when a "no debug info" was explicitly selected - the correct behavior would be not to show a prompt, but to make debug-related funcitons fidabled in IDE
Though, any idea how to give the user the hint, what he needs to do to turn it on?

Sadly, no.

I thought about creating a submenu "Disabled because Debug Info OFF"

I thought a menu item "Enable debugging" but that is only a glorified duplication of the existing "project options". Not a good idea.
Creating help inside the menu => total mess.

Quote
That said, F9 hotkey changing the meaning from "run with debug" to "Run without debug" seems reasonable option.
No good, hiding that debugging isn't working, and then have people asking "why the debugger does not work"....


Quote
Maybe the dialog (with accordingly changed explanation text) remains the least bad choice.
It's not bad, if its on user error.

The problem now is, that it is on IDE default.




Quote
Vertical layout are "one click" designs and make OK/Cancel button no more needed. You would need to add a panel just for on Help button. This would look both weird and unfamiliar. IF you realyl into unconventional design, then perhaps TForm.BorderIcons += biHELP would do... At least GUI-wise. Not sure though. It is not always visible, i no more remember exact conditions though, and would be platform-dependent anyway.

"run without debugger" can be made into one of radiobuttons though. You can do it right now just changing "Buttons.Add" "RadioButtons.Add" in the sources creating that button :-)
Which you disliked (and I come to agree with) because it does not separate it as a totally different thing


Quote
This way we go back to one-click design having only vertically aligned buttons and no radiobuttons.
The radios are good.

And we need them, to  be able to pre-select, or some users wont know what to select.


Quote
However, lack of HELP in the TTaskDialog.CommonButtons to me looks like a very clear intention by Microsoft - and it is now enshrined by experience of many Windows users and to some degree all WWW surfers.
Well, I wouldn't know why they done it....
And I see no reason not to add it, since we can


Quote
Adding custom widgets over OS-rendered dialog would be a different, more intrusive, comple and fragile, level of breaking.
We have the non-OS versions as is shown on Linux. And in some cases also shown on Windows.
That can be used, if a help button is needed.

No messing with the OS supplied dlg.

Quote
That said, if there was an API to open Project Options immediately on the Debugging tab - maybe this could be used instead of HELP button?
Contra: if user feels already confused and need Help - would he want to go into yet more complex full-featured config dialog?
Pro: such button would normally close the DWARF dialog so fits well "vertical design", and then help can be opened from taht dialog.
Actually, there may be. not sure.
If not yet.....
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 23, 2022, 07:22:53 pm
Quote
That said, F9 hotkey changing the meaning from "run with debug" to "Run without debug" seems reasonable option.
No good, hiding that debugging isn't working, and then have people asking "why the debugger does not work"....

Never gave me a trouble in Delphi. But surely, i am just one datapoint.

Quote
The radios are good.

And we need them, to  be able to pre-select, or some users wont know what to select.

You can have default pushbuttons, though the visual cue is really faint (it is animated though, slightly pulsing). At least with Windows native.

However, if LCL dialog is fixed to include command buttons hints, then it would be the same as my early complain about "run no debug". You said that when extended explanation is readilyrendered on the button itself - the users would not be confused.

So, you could advertise the suggested format with a clear hint. You can also move that button to be top one. See the attach.

I do not expect you would make reasonble hints (short descriptions) for every format out there, so i think all the rest would be narrow command buttons, having only format names, and above them would be a tall button having IDE-suggested format with both caption and hint.

Quote
Quote
However, lack of HELP in the TTaskDialog.CommonButtons
And I see no reason not to add it, since we can

Borrowing a concept just to violate it is questionable thing anyway.

And, there might be more than one help required for different topics, plus the pushbuttons are expected to close the dialog.
This seems to be proper refining of a dialog.
We internalized that stretch of a concept long ago, so we no more are confused. But for a person with fresh perception the idea that all buttons are his answer and would close the dialog and proceed on, while one single is not, is an unreliable deviation.

Interpolate it further. Imagine a dialog having 4 horizontal buttons and 3 vertical buttons, some are closing the dialog others don't.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 23, 2022, 08:13:22 pm
Borrowing a concept just to violate it is questionable thing anyway.
Maybe I am missing something....

But do we know for fact that:
- The absence of the help button is not just an oversight
- Rather it was a deliberate decission
- This decision was not in any way something like: to much effort (or other reasons, not directly related to the functionality)
- This decision was in fact, because MS has data that shows this leads to a better user interface

I haven't seen any doc or statement towards that.

Unless I misread something, this is your conclusion from the observation that it is missing?



Besides, if it were true, then the absence of a help button would suggest that help is discouraged. Hence adding it via a hyper-link would be a violation too.
Clearly hyperlinks must be meant for something else.

Actually: no.
NO that last paragraph isn't serious.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 23, 2022, 08:25:11 pm
Googling examples shows that the most common way is to have a "for more info go <link>" in the footer, below the buttons.

Which is 99% the same as a help button... (I.e. it's in the button area, it acts the same, it only looks a bit different, and has a meaningless bit of text before it...)

-------------------
But, anyway with such a link
- in the footer (rather than somewhere else)
- conveying no other info but "I am help"
... with that I am fine.

Mixing it with the content by putting the link elsewhere... IMHO: ouch.

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 23, 2022, 09:08:10 pm
Unless I misread something, this is your conclusion from the observation that it is missing?

Besides, if it were true, then the absence of a help button would suggest that help is discouraged. Hence adding it via a hyper-link would be a violation too.
Clearly hyperlinks must be meant for something else.

And also, from observation how Windows itself was using those dialogs.

Hyperlinks are explicitly not button (so, the expectation to close the dialog is not with them), and are expectd to WWW surfers exactly to "open another page, explaining the link's caption in more details"

Microsoft was more or less actively trying to blend Windows and WWW since 1996.
With Vista+ that trend got another boost.

https://technologyslash.com/posts/how-to-change-computer-properties-info-in-windows-7.png
https://fuzeservers.ru/wp-content/uploads/5/1/2/512ae167109107cdc2f7c0e936636198.png

Notice, how this windows, Win7 to Win10, explicitly has no buttons, but a lot of hyperlinks.
This trend i really noticeble and users who di not work with earlier windows might even lack a different reference frame.

http://elmajdal.net/Win7/Changing_Screen_Resolution_in_Windows_7/4-win7_accept_changes.png

The screen resolution change winodws does have both hyperlink and buttons.
And buttons are reserved for "do actions" rather than "open another windows with more details" which are still hyperlinks.

Also, for all the years after Vista was released - the Help button was not added back.

Quote
then the absence of a help button would suggest that help is discouraged.
To a degree.
The extended hints above and below buttons, command buttons thenselves with long captions and added hint panels - those indeed emphasize diallogs, that are verbose enough they rarely need help.
Especially a "general help" on the dialog itself. I think i read the document deliberately pushing for it, in Vista times. The screens became large, they say, so don't make users open help, was the tune.
For in-depth topics on specific related things - there are hyperlinks.

> NO that last paragraph isn't serious.

Provide API - and people would make it serious.
There is reason why Windows, MacOS, Gnome seek to make guidelines and API restrictive.

--------------

https://learn.microsoft.com/en-us/windows/win32/uxguide/mess-confirm

Scroll down to the "Usage patterns" gallery. The "Securty condirmations" dialogs have documentation hyperlinks, other dialogs have no external documentation. The need to provide enough information immediately, so no extra actions to get external information be required, is a recurrying theme in the article above too.

Also, the link to the dialogs are positioned in lower parts of the window, below the buttons. This was probably intended too, as auser reads the windows top-down, chances are he gets enough information to act upon early on. Then the user would commit to a choice and push a button. If he continues reading past the buttons, then he probably can not make his mind, and THEN providing extra materiel becomes timely.

Two example of "links above buttons" can be seen in https://learn.microsoft.com/en-us/windows/win32/uxguide/win-dialog-box - and those windows do not have footers to host that links otherwise.


Below the gallery there is "Guidelines" section, notice the terminology used, "Commit buttons". The buttons should commit.

-------

BTW perhaps we'd better change the main dialog's icon.

https://learn.microsoft.com/en-us/windows/win32/uxguide/mess-warn

Quote
We overwarn in Microsoft Windows programs. The typical Windows program has warnings seemingly everywhere, warning about things that have little significance. In some programs, nearly every question is presented as a warning.  ...  The mere potential for data loss or a future problem alone is insufficient to call for a warning. Additionally, any undesirable results should be unexpected or unintended, and not easily corrected.

Scroll down to the "Icons" section - and you see two examples of "good design" that chanced to have external documentation - both use hyperlinks.

------------

https://learn.microsoft.com/en-us/windows/win32/uxguide/text-ui

Quote
Avoid over-communication. Even if text isn't redundant, it can simply be too wordy in an effort to explain every detail. Too much text discourages reading the eye tends to skip right over it ironically resulting in less communication rather than more. In UI text, concisely communicate the essential information. If more information is necessary for some users or some scenarios, provide a link to more detailed Help content, or perhaps to a glossary entry for clarification of a term.

Resume: the lack of "Help" commit button in TaskDialog, from the year Vista was released and up to today, is consistent with both Windows 7 to Windows 10 GUI and with published then user interface guidelines.

----

Also https://learn.microsoft.com/en-us/windows/win32/controls/tdn-help

Keyboard F1 is the only said way to call help... Guess, it was concession to established user habits and deviation from their ideal design. LCL does not implement it anyway though.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 23, 2022, 09:57:11 pm
Microsoft was more or less actively trying to blend Windows and WWW since 1996.
With Vista+ that trend got another boost.
So it's marketing. Marketing is in no way the same as user-friendlinies. And we are in now way compelled to support their marketing.

Just my opinion.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 24, 2022, 12:45:08 am
Anyway, it now leads down other roads....

The IDE already has to many styles, in different areas. Starting with diff toolbar settings (text, icon, both, small, large, ...).
Diff buttons (plain, image, ...)

That should be unified (though nobody currently has spare time...).  Adding yet another fundamentally new style.... Maybe not the greatest idea.

And then, the style might be alien to other WS.

On Fedora (33), I found overall 2 links in the system settings, everything else buttons or other established widgets.
For Mac, I looked at images by google, and did not see any links (though I did not spend much time).

Of course - just a thought / an idea to entertain: ignoring the style being alien to the rest of the IDE, adding it as a enum value to the buttons (like ok, cancel), it could be displayed as link on Windows....
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 27, 2022, 01:19:21 am
So it's marketing. Marketing is in no way the same as user-friendlinies. And we are in now way compelled to support their marketing.

Original meaning of marketing was learning the market, learning what is actually wanted by users, not what you want to be good for them.
While talks about "information highway" in 1995 were premature, the overall direction was detected properly. Smartphones on every street would attest to it.

Now, "bad marketing" could be seen in MS attempts to play down smartphones and to insist on desktops and laptops way too long.
But again, general directions was detected right, and Netscape started it before Microsoft awaken, and Apple wth Google did it after Microsot fell asleep again.

So i think those GUI guidelines and the TTaskDialog specifically is generally a sound concept and is not useless money squeezer.

That of course does not mean anyone has to agree to this concept.  Just like there are different OSes and languages, each one sound in their way.
Yet TTaskDialog is a fruition of that concept, and if we disagree with it - better then not pretend and make a windows custom-tailored to our vision.

And then, the style might be alien to other WS.
On Fedora (33)...
For Mac...

...was one of the reasons i argued for custom "typical LCL" window instead and cheered when TButtonPanel could be used again, throwing away rather my (more polished) imitation of it.

The IDE already has to many styles...  That should be unified...

...and this thought made me think the insistence on TTaskDialog was "let' use deebugger as lab rat and see if TTaskDialog sticks. If it does - the rest of IDE can start coalescing on it"
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: wp on September 27, 2022, 10:24:42 am
In the attachments, the old and new dialogs for Dwarf debug information format selection can be compared.

In my impression, the new dialog (which is based on TTaskDialog) is overloaded and confusing. Now two clicks are needed to start compilation: Select "Dwarf 3", then "OK" - in the old dialog I only clicked on "Dwarf 3", and that was it.

And why is there a "Run with no debugger" button so prominently close to the "OK" button; I am a left-to-right reading person and it always strikes my attention unnecessarily. 99% of my compilations are running with debugger, and I don't want to change my mind after having decided to press F9.

Why does the dialog have that warning icon? This is alarming, saying: "You are on dangerous ground. Be careful." But it simply is asking a question: Which debugger format do you want? Therefore the question mark icon of the old dialog is much more appropriate.

I also don't know whether the pseudo-help text at the bottom is needed; it is clear that all compilation settings can be changed in the project options. And no other IDE dialog gives a hint on visiting the project options.

The old dialog, on the other hand, is very clear: It describes what is going on and asks me to press one of the buttons. The only way it could be improved is that it would not appear at all - but this has been discussed several times before.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 27, 2022, 12:38:12 pm
In my impression, the new dialog (which is based on TTaskDialog) is overloaded and confusing. Now two clicks are needed to start compilation: Select "Dwarf 3", then "OK" - in the old dialog I only clicked on "Dwarf 3", and that was it.
I fixed that. Now the "backend preferred" default is selected.

So one click, to use the default, and for those who don't know the default is pre-selected.

Did have to fix TaskDialog.
Didn't check, but likely similar fix for default button may be needed.

Quote
And why is there a "Run with no debugger" button so prominently close to the "OK" button; I am a left-to-right reading person and it always strikes my attention unnecessarily. 99% of my compilations are running with debugger, and I don't want to change my mind after having decided to press F9.
Yes that worries me do.

I wanted this a *button*, but in the *main-panel* (below the radios).
Yet keep the help button, in the lower button panel.
I was hoping another patch could be made for that....

Might disable the "run without" for the time being... I am away for about a week, starting tomorrow, so might not get to this before.


Quote
Why does the dialog have that warning icon? This is alarming, saying: "You are on dangerous ground. Be careful." But it simply is asking a question: Which debugger format do you want? Therefore the question mark icon of the old dialog is much more appropriate.
Well, good question. That is more generally: What is considered a warning?

"Your debugging session is about to fail, because you got wrong settings" => IMHO a warning. Even so it is not "dangerous", unless you have a breakpoint intercepting your code before it does something like "format c:".
But otherwise, it's just about "you are going to waste your time".... (which is still something bad).

And then "Do you want to close that file without saving it first", also comes down to you are going to have wasted your time. Well, ok... That is quite a bit simplified....

Anyway, I am ok with warning or question icon....



Quote
I also don't know whether the pseudo-help text at the bottom is needed; it is clear that all compilation settings can be changed in the project options. And no other IDE dialog gives a hint on visiting the project options.

The old dialog, on the other hand, is very clear: It describes what is going on and asks me to press one of the buttons. The only way it could be improved is that it would not appear at all - but this has been discussed several times before.
Personally I thought that info to be useful. Especially for new users who may not know where this can be set.

The "what is going on" is still there, right on the top of the box.

Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 27, 2022, 12:46:03 pm
There is a natural confusion between "easy to learn" and "thing i learned years ago and internalized".
We are all biased, and the more experience we gain with some tool - the stronger becomes the bias.

Quote
Now two clicks are needed to start compilation: Select "Dwarf 3", then "OK" - in the old dialog I only clicked on "Dwarf 3", and that was it.

Needed is one click, on OK button or even just hitting "Enter" key.

But if you disagree with IDE's default, then i believe forcing a second click is actually good. It is only done once per project.

Actually, mere providing default choice defuses the confusion. Old dialog was a total show stopper: what butotn should developer select to have enerything good and nothing bad? the old dialog sis not provide help... And this confusion would be partially restored if to switch task dialog from "radiobuttons design" to "vertical command buttons" design, as presented in screenshots on prior pages.

Quote
And why is there a "Run with no debugger" button so prominently close to the "OK" button; I am a left-to-right reading person and it always strikes my attention unnecessarily.

Because there is no "menu break" in the button bar. More so, the leftmost position there is reserved for "verification checkbox".

So, if keeping the general "radiogroup and horizontal "common buttons bar" approach, alternatives would be:
 - make no-debug into a radiobutotn, as one of debug formats
 - OK / Run no debug / Cancel
 - OK / Cancel / Run no debug

I preserved "standard" OK/Cancel positioning as right-bottom pair.

When i did full-custom proposal initially, there were space gaps between button, hinting at logical grouping.

Quote
99% of my compilations are running with debugger, and I don't want to change my mind after having decided to press F9.

Agree, but this should not be fixed by redesigning the dialog.
IDE should pre-select it to users without showing this dialog, this dialog should be reserved too later edge cases, that many developers would not ever meet.
When ther is "no dialog" - no argument about its design :-)

Quote
Therefore the question mark icon of the old dialog is much more appropriate.

Which reiterates the Microsoft guidelines i quoted above :-)  Sometimes Microsoft can produce more than marketing BS.

I agree. The "overwarning" ((c) MS) is really a bad habit.

Quote
I also don't know whether the pseudo-help text at the bottom is needed;

It is. The old dialog induces fear and is a road block. Much more that warning icon..

Quote
it is clear that all compilation settings can be changed in the project options.

No, it is not. What clear is you having many years experience of doing it. But for persons with no experience it is not so.


This notice for novices defuses the confusion and tells them "here is no danger, you can easily change your mind".

Quote
And no other IDE dialog gives a hint on visiting the project options.

Which is misfeature in those dialogs, hopefuully incrementalyl fixed.
Even if TTaskDialog is ditched and some other more LCL-ish deisgn would be set upon sas "new IDE standard".

Quote
The old dialog, on the other hand, is very clear: It describes what is going on and asks me to press one of the buttons.

without documenting the consequences of it.

From a novice PoV the old dialog is similar to "shell game" - choose your loss and give us a pretext to blame you of it, except that shell game typically only has 3 shells, while the old dialog had five (including the [X] in the top-right corner).
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 27, 2022, 01:12:52 pm
We are all biased, and the more experience we gain with some tool - the stronger becomes the bias.
Like someone who potentially has a lot of Delphi experience, looking at a different approach of UI-Design.... ;)

Quote
So, if keeping the general "radiogroup and horizontal "common buttons bar" approach, alternatives would be:
 - make no-debug into a radiobutotn, as one of debug formats
 - OK / Run no debug / Cancel
 - OK / Cancel / Run no debug
It was made pretty clear, that there is ONE other option. And that (for me) that is the option to go with (i.e. the only one I am willing to apply / if another team member wants to apply a different option => fine).

Whatever Microsoft says, they are certainly not having a monopoly on being right. As in, there may be more than one way to do it proper.
It was seen, considered and disregarded.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 27, 2022, 01:27:50 pm
We are all biased, and the more experience we gain with some tool - the stronger becomes the bias.
Like someone who potentially has a lot of Delphi experience, looking at a different approach of UI-Design.... ;)

Sure.
But i heard that Delphi compatibility is strong case for Lazarus.

Quote
Whatever Microsoft says, they are certainly not having a monopoly on being right. As in, there may be more than one way to do it proper.

And i am saying "ditch MS taskdialog and do custom LCL-ish window" from even before you said it.

Making misbehaving task dialog would be worse, both from programming point of view (fighting the system, instead of just making a fitting system) and user experience one.

"We painted buttons differently, so dumb Window users won't understood this was task dialog" - they would. They had decade of experience with neatly designed instances of it. They would clearly see unconformant ang ugly-looking one.

You would code two designs for every such dialog, depending on OS? And make problems for using sharing their experince across platforms? Well, see above, don't pick wrong tool, just to be fighting it and abusing it always later.

From the 2nd page: https://forum.lazarus.freepascal.org/index.php?action=dlattach;topic=60624.0;attach=50814;image
WP, did you participate during 2nd page infighing? :-D
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 27, 2022, 01:42:57 pm
We are all biased, and the more experience we gain with some tool - the stronger becomes the bias.
Like someone who potentially has a lot of Delphi experience, looking at a different approach of UI-Design.... ;)

Sure.
But i heard that Delphi compatibility is strong case for Lazarus.
We strife to do better than ....

And also that is LCL, and (some) packages. Not (or to a lesser extend) the IDE-UI. After all, we even have some features they (afaik) don't have.


Quote
Making misbehaving task dialog would be worse, both from programming point of view (fighting the system, instead of just making a fitting system) and user experience one.
Your opinion. Noted (again). Disagreed (again). No new info since... End of story.

And I still don't see where you get "fighting the system". It isn't there, and I pointed that out before.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 27, 2022, 01:55:26 pm
And I still don't see where you get "fighting the system". It isn't there, and I pointed that out before.

Designing a custom dialog took about half hour.
Including making texts, and positioning and repositioning bottom buttons, just to later throw them out and put TButtonsPanel back again.

Adding there plumbing, like form-level properties to be kept even if widgets changed later, would take about the same time.
Or maybe won't be needed at all, as this one-purpose dialog would have few uses and every caller can be coded directly against exposed published widgets.

On the other cup we have, after days, a vague idea to "extend TTaskDialog API in some still reasonable way" and to "implement this extension in some still reasonable way" and "to implement this extension so that a native dialog would still be used on Windows".
...and i speculate, after that you would also gain a stream of users, thin but steady for many years, reporting the dialog misbehaving.

One hour vs few days - no, not fighting a system.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 27, 2022, 02:04:04 pm
And I still don't see where you get "fighting the system". It isn't there, and I pointed that out before.

Designing a custom dialog took about half hour.
Including making texts, and positiining and repositioning bottom buttons, just to later throw them out and putting TButtonsPanel back again.

Adding there plumbing, like form-level properties to be kept even if control changed, would take about the same.
Or maybe won't be needed at all, as this one-purpose dialog would have few uses and eveyr place can be coded directly against exposed published widgets.

On the other cup we have, after days, a vague idea to "extend TTaskDialog API in some still reasonable way" and to "implement this extension in some still reasonable way" and "to implement this extension so that a native dialog would still be used on Windows".
...and i speculate, after that you would also have a number of users, thin but steady for many years, reporting the dialog misbehaving.

One hour vs few days - no, not fighting a system.
OK missunderstanding, different "system", not "Operating system"... Still, actually the same response...

Well yes, if you write code just for your own app (or just for the IDE) you don't need to worry about others using that code.

But since we do provide common code to all users, and since (as your reply above seems to agree on) this code could be useful to others (as you said, they might use it).
But then, yes if you write code that others may use => that adds some work.

That is how the "system" (making it public available) works.
I do not see it as a fight, if I want others to benefit of an implementation.


Already just using the existing TaskDialog has lead to bug fixes in it. Huge benefit.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 27, 2022, 02:11:30 pm
...and i do not see the work to dillute the concept, a good one in total, and widely used by millions of users worldwide, as "benefitting others".  Would be not converging, but splitting.

Would LCL, after evaluating TTaskDialog, design their own one, not trying to be "kinda-sorts mirosoft's one without microsoft" - i would have no beef with that.

The proposal #2 obviously could had easily be generalized, for example.

Though, this is more fitting the general TTaskDialog thread, not debugger-specific one.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: wp on September 27, 2022, 03:25:17 pm
Another screenshot, now from Linux Mint (gtk2), switched to 192ppi screen resolution. At least while these scaling issues are not fixed, we should return to the old dialog...
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 27, 2022, 04:21:32 pm
Another screenshot, now from Linux Mint (gtk2), switched to 192ppi screen resolution. At least while these scaling issues are not fixed, we should return to the old dialog...

can you show other forms for comparison? and maybe thewhole desktop with proper and impproper forms/dialogs

I see problems with having no bitmaps of larger size (does stock LCL has something like TSVGBitmap for glyphs?), but as for the rest i do not see "problems" but rather a window being rendered despite a very limiting environment.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Martin_fr on September 27, 2022, 04:40:22 pm
Maybe it is enough to set   Dialog.Form.Scaled=True

lcl\lcltaskdialog.pas line 840
  Dialog.Form := TEmulatedTaskDialog.CreateNew(Application);


Otherwise line 860
Code: Pascal  [Select][+][-]
  1.       aWidth := Dialog.Form.Canvas.TextWidth(Inst);
  2.       if (aWidth>300) or (Dialog.Form.Canvas.TextWidth(Content)>300) or
  3.          (length(Buttons)>40) then
  4.         aWidth := 480 else
  5.         aWidth := 420;
  6.  

needs to be scaled for DPI / or relative to the screen width
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: Arioch on September 27, 2022, 04:47:50 pm
Otherwise line 860  needs to be scaled for DPI / or relative to the screen width

Do you remember a joke about daughter, driving her car in wrong lane?

You would not have to scale "line 860" but ALL of the procedure, where all the controls and their bounds are ad hoc calculated wit hpixel accuracy (up to the point of "on Windows add 1 px, on Linux do not")

So, in the end it would be, IMHO, more simple to drop that code and just make a regular window in Form Designer using .AutoSize and .Align on most if not all controls.
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: wp on September 27, 2022, 10:55:08 pm
So, go ahead...
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: wp on September 28, 2022, 01:02:03 pm
Fixed scaling. Tested on Linux @192ppi --> some issues left (why is the row of buttons wrapped?)
Title: Re: The "Enable DWARF" dialog - before starting the debugger.
Post by: wp on September 28, 2022, 10:13:00 pm
Ondrej fine-tuned it, and now it's correctly scaled.
TinyPortal © 2005-2018