A couple of observations

[maxedi]

Hi,

first, thanks for the excellent work with the CEF4Delphi library

my first question is probably rhetorical one. Can you suggest why OSR-working cef (being an abstraction for rendering and input) still requires actual screen coordinates (through get_screen_point interface)?
I'll explain. There was a custom control of mine, utilizing OSR logic and perfectly working under Window. With Linux I had to carefully investigate why it crashed. So I looked at the CEF4Delphi Linux OSR Demo and finally found that ClientToScreen that somehow worked from non-main thread in Windows, here with gtk2 completely failed and even crashed the program. Understanding that I had to implement something like the demo approach with constant updating the saved screen origin in the main thread, my initial thought was "hmm, maybe for OSR it's not that important to give screen coordinates since almost everything regarding drawing here is virtualized". So I dropped origin conversion (only dpi one was kept) and the program started to work and everything looked perfect until one (at least) case. It was combobox and although selecting items in the dropdown list works, the scroller didn't, so any click at the scroller just closed the dropdown window. So I had to implement the origin updating and providing (instead to ClientToScreen call) and the scroller issue was gone. So the OSR CEF obviously still needs the screen coordinates after all (And I just met only one obstacle). Maybe they didn't abstract it enough?

Another observation is that I noticed that SimpleOSRBrowser insists on making the first creation attempt in FormActivate not FormShow. But being windowless and even not providing the handle for any means, isn't this too precautious? I saw with my own eyes in my code that the CreateBrowser call is perfectly fine with calling at any time during loading. Besides, it looks like comments in the source about FormActivate handler looks very similar to the one in the SimpleBrowser demo. So isn't it just pasted code for the sake of simplicity?

One final observation. When working with the demo trick about interfaces unuit on gtk/linux, I met an issue when my code, dependent on the widgetset, failed when calling pipe-related function from finalization section. This is expected since CustomWidgetSetFinalization is called outsize of units initialization-finalization chain. In my case it helped moving FreeWidgetSet call into finalization section of this customized interfaces unit. This works probably since FreeWidgetSet is ok with freeing nil objects in question so any process created outside "if ... StartMainProcess" clause just does nothing. I suspect that changing demos is not a good idea for this (they were tested and are working so this change might introduce some regression consequences), but maybe you can append a little comment in related modules in demos for someone at least to notice while utilizing these demos.

Thanks again!

[salvadordf]

my first question is probably rhetorical one. Can you suggest why OSR-working cef (being an abstraction for rendering and input) still requires actual screen coordinates (through get_screen_point interface)?
I'll explain. There was a custom control of mine, utilizing OSR logic and perfectly working under Window. With Linux I had to carefully investigate why it crashed. So I looked at the CEF4Delphi Linux OSR Demo and finally found that ClientToScreen that somehow worked from non-main thread in Windows, here with gtk2 completely failed and even crashed the program. Understanding that I had to implement something like the demo approach with constant updating the saved screen origin in the main thread, my initial thought was "hmm, maybe for OSR it's not that important to give screen coordinates since almost everything regarding drawing here is virtualized". So I dropped origin conversion (only dpi one was kept) and the program started to work and everything looked perfect until one (at least) case. It was combobox and although selecting items in the dropdown list works, the scroller didn't, so any click at the scroller just closed the dropdown window. So I had to implement the origin updating and providing (instead to ClientToScreen call) and the scroller issue was gone. So the OSR CEF obviously still needs the screen coordinates after all (And I just met only one obstacle). Maybe they didn't abstract it enough?

CEF4Delphi is just a CEF wrapper. If CEF or Chromium have some implementation requirements then it can only expose the interfaces, methods or properties necessary to satisfy the requirements.

The operating system differences makes it hard to use exactly the same code for Windows, macOS and Linux. Sometimes it's necessary to add some custom code with some conditional only for one of them.

Another observation is that I noticed that SimpleOSRBrowser insists on making the first creation attempt in FormActivate not FormShow. But being windowless and even not providing the handle for any means, isn't this too precautious? I saw with my own eyes in my code that the CreateBrowser call is perfectly fine with calling at any time during loading. Besides, it looks like comments in the source about FormActivate handler looks very similar to the one in the SimpleBrowser demo. So isn't it just pasted code for the sake of simplicity?

Yes, I probably pasted code. In fact I have to review the Linux demos because of this issue :
https://github.com/salvadordf/CEF4Delphi/issues/441

One final observation. When working with the demo trick about interfaces unuit on gtk/linux, I met an issue when my code, dependent on the widgetset, failed when calling pipe-related function from finalization section. This is expected since CustomWidgetSetFinalization is called outsize of units initialization-finalization chain. In my case it helped moving FreeWidgetSet call into finalization section of this customized interfaces unit. This works probably since FreeWidgetSet is ok with freeing nil objects in question so any process created outside "if ... StartMainProcess" clause just does nothing. I suspect that changing demos is not a good idea for this (they were tested and are working so this change might introduce some regression consequences), but maybe you can append a little comment in related modules in demos for someone at least to notice while utilizing these demos.

I'll add some code comments. Thanks!