Re: [Lazarus] RegisterWSComponent documentation?
On Wed, Nov 11, 2020 at 3:31 PM Zoë Peterson via lazarus < lazarus@lists.lazarus-ide.org> 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 lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] RegisterWSComponent documentation?
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 lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] RegisterWSComponent documentation?
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 lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] RegisterWSComponent documentation?
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 lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
