The "Enable DWARF" dialog - before starting the debugger.
lazarus / 12-Debugger
----------------------------------------------------------------------
Martin_fr · 2022-09-17 20:12
A question that reached me about that dialog.
Described at https://wiki.lazarus.freepascal.org/DWARF
QuoteMy 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
QuoteAlso 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 · 2022-09-17 20:57
Quote from: Martin_fr on September 17, 2022, 10:12:10 pm1) 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.
QuoteAnd 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.
Quote3) 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.
----------------------------------------------------------------------
Arioch · 2022-09-17 21:03
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 · 2022-09-17 21:28
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 · 2022-09-17 21:37
Quote from: Arioch on September 17, 2022, 11:03:38 pmAlso, 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 · 2022-09-17 22:15
QuoteBound 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)
Quotee "[ 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 timeI 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 · 2022-09-18 10:17
Please make DWARF as an automatic format for windows, this will remove
99% of the views of this dialog
----------------------------------------------------------------------
Arioch · 2022-09-18 12:45
Quote from: Martin_fr on September 18, 2022, 12:15:33 am2) 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
QuoteI 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.
QuoteQuote(*) Run without debugger now, ask me again next timeI 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.
----------------------------------------------------------------------
Arioch · 2022-09-18 13:18
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
----------------------------------------------------------------------
Martin_fr · 2022-09-18 22:29
Quote from: zamtmn on September 18, 2022, 12:17:33 pmPlease 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 · 2022-09-18 23:22
Quote from: Arioch on September 18, 2022, 02:45:46 pmQuoteI 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? ....
QuoteAnd 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.
QuoteRadioGroup 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.
QuoteAnother 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);
QuoteI 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 · 2022-09-19 03:32
Quote from: Martin_fr on September 19, 2022, 01:22:04 amI 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.
----------------------------------------------------------------------
zamtmn · 2022-09-19 07:51
>>And i think those dialogs do work in FPC/LCL today.
It include in LCL see lazarus\lcl\lcltaskdialog.pas
----------------------------------------------------------------------
Martin_fr · 2022-09-19 11:20
Quote from: zamtmn on September 19, 2022, 09:51:43 am>>And i think
those dialogs do work in FPC/LCL today.
It include in LCL see lazarus\lcl\lcltaskdialog.pas
Cool, so then that can be used.
It's radio too, but ok.
----------------------------------------------------------------------
PascalDragon · 2022-09-19 11:29
Quote from: zamtmn on September 19, 2022, 09:51:43 am>>And i think
those dialogs do work in FPC/LCL today.
It include in LCL see lazarus\lcl\lcltaskdialog.pas
To be precise it's available as TTaskDialog in unit Dialogs. Unit
LCLTaskDialog contains the low level implementation.
----------------------------------------------------------------------
Arioch · 2022-09-19 11:31
QuoteQuote from: Martin_fr on September 19, 2022, 01:22:04 amThs
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.
QuoteAnd 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"
QuoteI 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" :-)
QuoteQuoteRadioGroup 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
QuoteQuoteAnother 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
QuoteQuoteI 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
QuoteThere 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
QuoteAnd 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 · 2022-09-19 11:54
Quote from: Arioch on September 19, 2022, 01:31:34 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 · 2022-09-19 11:58
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 · 2022-09-19 12:05
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 · 2022-09-19 12:14
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 · 2022-09-19 12:20
Quote from: Arioch on September 19, 2022, 02:05:01 pmOkay... 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 · 2022-09-19 12:21
Quote from: Martin_fr on September 19, 2022, 01:54:15 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".
QuoteToo many people .... didn't read the textQuoteThe 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.
QuoteYou 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 · 2022-09-19 12:40
Quote from: Arioch on September 19, 2022, 02:21:45 pm
QuoteToo many people .... didn't read the textQuoteThe current one
click is seen as desirable.
Again, mutually exclusive.
Quote from: Martin_fr on September 19, 2022, 01:54:15 pm"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 · 2022-09-19 13:05
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.embarcade
ro.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.
----------------------------------------------------------------------
Arioch · 2022-09-19 13:17
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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i object
dlgDWARF: TTaskDialog Buttons = < item Caption = 'Run with
no debugger' ModalResult = 100 end> Caption = 'Running your
application with debugger' Flags = [tfEnableHyperlinks,
tfAllowDialogCancellation] FooterIcon = tdiInformation FooterText =
'This choice can be later changed in Project Options / Compiler
Options / Debugging window.' MainIcon = tdiWarning RadioButtons = <
item Caption = 'DebugInfo Format #1' end item
Caption = 'DebugInfo Format #2' end item Caption =
'DebugInfo Format #3' end item Caption = 'DebugInfo
Format #4' end> Text = 'Debugger can only run your application
when it was compiled with Debug Information enabled. Click here
for more info.' Title = 'Choose Debug Information format' Left =
493 Top = 454end
----------------------------------------------------------------------
Josh · 2022-09-19 13:28
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,
----------------------------------------------------------------------
Arioch · 2022-09-19 13:42
Quote from: Josh on September 19, 2022, 03:28:41 pmWhichever 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.
----------------------------------------------------------------------
Arioch · 2022-09-19 14:03
Quote from: Martin_fr on September 19, 2022, 02:20:54 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 · 2022-09-19 14:09
Offoptic, but
Quote from: Martin_fr on September 18, 2022, 12:15:33 amUnless 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 · 2022-09-19 16:51
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....
----------------------------------------------------------------------
Arioch · 2022-09-19 17:42
no Martin, they meant that that all RadioButtons had to be removed,
and inserted as Buttons insetad (AKA CommandButtons)
i believe one-click is BAD goal, but whatever
at least in Delphi you also would have to include tfUseCommandLinks
flag, otherwise you would again end with a smimilar ultra-wide kind of
dialog we started with
also, like said above, ControlButtons had to be empty set
but the biggest issue for now i believe would be inability to link to
Help because LCL TaskDialog did not implemented events but one.
while you can implement it i believe it would be re-inventing the
wheel and the better course would be to find a better implementation.
Hopefully mORMot, coming from Windows, did more complete
implementatoin, and given compatiblie license (hopefully) they can be
asked to donate.
Here is XE2 component copied, but converting clipboard DFM to LFM or
to Pascal source shold not be hard
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i object
TaskDialog1: TTaskDialog Buttons = < item Caption =
'DebugInfo Format #1' ModalResult = 201 end item
Caption = 'DebugInfo Format #2' ModalResult = 202 end item
Caption = 'DebugInfo Format #2' ModalResult = 203 end
item Caption = 'DebugInfo Format #4' ModalResult = 204
end item Caption = 'Run with no debugger' CommandLinkHint
= 'If you continue running without Debug Info selected - the
debugg' + 'er would not be enabled, and this question would
reappear next t' + 'ime you run your application.'
ModalResult = 100 end> Caption = 'Running your application with
debugger' CommonButtons = [] Flags = [tfEnableHyperlinks,
tfNoDefaultRadioButton, tfUseCommandLinks] FooterIcon = 3 FooterText
= 'This choice can be later changed in Project Options / Compiler
O' + 'ptions / Debugging window.' HelpContext = 10 MainIcon = 1
RadioButtons = <> Text = 'Debugger can only run your application
when it was compiled with' + ' Debug Information enabled. Click here for more info' +
'.' Title = 'Choose Debug Information format' Left = 504 Top =
272end
As for pre-selecting radio-button i don't mean this is on the table.
1) it would require serious rework of infrastructure to communicate
the available choices and the best choices ot the dialog.
In short term - that is not there. We can just do fast drop-in
replacement to what is there already.
Frankly, once-click vertical-aligned pushbutotns-only dialog is as
close to drop-in as possible. In this your team peers are spot on.
2) and when you do - in long term - this dialog would probably be no
more needed and be removed
zamtmn does have a point. If Lazarus does know what thebest choice is
- do not preselect the radiobutton, just update project options and do
not bug novices
----------------------------------------------------------------------
Martin_fr · 2022-09-19 18:25
You can mix the button and the radio
Either
- radios for various debug info / default selected
- button (in main part of dlg)for without debug
OR
- radios for various debug info / default selected
- run without in the button panel, but "run / debug" instead of "ok"
Just making sure the main action to run with the debug info is not put
into shadows by a more visible "run without dbg" button next to it.
---
It was established the help button can be used....
----------------------------------------------------------------------
Arioch · 2022-09-19 18:49
Quote from: Martin_fr on September 19, 2022, 08:25:18 pmYou can mix
the button and the radio
Just making sure the main action to run with the debug info is not put
into shadows by a more visible "run without dbg" button next to it.
I believe the mixed dialog at https://forum.lazarus.freepascal.org/ind
ex.php/topic,60624.msg454194.html#msg454194
is exactly th example how button overshadows radiobuttons, and it can
not be helped
i believe it is wasting effort now
- You team peers believe in one-push approach,
- the existing right now infrasturcture does not provide for pre-
selectin (or does it ?)
- after the infrastructure get evolved and generalized - there is big
chance this dialog would be outright removed
So, make the simplest possible drop-in with array of vertical "command
buttons" and with no "OK" and 'Cancel" buttons at all in the low panel
of standard buttons. Okay, maybe with a single "Abort" button doesn
there.
It is fast, simple, fits as drop-in replacement, and is what your
peers prefer. Seems a bingo.
Would anyone ever provide help to the dialog, before this dialog
removed at all? Then he would patch TTaskDialog to have it, or would
take more developed component.
QuoteIt was established the help button can be used....
What it means? You were given green light to add it? Or you were
promiced it can be added ?
There is NO such "CommonButton", everyone went Internet and Microsoft
discarded it, instead urging to provide hyperlinks. Twice so since
you can have only one Help button but multiple links.
You can add custom Command Button indeed - but... Then it still will
close the dialog EVEN if you set zero ModalResult.
Non-modal buttons in modal dialogs are considered harmful :-D And
honestly, MS has a point here.
----------------------------------------------------------------------
Arioch · 2022-09-19 18:53
or just re-enable closing the dialog with Esc or [ X ] - and that
would be your "abort" options.
Include( Flags, tfAllowDialogCancellation )
----------------------------------------------------------------------
Martin_fr · 2022-09-19 19:08
Quote from: Arioch on September 19, 2022, 08:49:45 pmQuote from:
Martin_fr on September 19, 2022, 08:25:18 pmYou can mix the button and
the radio
Just making sure the main action to run with the debug info is not put
into shadows by a more visible "run without dbg" button next to it.
I believe the mixed dialog at https://forum.lazarus.freepascal.org/ind
ex.php/topic,60624.msg454194.html#msg454194
is exactly th example how button overshadows radiobuttons, and it can
not be helped
yes, sorry I missed we had that before. Looks good.
Quotei believe it is wasting effort now
- You team peers believe in one-push approach,
- the existing right now infrasturcture does not provide for pre-
selectin (or does it ?)
- after the infrastructure get evolved and generalized - there is big
chance this dialog would be outright removed
It will be
- 1 new enum (listing the options)
- about 5 lines of code per backend (and some backends inherit, and
don't need it)
(if the backend has requirements / currently 2 of them)
- virtual in the base class
1) procedure declaration
2) procedure in implementation
3) begin
4) the value
5) end
Between 30 seconds and a minute per backend.
Have you looked at the current code calling the dialog, and where it
gets the list from?
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i class
function TFpDebugDebugger.RequiredCompilerOpts(ATargetCPU, ATargetOS:
String): TDebugCompilerRequirements;
QuoteQuoteIt was established the help button can be used....
What it means? You were given green light to add it? Or you were
promiced it can be added ?
It already exist in some dialogs, so its not a new concept, so it can
be used here too.
Invoking help is done by the single line of code, I posted earlier.
----------------------------------------------------------------------
Arioch · 2022-09-19 19:28
Quote from: Martin_fr on September 19, 2022, 09:08:13 pmBetween 30
seconds and a minute per backend.
Have you looked at the current code calling the dialog, and where it
gets the list from?
It already exist in some dialogs, so its not a new concept, so it can
be used here too.
1. Ok, good if it is so. Rehash API and we'll see.
Sad point, i tried to cherry-pick your commits into Fixes_2_2 and got
conflicts... Maybe because my Fixes_2_2 is dirty
2. No, like i said, fixing design first. I do not want to make
elaborate work only for it to be discarded and said to be not-
Lazarish. One time is enough. Agreement on design first, implementing
later.
Besides i spent fair deal of braincells and time on LCL today
debugging ActiveX failure with undocumented library.
3. The concept is not new, but it was deliberately removed from MS
TaskDialog.
So, we are back to square one - either drop TaskDialog and design
custom window, or drop Help button, that never was there to start
with.
Personally i believe hyperlink is no worse to the button, but LCL
does not have them either. The sources clearly show they did not
implement tdfEnableHyperLinks - it just is included to execute Delphi
code unchanged, but does not work.
So, neither Help button nor hyperlinks in the task dialog.
If you need them - then make custom window instead.
P.S. ...i should just had looked into LCL, lol
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i unit
LCLTaskDialog; { LCLTaskDialog.pas
----------------- Implement TaskDialog window
(native on Vista/Seven, emulated on XP). This unit was originally a
part of the freeware Synopse mORMot framework, licensed under a
MPL/GPL/LGPL tri-license; version 1.19. Synopse framework.
Copyright (C) 2016 Arnaud Bouchez Synopse Informatique -
http://synopse.info
----------------------------------------------------------------------
Martin_fr · 2022-09-19 19:33
It seems some of the discussed items are going in cycles now.
So maybe there are misunderstandings? If I did lack clarity somewhere
then I am sorry for that.
Also to point out: Some of my later statements included (implied)
withdrawals of prior questioning of ideas.
Also apparently for some items the separation of their context to the
context of other items in the message where I introduced them (or even
other messages), may not have been made clear enough. E.g. the
question of the help button had been made based on the expressed
assumption of mine that such a help button would be a new concept and
was not yet present anywhere. I then found my assumption wrong (i.e.,
help buttons are already in use) and hence withdraw my concerns. The
context of checking with the team had been as mentioned based on this
being a fundamentally new concept, and that even though not explicitly
mentioned had been discovered not to be the case. Again, sorry about
this.
So to remove any doubt:
This https://forum.lazarus.freepascal.org/index.php/topic,60624.msg454
194.html#msg454194
=> radio + one embedded "link button" for "run without dbg"
With the addition that one radio must be preselected.
The link to become a help button.
Is 100% ok.
I will merge/apply this.
No backsies on this.
As mentioned all captions must be initialized from resource strings
(IIRC unit LazarusIdeStringConst)
I also stand by my prior word, that for this one patch/merge-request I
will accept it against fixes branch, if it can be cherry picked to
main without major merge conflicts. (tree conflicts/ chunks of more
than a dozen lines conflicting)
It will very most likely only appear in the main branch.
I am happy to assist further with the help system, or the new debugger
procedure, as soon as I see a first patch against actual IDE code
(I.e. not just the form, but IDE code actually creating/calling that
form.)
Hope that covers it.
----------------------------------------------------------------------
Martin_fr · 2022-09-19 19:42
overlapped with my previous post...
Quote from: Arioch on September 19, 2022, 09:28:56 pmSad point, i
tried to cherry-pick your commits into Fixes_2_2 and got conflicts...
Maybe because my Fixes_2_2 is dirty
Which commits? And cherry pick to where?
Normally all commits in fixes are in main, and where picked from
there.
Quote2. No, like i said, fixing design first. I do not want to make
elaborate work only for it to be discarded and said to be not-
Lazarish. One time is enough. Agreement on design first, implementing
later.
Ok, then simply set the first radio to be the default.
Quote3. The concept is not new, but it was deliberately removed from
MS TaskDialog.
So, we are back to square one - either drop TaskDialog and design
custom window, or drop Help button, that never was there to start
with.
Ok here we have miscommunication.
I am missing completely what you mean?
Which concept?
And are we talking about the TTaskDialog in the LCL? (Which I hope
(not tested) to work on all platforms....)
Or something else?
QuoteSo, neither Help button nor hyperlinks in the task dialog.
If you need them - then make custom window instead.
Try a button and tfUseCommandLinks with the LCL control.
At least on Windows that shows radios, and a flat-button-like
It seems the main missing issue is, that no one checked yet what will
happen on other OS.
----------------------------------------------------------------------
Arioch · 2022-09-19 20:03
Quote from: Martin_fr on September 19, 2022, 09:42:50 pmWhich commits?
And cherry pick to where?
i'll check tomorrow on vanilla Fixes_2_2, mine is polluted currently
QuoteNormally all commits in fixes are in main, and where picked from
there.
I am not Lazarus hacker, not yet at least. I am user who contributes
when he can.
QuoteQuote3. The concept is not new, but it was deliberately removed
from MS TaskDialog.
So, we are back to square one - either drop TaskDialog and design
custom window, or drop Help button, that never was there to start
with.
Ok here we have miscommunication.
I am missing completely what you mean?
Which concept?
concept of having non-modal HELP button in an otherwise modal
TTaskDialog.
ANY button would close the dialog, even if ModalResult = 0
QuoteAnd are we talking about the TTaskDialog in the LCL? (Which I
hope (not tested) to work on all platforms....)
Both. VCL dialog is wrapper over Windows Vista API
LCL dialog is wrapper over Vista API when it present, and re-
imlpementation of SUBSET of Windows API otherwise.
This means, on Windows LCL dialog would look exactly as VCL or any
other Windows-native.
BUT will miss some behavior functonality.
The pieces that mORMot did not re-implement in cross-platform way -
they did not expose in API.
In particular that is hyperclick link - yes it is RENDERED on Windows,
but it has noi any aciton to it, because LCL TTaskDialog did not
implement the required events in x-platform way.
And implementing it in x-platform way would require limited HTML
rendered inside LCL. Which would not happen soon.
So,
- non-closing HELP button would not be in Taks Dialog, because
Microsoft deliberately precludes it.
- Hyperlink would not work in LCL TaskDialog, because it is not
implemented.
- Even if hyperlink worked on Windows alone - it still would not be
usable on non-Windows, so could not be relied upon
- Now, you can do a dirty trick: add the Help button, that would close
dialog and then immediately show it again
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i Choice:
TModalResult; repeat Choice := TaskDialog1.Execute(); if Choice <>
mrHelp then exit; // command to show LHelp or WWW helpuntil false;
Would you want SUCH a hack?
If not - you have a binary choice.
Either give up on TTaskDialog, or give-up on help (button or hyperlink
- both don't work) in the task dialog.
This - or that.
----------------------------------------------------------------------
Arioch · 2022-09-19 22:32
All in all, if you want to extend TTaskDialog to make it x-platform -
that is a noble goal, but i believe it is outside FpDebug scope.
Let's create a separate thread and talk there.
The immediate things would be
- reach Arnaud and ask if they gave up on Task Dialog or not. Is
mORMot TaskDialog upstream or LCL is ? PErsonally i'd rather hack on
mORMot with its Delphi compatibility, than FPC-only LCL. But in the
end it is about "who is upstream now".
- persuade LCL team to include any simple fast HTML renderer into the
core. We did not have to have fast and flexible solution, like thta
commercial Delphi HTML components. We probaly would not even need as
much as THtmlFrame. But ascending JediVCL HTML Label or something of
equaly complexity would be called for.
D:\fpcupdeluxe\ccr\jvcl\run\JvCtrls\jvhtcontrols.pas
D:\fpcupdeluxe\ccr\jvcl\run\JvNet\jvhtmlparser.pas
Or anything similar. Google shows
https://github.com/jackdp/DzHTMLText2 and
https://laptrinhx.com/delphi-and-lazarus-html-label-
component-4127787442/
Officially Microsoft only accepts HTML A-tag and nothing else. But
implementing ad-hoc anchor-only parser, and then rendered to
supplement it, should we really do it? https://learn.microsoft.com/en-
us/windows/win32/api/commctrl/ns-commctrl-taskdialogconfig
This is probably worth doing, but the amount of time and energy to to
make it ascend into LCL core would be.... substantial. Hence would be
past the timeline you set to FPDebug enhancement. Albeit on its own
merit that seems a worthy task.
----------------------------------------------------------------------
Martin_fr · 2022-09-20 00:09
Quote from: Arioch on September 19, 2022, 10:03:19 pmQuoteWhich
concept?
concept of having non-modal HELP button in an otherwise modal
TTaskDialog.
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i procedure
TForm1.TaskDialog1ButtonClicked(Sender: TObject; AModalResult:
TModalResult; var ACanClose: Boolean);beginend; Looks promising.
Tested on Linux and Windows, it works.
Not tested on Windows (nor Mac)
The other Issue => there is no build in "help" button. => and if the
custom buttons where to go up into the main area => then how to get a
help button.
Also that means there would be no way for a "help" button on the left
side, with all other buttons aligned towards the right side.
Or did I miss something.
QuoteQuoteAnd are we talking about the TTaskDialog in the LCL? (Which
I hope (not tested) to work on all platforms....)
Both. VCL dialog is wrapper over Windows Vista API
LCL dialog is wrapper over Vista API when it present, and re-
imlpementation of SUBSET of Windows API otherwise.
This means, on Windows LCL dialog would look exactly as VCL or any
other Windows-native.
BUT will miss some behavior functonality.
Tested under Linux. Mostly ok.
Only the buttons (if tfUseCommandLinks*) is set, will always be above
the radios.
Not yet looked at MacOs.
QuoteAll in all, if you want to extend TTaskDialog to make it
x-platform - that is a noble goal, but i believe it is outside FpDebug
scope.It may already be... With tiny differences/limits...
Quote- reach Arnaud and ask if they gave up on Task Dialog or not. Is
mORMot TaskDialog upstream or LCL is ? PErsonally i'd rather hack on
mORMot with its Delphi compatibility, than FPC-only LCL. But in the
end it is about "who is upstream now".
Even if, that will be a hold back. And I wont be able to mediate all
of that.
Lets see how far we can get with what is there. Then lets see what
needs adding.
Quote- persuade LCL team to include any simple fast HTML renderer into
the core. We did not have to have fast and flexible solution, like
thta commercial Delphi HTML components. We probaly would not even need
as much as THtmlFrame. But ascending JediVCL HTML Label or something
of equaly complexity would be called for.
There is one for the IDE hints ...IPro... package
But same as above.
That might mean to defer the Help button => but the initial goal to
reduce the width would be reached.
Also: a run without debug.
And even if the pre-select is not smart to begin, that will be easy to
add, and help the user with the choice.
// Tests for Mac assumed to succeed.
----------------------------------------------------------------------
PascalDragon · 2022-09-20 07:50
Quote from: Arioch on September 19, 2022, 03:42:12 pmIf anyone gets
interested to evaluate their code and maybe copy it into LCL, then
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.pas -
"licensed under a MPL/GPL/LGPL tri-license; version 1.18"
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.rc
Please note that this license is not compatible with the license used
with the LCL cause the LCL uses LGPL-with-static-linking-exception,
but mORMot uses the unmodified LGPL.
----------------------------------------------------------------------
Arioch · 2022-09-20 09:42
Quote from: PascalDragon on September 20, 2022, 09:50:05 amQuote from:
Arioch on September 19, 2022, 03:42:12 pmIf anyone gets interested to
evaluate their code and maybe copy it into LCL, then
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.pas -
"licensed under a MPL/GPL/LGPL tri-license; version 1.18"
https://github.com/synopse/mORMot/blob/master/SynTaskDialog.rc
Please note that this license is not compatible with the license used
with the LCL cause the LCL uses LGPL-with-static-linking-exception,
but mORMot uses the unmodified LGPL.
Oh, way too many licenses out there...
But anyway, after i checked LCL sources belatedly, they already
donated their to LCL. So, moot point from my part it was.
Now, i think TaskDialog talk here goes vicious circle.
Should LCL x-platformly re-implement missed HTML+hyperlinks
funcitonality of TaskDialog? Maybe.But it is beyond FpDebug talk andis
worth a separate backburner thread.
Should FPDebug use TaskDialog or custom one ? Depends whether adding
"visible HELP button" functionality is required or "quick drop-in
replacement" is preferred. Both are fine by me, but the choice has to
be made by Team Lazarus.
----------------------------------------------------------------------
Arioch · 2022-09-20 09:46
Quote from: Martin_fr on September 20, 2022, 02:09:07 amQuote-
persuade LCL team to include any simple fast HTML renderer into the
core. We did not have to have fast and flexible solution, like thta
commercial Delphi HTML components. We probaly would not even need as
much as THtmlFrame. But ascending JediVCL HTML Label or something of
equaly complexity would be called for.
There is one for the IDE hints ...IPro... package
"for the IDE" - irrelevant. TTaskDialog is for desktop user's apps,
outside of IDE. Whatever new code TTaskDialog would use - would have
to be moved to RTL/LCL/whatever core *runtime* packages end-user apps
must use anyway.
The CanClose thing i missed, maybe indeed it can do
----
One more thing missed in LCL/mORMot rather that pure Win32 wrapper
----------------------------------------------------------------------
Arioch · 2022-09-20 10:03
Default choice in "pushbutton" mode, native Win32, Delphi vs LCL
To me, Default rendering with CommandButtons is VERY faint, and is
less pushy" then mere mouse-hover effect.
On the fence, whether that is good or bad thing.
Personally i am against default choices, so it is good.
But "pure one-click" solution would ask to get rid of radiobuttons at
all and only use veritcally stacked pushbuttons, then "faint default"
would be bad
Then again, the lack of extended hint in LCL is... disturbing. I too
kit for granted.
To me "Run no debug" without immediately visible extended hint seems a
big loss.
----------------------------------------------------------------------
zamtmn · 2022-09-20 10:25
Arioch
Show how these dialogs will look in other widgesets. I'm afraid we
will have a bad surprise((
----------------------------------------------------------------------
Arioch · 2022-09-20 11:05
Quote from: zamtmn on September 20, 2022, 12:25:26 pmArioch
Show how these dialogs will look in other widgesets. I'm afraid we
will have a bad surprise((
i can not - https://forum.lazarus.freepascal.org/index.php/topic,60531
.msg453747.html#msg453747
also, ATM i am more inclined to recall the TTaskDialog idea and rather
do separately with short-term custom window for FPDebug immediate need
and slow long term enhancement of TaskDialog for the "greater good"
----------------------------------------------------------------------
wp · 2022-09-20 13:46
Quote from: zamtmn on September 20, 2022, 12:25:26 pmShow how these
dialogs will look in other widgesets. I'm afraid we will have a bad
surprise((
Played with the LCL TaskDialog and tried to create an adapted version
of the screenshot in reply #27. Here's my result for Win11, Linux-
Mint-gtk2, mac Mojave, and for comparison Delphi XE 10.4 (on Win 11).
They are all pretty much the same (except for Delphi which does not
have the option tdiQuestion for the FooterIcon). (The order of the OK
and Cancel buttons (or all buttons?) should be reworked in the non-
Windows version of the LCL Taskdialog).
----------------------------------------------------------------------
Martin_fr · 2022-09-20 15:23
Quote from: Arioch on September 20, 2022, 01:05:29 pmalso, ATM i am
more inclined to recall the TTaskDialog idea and rather do separately
with short-term custom window for FPDebug immediate need and slow long
term enhancement of TaskDialog for the "greater good"
Sorry, but no.
I made a clear statement what will be accepted
Quote from: Martin_fr on September 19, 2022, 09:33:52 pmSo to remove
any doubt:
This https://forum.lazarus.freepascal.org/index.php/topic,60624.msg454
194.html#msg454194
=> radio + one embedded "link button" for "run without dbg"
With the addition that one radio must be preselected.
The link to become a help button.
Is 100% ok.
I will merge/apply this.
No backsies on this.
As mentioned all captions must be initialized from resource strings
(IIRC unit LazarusIdeStringConst)
I also stand by my prior word, that for this one patch/merge-request I
will accept it against fixes branch, if it can be cherry picked to
main without major merge conflicts. (tree conflicts/ chunks of more
than a dozen lines conflicting)
It will very most likely only appear in the main branch.
I am happy to assist further with the help system, or the new debugger
procedure, as soon as I see a first patch against actual IDE code
(I.e. not just the form, but IDE code actually creating/calling that
form.)
Re-reading it: "The link to become a help button." refers to the ""
embedded link in the text.
I further stated:
Quote from: Martin_fr on September 19, 2022, 09:42:50 pmQuote from:
Arioch on September 19, 2022, 09:28:56 pm2. No, like i said, fixing
design first. I do not want to make elaborate work only for it to be
discarded and said to be not-Lazarish. One time is enough. Agreement
on design first, implementing later.
Ok, then simply set the first radio to be the default.
It seems the main missing issue is, that no one checked yet what will
happen on other OS.
On the last point: If any part is not possible, leave it out for now.
I have concrete ideas (based on the LCL TaskDialog) how to solve them.
But I will not go there, before I do have code that can be
successfully applied to the IDE.
For now (more than) enough options were explored: It is "whatever of
the above is possible with the existing LCL TaskDialog" as first step.
Quote from: Martin_fr on September 20, 2022, 02:09:07 amTested under
Linux. Mostly ok.
Only the buttons (if tfUseCommandLinks*) is set, will always be above
the radios.
That might mean to defer the Help button => but the initial goal to
reduce the width would be reached.
Also: a run without debug.
And even if the pre-select is not smart to begin, that will be easy to
add, and help the user with the choice.
If a help button has to be deferred it goes into stage 2.
----------------------------------------------------------------------
Arioch · 2022-09-20 15:37
Taskdialog itself:
https://forum.lazarus.freepascal.org/index.php?topic=60652.new#ne
----------------------------------------------------------------------
Arioch · 2022-09-20 15:43
I patched LCL to never use native API, even on Windows. I confirm the
reversed opsitioning of command buttns vs radiobutotns.
https://forum.lazarus.freepascal.org/index.php?action=dlattach;topic=6
0652.0;attach=50880;image
The event hack to prevent closing on Hepl button works, so given this
is pure-LCL button should work on every platform.
But the non-implementaiton of "command hints" (lesser, secondary
button caption), makes warning user about non-closing behavior of Help
impossible.
----------------------------------------------------------------------
Martin_fr · 2022-09-20 15:53
As I said, I have ideas how to resolve that. But I wont bother writing
them up, until I have code that runs in the IDE for those parts that
do work (I.e just the radios...)
----------------------------------------------------------------------
Arioch · 2022-09-20 16:06
Can you fix the radiobuttons vs common buttons placement ?
needs just swapping two if-blocks around.
can you apply to both main and Fixes_2_2 ?
----------------------------------------------------------------------
Martin_fr · 2022-09-20 16:16
It's based on one of the flags (use...links).
Can be done. Once their is a need. I.e. once there is code.
----------------------------------------------------------------------
Arioch · 2022-09-20 16:19
That being said,
1) would you prefer
a) no push-button for Help at all (no help function at all)
b) Help Button
2) positioning of buttons, horizontal or vertical ?
3) if vertical - with "arrow" pictures or without? I found no way to
make pictures different.
IMHO "arrow" on help button reinforces wrong impression
4) if vertical, should "help" be the last (bottom) one, or go between
radio-buttons and "run with no debug" ?
----------------------------------------------------------------------
Arioch · 2022-09-20 16:23
Quote from: Martin_fr on September 20, 2022, 06:16:40 pmIt's based on
one of the flags (use...links).
Can be done. Once their is a need. I.e. once there is code.
Guess you missed the point.
Compare three pictures, focus on radiobuttons and "big buttons". Which
are top and which are below
Windows native (on the right) - https://forum.lazarus.freepascal.org/i
ndex.php?action=dlattach;topic=60624.0;attach=50866;image
Current LCL - https://forum.lazarus.freepascal.org/index.php?action=dl
attach;topic=60624.0;attach=50882;image
After the patch - https://forum.lazarus.freepascal.org/index.php?actio
n=dlattach;topic=60624.0;attach=50884;image
The implementation was wrong, flags don't fix it, only the patch
(trivial, swapping two code blocks)
----------------------------------------------------------------------
Martin_fr · 2022-09-20 16:43
Quote from: Martin_fr on September 20, 2022, 06:16:40 pmOnce their is
a need. I.e. once there is code.
----------------------------------------------------------------------
Arioch · 2022-09-20 17:07
oookay, then i go with the 1st variant, horizontal small buttons
----------------------------------------------------------------------
Martin_fr · 2022-09-20 17:28
Quote from: Arioch on September 20, 2022, 07:07:01 pmoookay, then i go
with the 1st variant, horizontal small buttons
Ok
----------------------------------------------------------------------
Arioch · 2022-09-20 17:29
Quote from: Martin_fr on September 19, 2022, 01:22:04 amThere is a
"help system" in the IDE, and a file with all the links in the docs
folder.
The help button has to use that existing system.
ide\codetemplatesdlg.pas
LazarusHelp.ShowHelpForIDEControl(Self);
This won't do....
There is no any control to call the help over.
The original code was
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i case
IDEQuestionDialog(lisEnableOptionDwarf,
Format(lisTheProjectDoesNotUseDwarf, [DebugClass.Caption]),
mtConfirmation, [1 {mrOk}, lisEnableOptionDwarf2Sets,
12, lisEnableOptionDwarf2, 13,
lisEnableOptionDwarf3, mrCancel])
Here is one more parameter const HelpKeyword: string = '') - unused
All the calls in D:\fpcupdeluxe\lazarus_deb\ide\main.pp also lack this
parameter. And rightfully so....
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i function
QuestionDlg(const aCaption, aMsg: string; DlgType: TMsgDlgType;
Buttons: array of const; const HelpKeyword: string):
TModalResult;begin // TODO: handle HelpKeyword Result :=
QuestionDlg(aCaption, aMsg, DlgType, Buttons, 0);end;
Basically, you just do not have it in IDE Help system to call help
over some (potentially extensible) string ID
Can you debug CallStackDialog and find how it does open WWW wiki
window?
Is there at least some semi-official semi-unified way or a total ad
hoc ?
----------------------------------------------------------------------
Arioch · 2022-09-20 17:54
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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i // Setup
debugger if not SkipDebuggerThisTime then if not
DebugBoss.InitDebugger then begin debugln(['Info: (lazarus)
[TMainIDE.DoInitProjectRun] DebugBoss.InitDebugger failed']);
Exit; end;
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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i function
TMainIDE.DoRunProject: TModalResult;var Handled: Boolean;begin
DebugLn('Hint: (lazarus) [TMainIDE.DoRunProject] INIT'); if
(DoInitProjectRun <> mrOK) or (ToolStatus <> itDebugger) then begin
Result := mrAbort; Exit; end; debugln('Hint: (lazarus)
[TMainIDE.DoRunProject]
Debugger=',DbgSName(EnvironmentOptions.CurrentDebuggerClass));
and make a custom mrResult code for it
this code anyway has ot be fixed, it is obviously wrong...
GUI-only patch attached
----------------------------------------------------------------------
Martin_fr · 2022-09-20 17:55
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 · 2022-09-20 17:57
...or not
QuoteD:\fpcupdeluxe\lazarus_deb\components\debuggerintf\dbgintfdebugge
rbase.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 · 2022-09-20 18:06
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 · 2022-09-20 20:40
> 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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i if
(DoInitProjectRun <> mrOK) or (ToolStatus <> itDebugger) then begin
Result := mrAbort; Exit; 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 · 2022-09-20 21:12
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
----------------------------------------------------------------------
Martin_fr · 2022-09-20 21:47
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 · 2022-09-21 16:00
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 · 2022-09-21 16:48
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 :-)
QuoteAdd "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.
QuoteAdd 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.
----------------------------------------------------------------------
Martin_fr · 2022-09-22 20:52
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....
Quote from: Arioch on September 21, 2022, 06:48:52 pm> - 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.
QuoteWell, 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)
Quote4. 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?
QuoteWell, 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.
Quotedid you notice how we are sliding into spec-making, BTW ? oh,
okay, techwriting sucks, i know :-)
I'd call it collecting ideas...
QuoteQuoteAdd "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.
QuoteQuote (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)
QuoteSurely 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.
QuoteIf 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 · 2022-09-22 23:15
After WP implemented "Test dialog" in IDE testing look and feel could
be done without coding IMHO.
Quote from: Martin_fr on September 22, 2022, 10:52:09 pmSorry, 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.
QuoteAt 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.
QuoteBut, 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
QuoteQuote4. 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.
QuoteQuoteStill 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.
QuoteQuoteI 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 :-)
QuoteIf 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.
QuoteQuoteSurely 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.
QuoteQuoteIf 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 · 2022-09-23 01:07
Quote from: Arioch on September 23, 2022, 01:15:26 amQuoteAt 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 · 2022-09-23 01:29
Quote from: Arioch on September 23, 2022, 01:15:26 amQuoteBut, 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
QuoteQuote4. 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.
QuoteThat 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"....
QuoteMaybe 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.
QuoteVertical 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
QuoteThis 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.
QuoteHowever, 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
QuoteAdding 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.
QuoteThat 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 · 2022-09-23 17:22
Quote from: Martin_fr on September 23, 2022, 03:29:34 amQuoteThat
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.
QuoteThe 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.
QuoteQuoteHowever, 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.
----------------------------------------------------------------------
Martin_fr · 2022-09-23 18:13
Quote from: Arioch on September 23, 2022, 07:22:53 pmBorrowing 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.
----------------------------------------------------------------------
Martin_fr · 2022-09-23 18:25
Googling examples shows that the most common way is to have a "for
more info go " 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 · 2022-09-23 19:08
Quote from: Martin_fr on September 23, 2022, 08:13:22 pmUnless 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
QuoteWe 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
QuoteAvoid 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.
----------------------------------------------------------------------
Martin_fr · 2022-09-23 19:57
Quote from: Arioch on September 23, 2022, 09:08:10 pmMicrosoft 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 · 2022-09-23 22:45
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 · 2022-09-26 23:19
Quote from: Martin_fr on September 23, 2022, 09:57:11 pmSo 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.
Quote from: Martin_fr on September 24, 2022, 12:45:08 amAnd 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.
Quote from: Martin_fr on September 24, 2022, 12:45:08 amThe 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 · 2022-09-27 08:24
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 · 2022-09-27 10:38
Quote from: wp on September 27, 2022, 10:24:42 amIn 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.
QuoteAnd 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.
QuoteWhy 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....
QuoteI 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 · 2022-09-27 10:46
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.
QuoteNow 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.
QuoteAnd 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.
Quote99% 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 :-)
QuoteTherefore 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..
Quoteit 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 opinionEven 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 priorityEven 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".
QuoteAnd 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".
QuoteThe 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 · 2022-09-27 11:12
Quote from: Arioch on September 27, 2022, 12:46:03 pmWe 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....
QuoteSo, 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 · 2022-09-27 11:27
Quote from: Martin_fr on September 27, 2022, 01:12:52 pmQuote from:
Arioch on September 27, 2022, 12:46:03 pmWe 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.
QuoteWhatever 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?acti
on=dlattach;topic=60624.0;attach=50814;image
WP, did you participate during 2nd page infighing? :-D
----------------------------------------------------------------------
Martin_fr · 2022-09-27 11:42
Quote from: Arioch on September 27, 2022, 01:27:50 pmQuote from:
Martin_fr on September 27, 2022, 01:12:52 pmQuote from: Arioch on
September 27, 2022, 12:46:03 pmWe 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.
QuoteMaking 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 · 2022-09-27 11:55
Quote from: Martin_fr on September 27, 2022, 01:42:57 pmAnd 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.
----------------------------------------------------------------------
Martin_fr · 2022-09-27 12:04
Quote from: Arioch on September 27, 2022, 01:55:26 pmQuote from:
Martin_fr on September 27, 2022, 01:42:57 pmAnd 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 · 2022-09-27 12:11
...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.
----------------------------------------------------------------------
wp · 2022-09-27 13:25
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...
----------------------------------------------------------------------
Arioch · 2022-09-27 14:21
Quote from: wp on September 27, 2022, 03:25:17 pmAnother screenshot,
now from Linux Mint (gtk2), switched to 192ppi screen resolution. At
least while these scaling issues are not fixed, we should return to
the old dialog...
can you show other forms for comparison? and maybe thewhole desktop
with proper and impproper forms/dialogs
I see problems with having no bitmaps of larger size (does stock LCL
has something like TSVGBitmap for glyphs?), but as for the rest i do
not see "problems" but rather a window being rendered despite a very
limiting environment.
----------------------------------------------------------------------
Martin_fr · 2022-09-27 14:40
Maybe it is enough to set Dialog.Form.Scaled=True
lcl\lcltaskdialog.pas line 840
Dialog.Form := ]"]>BlockedlatedTaskDialog.CreateNew(Application);
Otherwise line 860
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
aWidth := Dialog.Form.Canvas.TextWidth(Inst); if (aWidth>300) or
(Dialog.Form.Canvas.TextWidth(Content)>300) or
(length(Buttons)>40) then aWidth := 480 else aWidth :=
420;
needs to be scaled for DPI / or relative to the screen width
----------------------------------------------------------------------
Arioch · 2022-09-27 14:47
Quote from: Martin_fr on September 27, 2022, 04:40:22 pmOtherwise line
860 needs to be scaled for DPI / or relative to the screen width
Do you remember a joke about daughter, driving her car in wrong lane?
You would not have to scale "line 860" but ALL of the procedure, where
all the controls and their bounds are ad hoc calculated wit hpixel
accuracy (up to the point of "on Windows add 1 px, on Linux do not")
So, in the end it would be, IMHO, more simple to drop that code and
just make a regular window in Form Designer using .AutoSize and .Align
on most if not all controls.
----------------------------------------------------------------------
wp · 2022-09-27 20:55
So, go ahead...
----------------------------------------------------------------------
wp · 2022-09-28 11:02
Fixed scaling. Tested on Linux @192ppi --> some issues left (why is
the row of buttons wrapped?)
----------------------------------------------------------------------
wp · 2022-09-28 20:13
Ondrej fine-tuned it, and now it's correctly scaled.