Recent

Author Topic: TTaskDialog musings  (Read 1719 times)

zamtmn

  • Hero Member
  • *****
  • Posts: 523
Re: TTaskDialog musings
« Reply #15 on: September 21, 2022, 12:52:22 pm »
The answer is from another topic, about colors.
I think that we need some kind of centralized method of selecting the color of the text by background and the background by the text. So that the result is somehow similar to the system colors. It will not be possible to just do with clXXXX constants, there will always be "bad" color themes

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: TTaskDialog musings
« Reply #16 on: September 21, 2022, 01:55:33 pm »
Strangely tfUseHiconMain affects their location and style

Also tfUseHiconMain,

It is not "affecting location", it is switching form Native to LCL-emulated.
It is non-Windows extended feature, most probably.

There is more to it, but it is gladly not exposed on dialogs.TTaskDialog level.
They took lazy approach with Flags though.

And frankly, would Windows and VCL  ever add more flags - the very idea of extending binary bitset with custom flags would lead to troubles.
However, mere hiding from Object Inspector could be had done by the trivial reduced enum type...
Shoud be done, perhaps.

For example, there is (in emulation) an option to turn "verificationText" from a checkbox to a combo drop-down list or radiogroup (according to comments, did not test)
Another example is to emed TEdit into the dialog, so free-form response from user can be asked for, effectively replacing simplistic InputQuery and InputBox dialogs.

https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Dialogs.InputQuery

If you are curious, skim through top comments in LCLTaskDialog looking for Selected... and Quesry... properties being mentioned.

I can sympathisize with both mORMot's desire ot have TEdit because why not, and MS desire to not have, because ugly and breaks tablets-freendly design

----

Not sure what could be a proper design with all this.

DevExpress' Quantum Grid, for example, has a property to chose a database backend from a drop-down list of registered ones, then extended properties appear as sub-properties of selected back-end object. Same can be done with Task-dialog, if to separate Win32 and Natice implementations into totally separate classes (right now they are just two execution paths within one long procedure). This would allow for keeping bare-bones LCL implementation and then adding a 3rd full-feature implementation, for example based on HTML rendered through THtmlFrame package

TTaskDialog itself then would only expose bare-bone properties, and extended one going to sub-properties of an implementation, with default auto-implementation adding none.

Related concern is that currently Lazarus is totally broken when loading a non-found property. In Delphi i regularly switch to direct DFM editing, like when i need to change component type (recent example, you asked me why TStaticText in the proposed DWARF-choosing dialog, and indeed, it had to be TLabel). In Delphi it is a mundane "skip this property?" confirmatin, in Lazarus it is death of IDE.

So, how should Delphi project be imported to Lazarus then, when Delphi expose more properties (especialyl events) ???

Should those all properties be published (to facilitate DFM import) and then forcibly hidden from OI (typical Delphi trick was setting OI property setter to nil procedure, it auto-hid the property as misconfigured)?

Ideally, DFM Import should be an "official feature" of IDE, rather than a separate project, so each LCL component would be encouraged to register itself as some DFM components handler, and have a special loading control flow to import form DFM not LFM.

Another approach would be just making two components  on the palette, one striving at Delphi/Windows compatibility, and another pure LCL caring about nothing and implemented everything LCL developers would think is  good-to-have

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: TTaskDialog musings
« Reply #17 on: September 21, 2022, 02:02:14 pm »
selecting the color of the text by background

like i said, if Abs(Brightness(FontColor) - Brightness(BackColor)) < threshold then FontColor := { Black Or White Opposite to background }

more elborate schemes would require "colors theory" selecting colours from all the palette to make some theoretically pleasant pair, but actually not even that - you would first have to determine all the currently active "screne area" - which is maybe the current TForm, but maybe is several forms, all forms of TApplication, or maybe just all the windows of all the applications...

Uncertainties start snowballing.

and the background by the text.

big NO.

while black or white text is limited ugliness while preserving the window's vague general uniformity, changing background would create a big contrast patch of a very different (to adjacent ocntrols) colour.

that would be ugly

wp

  • Hero Member
  • *****
  • Posts: 10300
Re: TTaskDialog musings
« Reply #18 on: September 21, 2022, 02:29:27 pm »
The answer is from another topic, about colors.
I think that we need some kind of centralized method of selecting the color of the text by background and the background by the text. So that the result is somehow similar to the system colors. It will not be possible to just do with clXXXX constants, there will always be "bad" color themes
The system colors usually come in pairs such as clWindow - clWindowText, clHighlight - clHighlightText, clInfoBk - clInfoText. Unfortunately for some colors it is hard to decide whether they are used as background or foreground color (at least without some work). But anyway, Arioch's hint on clHotLight (why didn't they call it clHotText if it used for hyperlinks?) is an interesting tip: zamtmn, could you check whether this could serve in dark mode as a replacement for the $B00000 in the original code?

zamtmn

  • Hero Member
  • *****
  • Posts: 523
Re: TTaskDialog musings
« Reply #19 on: September 21, 2022, 02:41:18 pm »
The answer is from another topic, about colors.
I think that we need some kind of centralized method of selecting the color of the text by background and the background by the text. So that the result is somehow similar to the system colors. It will not be possible to just do with clXXXX constants, there will always be "bad" color themes
The system colors usually come in pairs such as clWindow - clWindowText, clHighlight - clHighlightText, clInfoBk - clInfoText. Unfortunately for some colors it is hard to decide whether they are used as background or foreground color (at least without some work). But anyway, Arioch's hint on clHotLight (why didn't they call it clHotText if it used for hyperlinks?) is an interesting tip: zamtmn, could you check whether this could serve in dark mode as a replacement for the $B00000 in the original code?
of course, there just became too many topics and text

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: TTaskDialog musings
« Reply #20 on: September 21, 2022, 04:40:01 pm »
i believe you could just look in the Lazarus itself, any TForm has Color property, so...

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: TTaskDialog musings
« Reply #21 on: September 21, 2022, 05:00:25 pm »
The system colors usually come in pairs such as clWindow - clWindowText, clHighlight - clHighlightText, clInfoBk - clInfoText.

Yet they were directly applied only in 2D looks of Windows 3.x and even DOS Shell

As soon as MS Office 6.0 for Win16 introduced 3D look (and then Win95 and WinNT4 embraced it) - it became convoluted.
It became common point for text of element Y assume the background colour of elemnt Y or vice versa, because that way it was looking slick.

if you would look into VCL sources for properties like Ctrl3D or FlatXXXX mentioned in sources - you would find those examples.
Especially in early Delphi ( Ctrl3D used to make the same program look differently under Win3.1 and Win95, then it was gradually phased out and removed form public VCL API, but traces of it still occasionally found in VCL sources)

wp

  • Hero Member
  • *****
  • Posts: 10300
Re: TTaskDialog musings
« Reply #22 on: September 21, 2022, 06:52:56 pm »
And just found another issue: Switched my Linux VM to High-DPI - the emulated TaskDialog is not ready for high-dpi, it does not scale.

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: TTaskDialog musings
« Reply #23 on: September 21, 2022, 07:15:17 pm »
yeah, it is hard-coded on per-pixel level

and frankly, VCL design is very bad in scaling.

in 16-bits time the decision to use pixels instead of abstract split-pixel "typographic points" (used by Widows GDI) saved a lot of memory and CPU cycles. Today we pay the price...

from experience, just working with the same DFM files with Delphi IDE run on Windows machines with display set to 96DPI and 120DPI resulted in very bad and quickly snowballing rounding errors

there even was a project on github, TBaseForm = class (TForm), seeking to comlement / replace functions of stock VCL, and scaling/aligning was one of them

LCL dialog should be reformulated as a set zero-border panels with .Align set and .BorderSpacing (in LCL terms, in VCL those are .Margins), then .Scaling := True and cross your fingers and pray it would work.

The premonitions about HighDPI also was one of my thought making implementing the dialog via THTMLFrame crossed my mind.
In general i abhor HTML as widgets toolkit.

I believe it was one of factors why Microsoft canned the original, written in Delphi Skype and started anew with Electron/JS.

But remember - there already was complain about Lazarus Form Designer on High-DPI screen yesterday, this early LCL/VCL design choice consequences would be recurring now.

On Windows 8+ the best course is setting Display scale 200% - it just turns every logic pixel into 2x2 physical px for non-adapted applications.

Now, recent Delphi versions claim they managed to solve it, but i did not look if they did. Community edition have no sources, and i don't feel like downloading pirated Delphi just for that. I prefer XE2 and "devil i know".

P.S. from a personal COVID lockdowns experience: on Windows you can have HighDPI (200%) Windows connecting by RDP to office machine (Win7 or 8) running the 125% (120PPI) mode, an then running applications written for standard (96PPI) mode. Now THAT's the fest of rounding errors and .Align's going amok.
« Last Edit: September 21, 2022, 07:18:47 pm by Arioch »

wp

  • Hero Member
  • *****
  • Posts: 10300
Re: TTaskDialog musings
« Reply #24 on: September 21, 2022, 07:27:28 pm »
zamtmn, could you check whether this could serve in dark mode as a replacement for the $B00000 in the original code?
No so good... I played a bit with the themes on my Linux-VM and found clHighlight to be fine in all cases that I visited. However, I don't have access to qt/qt5 ATM. zamtmn, would you be so kind to check this color, too?

zamtmn

  • Hero Member
  • *****
  • Posts: 523
Re: TTaskDialog musings
« Reply #25 on: September 21, 2022, 08:20:02 pm »
Yes, this is the best color

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: TTaskDialog musings
« Reply #26 on: September 21, 2022, 08:32:17 pm »
...in this theme

but chances are in the hundreds of themes floating around there would be those where clHighlight would not be good choice :-(

in the end, we are doing guesswork after looking at some few (1 or 20 or maybe 10, hardly more) of selected themes

P.S. ...andthen there are also GTK2 and GTK3 with their own themes

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: TTaskDialog musings
« Reply #27 on: September 21, 2022, 09:39:06 pm »
i wonder if slick button animation is required...

https://github.com/jackdp/JPPack/raw/master/docs/img/TJppBasicPngButtonEx.png  - this looks good, but is said to be Delphi-only

But then i thought that TPanel can be a replacement of TBitBtn with two captions.

Border/Bevel can to extent simulate button's borders. But animatiionf of mouse hovering or pressing would be much more rough.

Of course one can just implement such a button on top of TButton ot TBitBtn too, feigning empty caption to OS, and then making it custom-painted. Which then would be bound to look more or less distinct from native buttons of OS.

But TPanel is already there :-)

wp

  • Hero Member
  • *****
  • Posts: 10300
Re: TTaskDialog musings
« Reply #28 on: September 21, 2022, 10:11:22 pm »
...in this theme

but chances are in the hundreds of themes floating around there would be those where clHighlight would not be good choice :-(

in the end, we are doing guesswork after looking at some few (1 or 20 or maybe 10, hardly more) of selected themes

P.S. ...andthen there are also GTK2 and GTK3 with their own themes
And the green bitmap arrows, BTW, have the same issue...

This color combination so far worked for all themes that I checked. It's definitely better than anything else that I've seen before. Committed the version with clWindow and clHighlight to Laz/main. Let's see what users report - they will definitely see it because the TaskDialog version of the debug format selection is in main now.

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: TTaskDialog musings
« Reply #29 on: September 22, 2022, 10:51:02 pm »
But can there be a generic way for LCL back-ends to fetch TBitBtn standard glyphs from Linux toolkit themes?
I doubt...

Meanwhile trying to internalize native behaviour on WIn7 found a funny bug.
Notice, how the last button shape/size was mad for two short strings, but then the caption was rendered as one long string.


 

TinyPortal © 2005-2018