Recent

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

Arioch

  • Sr. Member
  • ****
  • Posts: 384
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #60 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
« Last Edit: September 20, 2022, 10:41:07 pm by Arioch »

Martin_fr

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





Arioch

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

Martin_fr

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

Arioch

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

Arioch

  • Sr. Member
  • ****
  • Posts: 384
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #65 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
« Last Edit: September 20, 2022, 11:41:42 pm by Arioch »

Martin_fr

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

Martin_fr

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





Arioch

  • Sr. Member
  • ****
  • Posts: 384
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #68 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.
« Last Edit: September 21, 2022, 06:57:03 pm by Arioch »

Martin_fr

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

Arioch

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

Martin_fr

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

Martin_fr

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

Arioch

  • Sr. Member
  • ****
  • Posts: 384
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #73 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.
« Last Edit: September 23, 2022, 07:26:42 pm by Arioch »

Martin_fr

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

 

TinyPortal © 2005-2018