Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some extra classes #26

Open
infrom-software opened this issue Nov 17, 2017 · 15 comments
Open

Some extra classes #26

infrom-software opened this issue Nov 17, 2017 · 15 comments

Comments

@infrom-software
Copy link

infrom-software commented Nov 17, 2017

I badly need CefMessageRouter.

@infrom-software infrom-software changed the title Some exta Some extra classes Nov 17, 2017
@lvsti
Copy link
Owner

lvsti commented Nov 17, 2017

well, that's gonna be tricky since that class is part of libcef_dll_wrapper which is a pure C++ API...

@infrom-software
Copy link
Author

Yep.

@lvsti
Copy link
Owner

lvsti commented Nov 17, 2017

do you want to use swift in the renderer process as well?

@infrom-software
Copy link
Author

I'm not sure this affects Helper, i.e. it has not to be modified (in C).

@lvsti
Copy link
Owner

lvsti commented Nov 17, 2017

based on what I see in the documentation in cef_message_router.h, you'll need to set up both sides of the channel yourself

@infrom-software
Copy link
Author

infrom-software commented Nov 17, 2017

Oh, I see. CefMessageRouter implies renderer in swift.

@lvsti
Copy link
Owner

lvsti commented Nov 19, 2017

I've done some research, it's not impossible but it involves:

  • modifying CEF a bit
  • creating a C API for the C++ classes
  • restructuring CEF.swift
  • wrapping the C API with a swift library

I'm planning to carry this out gradually but due to the size of the task I'd rather not fix any ETA.

@lvsti
Copy link
Owner

lvsti commented Nov 19, 2017

Oh, I see. CefMessageRouter implies renderer in swift. (solution to getting rid of duplicate swift std libs needed)

Even if you use CefMessageRouter, you can have Swift on one side (browser process) and C++ on the other (render process), it doesn't have to be the same language.

@infrom-software
Copy link
Author

infrom-software commented Nov 19, 2017

At first sight I thought that a direct swift port might be possible, using extant CEF.swift classes.

@SyberToto
Copy link

Hi @lvsti ,
I also want CefMessageRouter badly. With this pull request, I assume that the modification for CEF is done. Is there any other progress with CefMessageRouter? Although I'm not experienced with this C/C++/Swift translation, it will be my pleasure if I can help with this issue as I really want CefMessageRouter. :)

@lvsti
Copy link
Owner

lvsti commented May 6, 2019

Bridging the wrapper classes is indeed feasible but I always tried to avoid dumping them into the CEFswift module itself because I felt that they didn't belong there. On the other hand, I didn't manage to rearrange the source in a way that allowed both the existing CEFswift and a separate (and preferably optional) CEFswift.Wrappers submodule, so I abandoned that branch some weeks later.

I'll take another look at the impact of shoving everything into CEFswift and let you know what I decided.

@lvsti
Copy link
Owner

lvsti commented May 23, 2019

I've made some progress with the message router, hopefully I can get it to work on a branch around the weekend.

@SyberToto
Copy link

@lvsti Thanks for following up. Actually, I've added the message router to CEF.swift myself. It's not perfect but it's working. I'd like to have some discussion through email if you are interested, but I cannot find your email address on your Github home page.

@lvsti
Copy link
Owner

lvsti commented May 24, 2019

@SyberToto I've created a gitter room for this discussion: https://gitter.im/CEF-swift/wrapper-classes

@lvsti
Copy link
Owner

lvsti commented May 25, 2019

here is where I am with it: https://github.com/lvsti/CEF.swift/tree/wrapper-classes-redux

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants