Recent

Author Topic: The "Enable DWARF" dialog - before starting the debugger.  (Read 9209 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
The "Enable DWARF" dialog - before starting the debugger.
« 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.

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #1 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.
« Last Edit: September 17, 2022, 11:00:27 pm by Arioch »

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #2 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

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #3 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 :-)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #4 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"

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #5 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)









zamtmn

  • Hero Member
  • *****
  • Posts: 594
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #6 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

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #7 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.
« Last Edit: September 18, 2022, 02:53:54 pm by Arioch »

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #8 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
« Last Edit: September 18, 2022, 06:44:38 pm by Arioch »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #9 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.


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #10 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....





440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #11 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.
« Last Edit: September 19, 2022, 06:01:06 am by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

zamtmn

  • Hero Member
  • *****
  • Posts: 594
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #12 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

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #13 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.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #14 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.

 

TinyPortal © 2005-2018