BriskBard, CEF4Delphi, WebView4Delphi, WebUI4Delphi and WebUI4CSharp

I started to try and see if it would work on Mac.

I have it, so that it does compile.
It does not yet check the presence of the framework files on disk. To be added later, when and if it works. The demo also needs some clean up.

It also works in SingleProcessMode.

But I can't get it to work in MultiProcessMode.
I created a separate exe for the SubProcess. And I can see (by inserting writeln) that the exe is found and launched.

However, even before the sub-process is launched, I get a message "the gpu process has crashed". I could not figure out why.

I played with various options, but to no avail.
I also tried to create/init the CEF app before the Lazarus Widgetcode gets to run (change the unit order, which affect the order in which initialization blocks are executed / moving the create/init into the main code, instead of the initialization block did not work either).
As for the sub-process, I also tried the "no gui" widgetset, in case the normal one would interfere.

https://github.com/User4martin/CEF4Delphi/tree/fpc-mac
See the comments, where files should go.

I welcome any ideas.
Thanks

Great!!!

Tank you very much!

Right now I'm busy but I'll take a look at the code this weekend and I'll try to help.

I don't have a Mac and know nothing about programming in that OS but I'll compare your code with the official CEF demo.

I just merged your code into the project. Thanks again!!!!

I noticed that FPC and Delphi have a conflict with the MACOS and DARWIN conditionals so I added a new one to "cef.inc" called MACOSX
MACOSX is now defined for both compilers when the target is the new MacOSX system.

As I commented before, I know nothing about programming for MacOS and added your code without changes but I'm not sure about some declarations in uCEFTypes.

Some types for MacOS are defined here in the CEF project :
https://bitbucket.org/chromiumembedded/cef/src/master/include/internal/cef_types_mac.h

What we call TCefWindowHandle, TCefCursorHandle and TCefEventHandle in CEF4Delphi are defined like this in CEF : The fpCEF3 project added the "CocoaAll" unit to the "uses" section and defined those types like this :
https://github.com/dliw/fpCEF3/blob/master/cef3types.pas Perhaps we could try declaring them the same way as fpCEF3 or maybe using NSCursorPtr, NSEventPtr and NSViewPtr.

I can't test the demo but I would suggest that we try something much "easier" (notice the quotes) before creating a full browser.

The first demo that I could run in Linux was "TinyBrowser2" because it lets CEF creates everything.

Another good candidate to make a first demo would be a simple empty form that initializes CEF without any browser.

salvadordf wrote: ↑Sun Jan 31, 2021 4:38 pm Some types for MacOS are defined here in the CEF project :
https://bitbucket.org/chromiumembedded/cef/src/master/include/internal/cef_types_mac.h

What we call TCefWindowHandle, TCefCursorHandle and TCefEventHandle in CEF4Delphi are defined like this in CEF :

Code: Select all

// Handle types.
// Actually NSCursor*
#define cef_cursor_handle_t void*
// Acutally NSEvent*
#define cef_event_handle_t void*
// Actually NSView*
#define cef_window_handle_t void*

So that would be "pointer".
"PtrUInt" is fully compatible.

The only difference is, that PtrUint can be used as int, pointer needs casting.
PtrUint <> 0 // Pointer <> nil

Since other code (for other platforms) already uses "<> 0", I believe PtrUInt is good.

----
I did try TinyBrowser2 => same error: GPU process crashed, then GPU process is unusable
"gpu_data_manager_impl_private.cc(439) gpu process isn't usable"

I even compiled it with "widgetset = nogui", getting as close to a console app as I can, to avoid interference from the Lazarus widgetset.

Again SingleProcess works.

And as far as I can tell from my logs, the only subprocess started is for networking, which would mean:
- It does find the subprocess and can use it
- The GPU process crashes before a subprocess is launched.

I guess it must be looking for something that it needs to pass to the subprocess, and does not need in single process mode.

I tried to run with --disable-gpu
No difference. (Some sides say this is no longer supported, no idea)

I haven't checked but perhaps CEF also uses Zygote subprocesses in Mac as in Linux.

I had to set GlobalCEFApp.DisableZygote to true to avoid a similar error in some Linux demos and I just saw that I missed the Zygote subprocesses in a couple of GlobalCEFApp procedures. I'll upload the fix for that as soon as I can.

I need to learn a lot of things about Mac and see if I can understand what the official sample application does in that OS.
Until now I wasn't paying much attention to the discussions about Mac in the official CEF forum.

I'll try to import some of the fpCEF3 code for Mac too. It might be helpful even if I can't test it.

Making some progress. Will report back when I have more.

Seems related to this announcement https://groups.google.com/g/cef-announce/c/YK6CTvGNhlY

Thank you so much for your work on MacOS !!!

I had to make a few changes to the latest pull request because there were some issues building the Windows version of CEF4Delphi.

I'm glad that the browser is now working on MacOS.

I did some more commits.
I tested on Windows, Ubuntu, and Mac.

My tests are mainly loading Google, and playing a clip on YouTube.
If there are any other tests worth performing, please let me know.

Mac still crashes when you close the app.
Should get fixed eventually, but may take some more time.

Another question:
When are they needed, when not?

They appear to be only in target=Windows demos.

However Window does for example not use TCEFLinkedWindowParent. So it is not clear if they are needed for that (Linux uses it, and does not have the above calls)

What kind of Webpage do they need for testing them?

Thank you very much again Martin!

I see that you've moved the MacOS demo to a new directory and you added support for other OSs.

CEF and Chromium have very different ways of doing things depending on the OS and widgetset used.
A few examples would be :

• Unique app bundles for Mac.
• Different ways to resize, show and hide the internal browser view in Windows, Linux and probably MacOS.
• Different destruction steps.
• Different ways to handle the web page image in OSR mode.
• etc.

Having all that in one demo is possible but I would recommend that we focus on a demo only for MacOS because adding support for other OSs only takes time away from having a full MacOS demo.

In general, CEF is more complicated to use than TWebBrowser and I decided to create more demos that were easier to understand and maintain.

Most of the current demos (not all) show how to do a reduced set of things and this should make it easier for the developers to take the code they need from the demos to their own applications. Small changes in the CEF API, which are not infrequent, are also easier to detect and fix this way.

Additionally, it's rare to find someone willing to help in this project with code for some unimplemented feature, OS/framework support or fixing issues. Your case is even more rare because you have the time, knowledge and hardware to help with MacOS support.

About the shutdown issues, there are a couple of suggestions :

• Windows and Linux have slightly different destruction steps that need to be implemented in order to avoid shutdown issues. As you can see in the "ExternalMessageBrowser" demos, the TChromium.OnClose event sets a different value for the aAction parameter because the Windows demo needs to destroy CEFWindowParent1. That is necessary to receive the TChromium.OnBeforeClose event and then close the main form. The Linux demo in the other hand doesn't need all that and you can set aAction to cbaClose to continue closing the browser. I would have to learn a lot more about MacOS and check the CEF sources to know what MacOS needs for that event in a Lazarus demo.
• The other "ExternalMessageBrowser" demos have some extra code in the LPR file to free the main application form and call GlobalCEFWorkScheduler.StopScheduler before the DestroyGlobalCEFApp and DestroyGlobalCEFWorkScheduler calls. This is also necessary to avoid shutdown issues. https://github.com/salvadordf/CEF4Delphi/blob/master/demos/Lazarus_Linux/ExternalPumpBrowser/ExternalPumpBrowser.lpr