[Lazarus] Cocoa maintainer and submitting patches

[Zoë Peterson via lazarus]

As we're winding up preparations for our upcoming release, we've been 
collecting all of our outstanding changes relative to Lazarus trunk and 
splitting them into patches.  Outside some that are specific to us, we 
currently have about 130 distinct patches, half of which are for 
LCLCocoa, with the remainder being a mix of LCL core, LCLQt5, or 
components.  Some of those would require significant effort to develop 
example apps and bug write-ups for, which would be hard to justify if 
they're unlikely to be merged.


Dmitry hasn't been actively maintaining the Cocoa widgetset for quite a 
while now, and my understanding is that he's stepped down. Alextp has 
been pinging me on a issues that impact him, but I'm not currently a 
member of the Lazarus team.  I think I can do good job of evaluating 
patches, but macOS has already taken up significantly more of my time 
than I can justify, and I've already had to reduce my Cocoa efforts 
here.  David Jenkins is our primary macOS/Linux developer and did at one 
point have LCLCarbon commit access, but he's never been very active in 
that capacity.  He doesn't want maintainership himself either, but we 
can have him help, especially if it helps get our patches merged.


One concern I have with either of us is that an explicit design goal of 
our app is that it feel as macOS-native as possible, and that has 
involved considerable work to bypass the LCL in various ways.  We don't 
use the LCL common dialogs, for example, so if those break, we're less 
likely to notice.  We also don't use Lazarus on Windows, and David 
doesn't have any significant Win32 experience, so cross-widgetset 
functionality that we need on macOS/Linux could easily conflict with 
things that the LCL needs elsewhere.


Has there been any movement to replace Dmitry?  Are there any other 
developers who've expressed interest or even shown significant knowledge 
on the LCLCocoa innards?


--
Zoë Peterson
Scooter Software

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Request for Gitlab access rights for Cocoa

[Zoë Peterson via lazarus]

On 9/29/2021 12:53 PM, Alexey Tor. via lazarus wrote:


Thanks, here are 3 patches which I wanted to merge on start

3- forum, patch by Zoe, Demo to benchmark TextOut on win64/gtk2/Cocoa 
- Cocoa is very slow 



This patch is absolutely not ready to be merged.  It's a proof of 
concept that was intended to spur further research.  I didn't verify 
that it works for all cases, and I expect the final fix to be more 
invasive,  since the testing showed that the caching that the Cocoa GDI 
objects are currently doing is ineffective.  I don't have time for that 
myself right now, and hope that either Dmitry or David will look into it 
further when they have time.  If/when we have something that we're 
confident of, we'll submit it through the bug tracker.


--
Zoë Peterson
Scooter Software
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] FPC & Lazarus moving to gitlab

[Zoë Peterson via lazarus]

On 6/22/2021 11:05 AM, Michael Van Canneyt via lazarus wrote:

The conversion program will attempt to convert existing bugs using the
account of the new gitlab user. To map your gitlab user name (or ID) 
to the

mantis user, we ask that you file an issue in the mantis project of the
current bugtracker, assign it the category gitlab, and set the summary of
the bugreport to your gitlab account name or ID number (not both!). 



I have two Mantis accounts on bugs.freepascal.org, stemming from when I 
changed my name.  If I make two bug reports, one with each account, both 
listing the same GitLab account, will that work or mess something up?


--
Zoë Peterson
Scooter Software

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] RegisterWSComponent documentation?

[Zoë Peterson via lazarus]

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?

[Zoë Peterson via lazarus]

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

[Lazarus] RegisterWSComponent documentation?

[Zoë Peterson via lazarus]

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
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] OS theme change via TAppProperties

[Zoë Peterson via lazarus]

ThemeServices has an OnThemeChange callback for this already. Adding it 
to TApplicationProperties wouldn't be a terrible idea, though it would 
probably be better to implement CM_THEMECHANGED/CM_STYLECHANGED in 
TControl, which would be VCL compatible.  I haven't tested it on most 
widgetsets, but I do see calls to IntfDoThemeChange in them.  When I 
tested with Qt5 on Mint Cinnamon, there were cases where it wasn't 
getting called correctly, but I haven't had a chance to research it 
fully yet.  Looks like Cocoa is just watching for the system colors to 
have changed; this question[1] on StackOverflow implies it'll we'll need 
to hook into DistributedNotificationCenter instead.


1) 
https://stackoverflow.com/questions/39048894/how-to-detect-switch-between-macos-default-dark-mode-using-swift-3 



--
Zoë Peterson
Scooter Software


On 8/30/2020 11:43 AM, Alexey Tor. via lazarus wrote:

This forum topic is about how we can react to macOS theme change.
https://forum.lazarus.freepascal.org/index.php?topic=43111.msg376056;topicseen#new 



and I had the idea to make all this task simpler.
we have the TApplicationProperties. let's add OnThemeChange there!
some widgetset funcs will be needed.
now it's the problem - do this reaction on macOS, on win32,... no one 
knows how to do it on gtk2/qt...

I wrote to Dmitry (Cocoa developer) about this idea, then wrote here.

Alexey Torgashin




--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Debugger backends configuration

[Zoë Peterson via lazarus]

What controls what appears in the "Debugger type and path" dropdown in 
the Debugger backend preferences?


I have two macOS systems, one running 10.13 and one 10.14 that have 
different items listed.  The 10.13 one lists fpdebug, GDB, and LLDB 
based ones (6 total) and I've been successfully using "LLDB debugger 
(with fpdebug) (Beta)".  The 10.14 one only lists the GDB based ones in 
the dropdown though.


We have some custom commands in our build scripts, and both FPC and Laz 
are slightly out of date from trunk, (FPC more so right now).  I'm 
building on both systems using identical scripts though, and even tried 
wiping FPC, Lazarus, and their configurations off the system and 
starting from a fresh FPC 3.04a install.  Currently building Lazarus as 
64-bit with the Cocoa widgetset, using Xcode 10.


Where should I look for whatever is going wrong or being excluded?

Thanks!

--
Zoë Peterson
Scooter Software

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

[Zoë Peterson via lazarus]

There is an alternate way to swizzle documented here, which the author 
claims has less side effects.  I assume it would be possible to do this 
variant with Objective Pascal, but for a proof of concept it shouldn't 
be necessary:


https://blog.newrelic.com/engineering/right-way-to-swizzle/
--
Zoë Peterson
Scooter Software

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

[Zoë Peterson via lazarus]

On 6/11/2019 11:56 PM, Dmitry Boyarintsev via lazarus wrote:

If it's a problem to check isRunning every time through
nextEventMatchingMask, and alternative with the same behavior would be
to swizzle in the runloop variant before calling inherited run and
switching it back once we get into it.

Switching back? how is it possible?


"Swizzling" is the name for replacing the Objective C method pointers 
using method_exchangeImplementations.  It's not the same as overriding it.


There's a writeup of it here:

https://trinhngocthuyen.github.io/tech/method-swizzling-what-why-and-how/

So, rather than overriding nextEventMatchingMask directly, ours is 
called something like runLoop_nextEventMatchingMask. 
TCocoaWidgetSet.AppRun swaps the function pointers, soour version is 
only called after we get to that point, and when we get into that 
function, we swap them back and call the original implementation like 
normal.  Our version only gets called once.



We cannot be sure at what particular event, the hijacking would occur.
Today, there was a bug report, about crash in the hijacking approach
https://forum.lazarus.freepascal.org/index.php/topic,44930.msg323420.html#msg323420 

The application written caused nextEventMatchMask to be called even 
prior to Application.Init.


The above approach takes care of that, since our version is never used 
until we actually swap the method pointers.  It removes the need to 
maintain an "isRun" variable too.


--
Zoë Peterson
Scooter Software


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

[Zoë Peterson via lazarus]

On 6/11/2019 9:19 AM, Dmitry Boyarintsev via lazarus wrote:

Can we actually try to set the value for the instance variable?

Can anyone try and modify TCocoaApplication.run to look like this. (If 
you're using trunk, you'll need to have {$define COCOALOOPOVERRIDE} 
defines in cocoadefines.inc}


David did the research on this one, but IMHO, this is a bad idea.  As he 
said, the inherited run does more than just set _running before it 
starts calling nextEventMatchingMask; that's is just the bit that causes 
an obvious crash.  It's also poking around the implementation rather 
than relying on the public API, so it will be more likely to break again 
going forward.


If it's a problem to check isRunning every time through 
nextEventMatchingMask, and alternative with the same behavior would be 
to swizzle in the runloop variant before calling inherited run and 
switching it back once we get into it.


--
Zoë Peterson
Scooter Software

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] TApplication.DoEscapeKey/DoReturnKey

[Zoë Peterson via lazarus]

I'm working on the keyboard handling code in the Cocoa widgetset and 
I've run into an issue I'm hoping for some guidance on.


TApplication's DoEscapeKey and DoEnterKey are called in response to 
LM_KEYUP rather than LM_KEYDOWN.  Cocoa's "invalid key" beep occurs as 
part of the keyDown processing though and can not be suppressed until 
after keyUp (long story).  The logic in DoReturnKey to actually get to 
the "Key := VK_UNKNOWN" line is very complicated, and I don't want to to 
repeat all of it in the keyDown handler just to suppress the beep.


Is there a simpler check to do, or can all of those checks be moved into 
accessor methods that return ActiveDefaultControl/CancelControl or nil 
based on whether they should be activate?


--
Zoë Peterson
Scooter Software

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugging on macOS

[Zoë Peterson via lazarus]

Martin,

Thank you for looking into it.  I've been testing the latest version 
over the past couple of weeks and it seems to be working well.  I'll 
keep an eye on it and let you know if I see any more unexpected hangs.


Zoë


On 3/11/2019 8:47 AM, Martin Frb via lazarus wrote:

On 10/03/2019 23:05, Martin Frb via lazarus wrote:
When you press step, the debugger will (should?) abort reading locals 
and watches. But it will only do so between 2 watches.

If a single watch takes a lot of time, this may add delays.


It appears I was wrong. Watch/Locals evaluation is not currently 
interrupted. So this may cause long delays.

I will be looking into this.


I looked into it. Fixed in trunk.

Please let me know if this improves the situation.



--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugging on macOS

[Zoë Peterson via lazarus]

Martin,
Thank you for both the suggestions and looking into it.  I'm on 
something else right now, but I'll give everything a try in the new few 
days and let you know how it goes.


--
Zoë Peterson
Scooter Software

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Debugging on macOS

[Zoë Peterson via lazarus]

Are there still obvious optimizations/improvements to be done with the 
"LLDB with fpdebug" debugger on macOS? We're on trunk and it's largely 
not usable right now.  I'm sure it has something to do with the size of 
our project, but it currently has random, lengthy hangs when doing 
things like single stepping.  If I wait long enough it does eventually 
come back, but it is very much in the range of "Is this hung?" and not 
just sluggish.  It adds 10+ seconds to actually launching the app too, 
which is unpleasant, but at least something I can expect and work around.


--
Zoë Peterson
Scooter Software

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Printers4Lazarus: QtDefaultPrinter

[Zoë Peterson via Lazarus]

I was just digging through the OSPrinters code and noticed that all of 
the Qt code interacts with QtDefaultPrinter instead of 
TQtPrinters.Handle (which is never assigned).  Is that intentional?


Also, is printing from background threads (either just 1 or multiple 
using separate TPrinter objects) supported on any of the widgetsets?


--
Zoë Peterson
Scooter Software

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Doe fpc/lazarus already have System-Threading or is it planned

[Zoë Peterson via Lazarus]

On 2/2/2018 2:37 PM, Sven Barth via Lazarus wrote:
Once FPC supports anonymous functions as well I assume that support will 
start to become alive again. ;)


Hopefully.  They were already working on iOS/Android/macOS/Linux support 
using Delphi, and that's what's stalled.  The last commit on the v4 
branch was a year ago.  I looked into at least getting FPC on Windows 
running with Blaise's closure branch in Nov/Dec, but stopped because of 
that and the missing generics.  Primož did respond favorably when I 
asked him about adding FPC support though.


--
Zoë Peterson
Scooter Software

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Doe fpc/lazarus already have System-Threading or is it planned

[Zoë Peterson via Lazarus]

On 2/2/2018 1:37 PM, R0b0t1 wrote:

I've been looking for a replacement to
http://www.omnithreadlibrary.com/ for a long time. If I remember, the
dealbreaker is the library's codebase making heavy use of anonymous
functions and procedures.


Yeah, OTL requires anonymous methods.  I was hoping to port it to FPC 
once the anonymous method support landed, but AFAICT the cross platform 
port got pushed into OTL v4 and it looks like that stalled a year ago.



Does System.Threading expose an API that could take either code
references or anonymous methods? I'm very interested.


Yes, System.Threading has both "reference to procedure" and "procedure 
of object" overloads in the API, so you could implement most of it in 
the current FPC release.  As Sven said, though, no one has started on 
it, and anyone who did work on it would have to be careful to not taint 
it with code from Delphi's implementation.


--
Zoë Peterson
Scooter Software

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Doe fpc/lazarus already have System-Threading or is it planned

[Zoë Peterson via Lazarus]

On 2/2/2018 10:19 AM, Zoë Peterson wrote:
System.Threading requires anonymous methods, which Free Pascal doesn't 
currently support.


Oops, Sven's right, it mostly doesn't use anonymous methods, so this 
isn't a blocker.


--
Zoë Peterson
Scooter Software


--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Doe fpc/lazarus already have System-Threading or is it planned

[Zoë Peterson via Lazarus]

On 2/2/2018 4:25 AM, Michael Schnell via Lazarus wrote:
Featuring "parallel loops", "future variables", etc, implemented via a 
thread pool that is transparent for the application programmer.


System.Threading requires anonymous methods, which Free Pascal doesn't 
currently support.  Someone has been working on those, but it's hard to 
say when they'll be ready for merging.  Once that's done someone could 
start implementing System.Threading, though personally I'd probably just 
look into adding FPC support to OmniThreadLibrary at that point.


--
Zoë Peterson
Scooter Software

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Guessing the encoding of some text

[Zoë Peterson via Lazarus]

On 11/16/2017 4:25 AM, Torsten Bonde Christiansen via Lazarus wrote:
Does Lazarus or FPC include other convinient tools that may detect the 
encoding of (the content of) a file?

What do others do in this situation?


If you need cross-platform, this works with some trivial changes:

http://chsdet.sourceforge.net/

If you're Windows only, Microsoft provides 
IMultiLanguage2.DetectInputCodepage():


https://msdn.microsoft.com/en-us/library/aa740986(v=vs.85).aspx

--
Zoë Peterson
Scooter Software

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] LCL Cocoa: Overriding delegate protocols

[Zoë Peterson via Lazarus]

I need to handle some delegate protocols in our application layer, which 
will require overriding things that the LCL Cocoa layer already 
implements in classes like TCocoaWindow.


In the Carbon interface, the equivalent was fairly easy, since 
TCarbonWSCustomForm.CreateHandle just creates a TCarbonWindow and passes 
it back, so it's trivial to implement a new CreateHandle that returns my 
descendant.  TCocoaWSCustomForm.CreateHandle, on the other hand, creates 
a TCocoaWindow and then does a bunch of extra work to set that window up.


I'd really rather not duplicate the entirety of TCocoaWS*.CreateHandle, 
especially since the interface is still immature.  It seems like the fix 
would be to move all of the CreateHandle code into a method in 
TCocoaWindow (possibly init), and if that's the case, we can certainly 
look into a patch to do that, but I'd like some direction from the devs 
first.


Thanks,

Zoë Peterson
Scooter Software

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus