Recent

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

Arioch

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

Martin_fr

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


Martin_fr

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

Arioch

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

Martin_fr

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

Martin_fr

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

Arioch

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

Martin_fr

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

Arioch

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

Arioch

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

Josh

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

The best way to get accurate information on the forum is to post something wrong and wait for corrections.

Arioch

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

Arioch

  • Sr. Member
  • ****
  • Posts: 421
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #27 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) with tfUseCommandLinks and the rest was the same.

Arioch

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

Martin_fr

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

 

TinyPortal © 2005-2018