Recent

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

Martin_fr

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


Arioch

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

Martin_fr

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

Martin_fr

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

Arioch

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

wp

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

Martin_fr

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


Arioch

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

  • There is no a priori warranty that every change can be undone. When i create e-mail account in mail programs, once i selected POP3 or IMAP i almost never can reconfigure the acocunt, i would only be able to delete it andcreate new one. And before you say "this is no mail account, this is just a project options" - you can only say it exactly out of the many years experience with both, that not everyone has.
  • Even if user thinks after the fact changing some setting is good thing, it does not warrant that Lazarus team had the same opinion
  • Even if Lazarus team had the same opinion, it does not warrant they implemented such a retroactivechange. It could had been complex, or could had been very low priority
  • Even if Lazarus team implemented it - who knows where? Lazarus has dozens of windows, and those have dozens of tabs/sections.Memorizing them all might take years.

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).

Martin_fr

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

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #84 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
« Last Edit: September 27, 2022, 01:32:25 pm by Arioch »

Martin_fr

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

Arioch

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

Martin_fr

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

Arioch

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

wp

  • Hero Member
  • *****
  • Posts: 10298
Re: The "Enable DWARF" dialog - before starting the debugger.
« Reply #89 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...
« Last Edit: September 27, 2022, 03:31:49 pm by wp »

 

TinyPortal © 2005-2018