[Lazarus] RegisterWSComponent documentation?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Lazarus] RegisterWSComponent documentation?

Free Pascal - Lazarus mailing list
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

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] RegisterWSComponent documentation?

Free Pascal - Lazarus mailing list
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 declared at TWSCustomControl. 
If 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 <[hidden email]> wrote:
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

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] RegisterWSComponent documentation?

Free Pascal - Lazarus mailing list
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


--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] RegisterWSComponent documentation?

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
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.

--
Zoë Peterson
Scooter Software

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] RegisterWSComponent documentation?

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
Juha,

On 11/11/20 3:48 AM, Juha Manninen via lazarus 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.

--
Zoë Peterson
Scooter Software

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] RegisterWSComponent documentation?

Free Pascal - Lazarus mailing list
In reply to this post by Free Pascal - Lazarus mailing list
On Wed, Nov 11, 2020 at 3:31 PM Zoë Peterson via lazarus <[hidden email]> wrote:
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.
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
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.

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 

--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus