-
Notifications
You must be signed in to change notification settings - Fork 87
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
HTML5 video in MinEx (MinimalExample) should "just work" #4
Comments
See cefsharp/CefSharp#137 for the suggested package names, so you don't have to reinvent the wheel here more than necessary. 😃 |
I guess you mean this comment: cefsharp/CefSharp#137 (comment) I'm thinking this on priorities for NuGet partitioning:
Based on this I'm thinking we should maybe split across the x86/x64 pivot dimension instead + maybe a package with the bitness (you can't use that term enough) independent parts? I'm guessing that most either build an app as x86 or x64 - and hence don't need the other Of course that's seen from a CefSharp using developers PoV (i.e. one building an app based on CEF) and not a CefSharp hacker's |
... And it's along the pivot dimension CEF has chosen with "bitness" ... When in Rome do like Romans |
I don't know if splitting across bitness would work? I mean, that means that the It feels spontaneously a bit wrong to split it based on that. 😃 But I don't know. You are right in that it makes the packages a bit smaller and definitely less "bloated" in a sense. For our particular use case, it's not like we will ever need to support "only one" of them; we always want both x86 and x64. So perhaps we can just optimize for that, and if someone feels like making an x64 app only... well, it's their problem really. 😉 Am I too cruel as a dictator stating that? |
Are you aiming for the title of BDFL for CefSharp-land 😉 No seriously; it's great to bounce a bit back and forth on what to do, avoids some of the blind spots - and let's us do it more KISS. Actually I think when I wrote the above I was more thinking about You are right there might be problems when switching bitness when building - but the reason for the error message you get "should" be obvious/already documented in the FAQ if you elected for only e.g. In general what we gain from splitting across any pivot dimension would be stats versus other stats on what people actually use. Then again, stats are only one of the 3 kinds of lies there are. Let's take baby-steps and just keep it at what's optimal for CefSharp hackers at first:
I will build & push that new |
Why not... 😃 Well, time will tell. Maybe I will hand over the project entirely to you at some time. 😉
And to be honest, I didn't really grasp fully your intentions here (cef.sdk and cef.redist for different things). But I understand them now, and I think you're doing good there!
I think this one is actually quite hard. It's not that easy, not at all. Ideally, I would want it to work like this (and no, this is NOT a short-term goal):
The user (of CefSharp) would then not have to care about what bitness they are using. CefSharp would just be smart enough to load the right (unmanaged) binaries as needed. Wouldn't that be quite cool? If you agree, make this an issue on the CefSharp repo please, and we can then plan it for some future release. It's definitely doable. So, whatever steps we take here should preferably align with that future roadmap, if possible. I guess that means one single package, or CefSharp depending on both the Food for thought. What do you think? The difficulty then would just be of course to make the CefSharp dependencies be correct... As a slight side note, I couldn't get the .sln to automatically restore the package (cef.sdk) for me; I don't know why it didn't work. Could you try re-cloning CefSharp and see if it works for you? I mean, from a clean slate... |
I think the whole section you wrote above is
Now this is something I feel we should be focusing on immediately - because that's the actual blocker for cefsharp/CefSharp#288 being able to land right now (unless you want to focus on getting a non -pre 3.29 out the door before that?). I'll continue it over on cefsharp/CefSharp#288 |
Good. Did you add the issues already? 😉 Btw, should that perhaps be "dimension" rather than pivot? |
This should now work with |
Yep! 😄 |
😄 |
From the Google Group:
So should we just include all the CEF redist pieces?.... Actually it could be a CEF.redist.redist (redist^2) package 😄 because it's a redist of the bits that upstream CEF is redist'ing
The text was updated successfully, but these errors were encountered: