Is there any documentation on how RegisterWSComponent works with creating classes at runtime?

I'm specifically looking at TTreeView and TCustomControl, which both have WS classes, TWSTreeView and TWSCustomControl, and widgetset specific subclasses, TCocoaWSTreeView and TCocoaWSCustomControl. It looks like it's creating new classes at runtime that somehow combine TCocoaWSTreeView and TCocoaWSCustomControl together, but it's not clear.

If I have my own class (TUiTreeView) and I want to register a subclass of my own to customize some behavior, should TUiCocoaWSTreeView descend from TCocoaWSTreeView or TCocoaWSCustomControl? Does it matter? If I have a TUiCocoaWSCustomControl too, which has a bunch of behavior I want to share, can I have TUiCocoaWSTreeView descend from that? Does the answer change if I add a new virtual method in TUiCocoaWSCustomControl?

This is an issue for me because on macOS 10.14 and later, treeviews should use an NSVisualEffectView for their background rather than using a plain fillRect(clWindow). I have that working in our own wrapper classes, but I'm not sure if I'm doing something dangerous. I would love to submit the above back to the LCL for inclusion in stock Lazarus, but to allow descendants to hook it properly, I'd want a virtual method in TCocoaWSCustomControl that TCocoaWSTreeView could override, and I assume that isn't supported.

Thanks,
Zoë Peterson
Scooter Software

The "logical" hierarchy of TWSxxx classes, drives the run time "virtual" composition.
TWSCustomTreeView inherits from TWSCustomControl.

When "building" an actual (interface) class in run-time, the code tracks every method the method is overridden by any platform-descendant class (i.e. TCocoaWSCustomTreeVierw), then the run-time class will get the method from the descendant. Otherwise the platform-class (i.e. TCocoaWSCustomControl) method is used.
If platform-class doesn't implement a method, the actual method (of TWSCustomControl) would be used.

As a result, the runtime built class "emulates the hierarchy" of TCocoaWSCustromTree -> TCocoaWSCustromControl ->
...
even though the actual hierarchy is
TCocoaWSCustromTree -> TWSCustromTree
TCocoaWSCustromControl -> TWSCustromControl

It's not nice, but it works.
There are three drawbacks due to use of such approach:
* a complicated run-time "building" code
* "inherited" call should not be used in TPlatformWSxxx methods. Instead of using inherited, an actual TPlatformWSParentClass should be used instead.
* FPC verify method call (-CR) check cannot be used with LCL. (since it the check would always fail in run-time built classes)

What you want to do, are the following things:
1) Declare TWSFancyTreeView, as a descendant from TWSTreeControl
2) Declare TUITreeView (LCL control), it can be a descendant from TTreeView
3) Add an implementation TCocoaWSFancyTreeView descendant from (TWSFancyTreeView).
4) In CocoaWSFactory, have a call to RegisterWSComponent( TUITreeView, TCocoaWSFancyTreeView );
that should do the trick.

thanks,
Dmitry

On Tue, Nov 10, 2020 at 4:28 PM Zoë Peterson via lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201110/787f9406/attachment.html>

FYI, the TTreeView in LCL is custom drawn. It does not map to a native widget unlike LCL controls typically do.
There are empty classes TWSCustomTreeView and TWSTreeView and I guess you can derive from them as Dmitry explained.
Replacing the current TTreeView in LCL is not realistic though.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201111/e70ecc0f/attachment.html>

Dmitry,

Thanks for the write-up, that's what I thought was going on, and details like the "inherited" call were what I was worried about. :)

Now that I've had a chance to shake out the design, I do see a patch I could pull together if you think it would be merged. General details are:

1) Add a new NSVisualEffectView descendant that wraps a TCocoaManualScrollHost and passes things down to it, just like TCocoaManualScrollHost does for its documentView.

2) TCocoaWSTreeView.CreateHandle would call the existing TCocoaWSCustomControl.CreateHandle to create the TCocoaManualScrollHost handle, then check the OS version, and if it's macOS 10.14 or later, it would create the NSVisualEffectView and nest the inherited handle within it. This new view becomes the handle, but only on versions of macOS that require it.

3) Change a couple of places in TTreeView to call
GetColorResolvingParent so it can use clDefault, and add a TCocoaWSTreeView.GetDefaultColor method that conditionally returns either clWindow or clNone. The TTreeView code already skips doing a fillRect on the background if you set Color to clNone.

Personally I need the new behavior for any TCustomControl descendant, so I'd put most of the code in TCocoaWSCustomControl, but we have our own TUiTreeView/TUiCustomControl classes already, so I can add the extra configurability we'd need there.

The biggest concern I'd have with it being pushed into LCL proper is that FillRect(clWindow) doesn't look right. The NSViualEffectView changes color based on the average color of the desktop wallpaper behind the window and shifts as you move the window around, so none of the NSColors can match it. I had to adjust our owner draw functions to not rely on drawing an opaque rectangle to clear/overwrite things, but it wasn't too bad.

I know this might seem like an unnecessary flourish, but TListView and TListBox already have the color shifting background. I'm just trying to make TTreeView match them and NSOutlineView.

Juha,

Juha Manninen wrote

FYI, the TTreeView in LCL is custom drawn. It does not map to a native widget unlike LCL controls typically do.

See my reply to Dmitry for the details, but the short answer is that I already have everything working. It's just all in our own classes that descend from the widgetset ones.

I don't know if/when the behavior changed, but modern versions of macOS do not treat NSView (aka HWND) as opaque. If you don't draw anything, the parent shows through without you having to tell it to. In dark mode, even things like TEdit are translucent. As long as the TTreeView doesn't do a fillRect(ClientRect), everything is drawn correctly.

NSVisualEffectView itself isn't transparent. It's a hardware accelerated surface that takes advantage of the GPU compositing to draw. You can put one on top of a bunch of other opaque controls, tell it to show what's behind the window, and it will make it seem like the desktop is peaking through without the opaque controls being visible. There's actually a flag for "Show what's behind the window" or "Show what's behind the view" that controls that.

On Wed, Nov 11, 2020 at 3:31 PM Zoë Peterson via lazarus <

I'd suggest to address the issue in the same manner as NSCell-based vs NSView-based tables were.
Just add another complication condition into Cocoa-widgetset.

The use of NSViualEffectView cannot be hard in Cocoa, as LCL claims to support back to 10.5.8 (or at least 10.6)
(There are still some PowerPC Lazarus users)

The biggest concern I'd have with it being pushed into LCL proper is

This is actually a LCL change, rather than Cocoa change. What you might want to do is to add another Widgetset compatibility flag (TLCLCapability) to indicate on how the background of TreeView should/should not be drawn. Using fancy effects is becoming a new norm (for any platform), so it might be handy in future for others (i.e. Qt5)

One might argue that TLCLCapability is not the right place for that, and instead Themes class should be used.
I personally don't have an opinion about that.

After all, you're dealing with a problem that surpassed Win9x User Interface :)
Thus, it's not a surprise for LCL not to have enough information to address the problem.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201111/a70b7865/attachment.html>