In the context of webkit in chromium source code ,it says it is source compatible but not binary compatible. Does it suggest that we build .dll file of webkit and build it with chrome binary ?
(This answer doesn't talk about the specific context of WebKit - it's not clear what exactly you mean by the various "it says" parts. I've tried to give a more general answer.)
Suppose we have a library called LibFoo, and you have built an application called SuperBar which uses LibFoo v1.
Now LibFoo v1.1 comes out.
If this is binary compatible, then you should be able to just drop in the new binary, and SuperBar will work using the new code without any other changes
If this is only source compatible then you need to rebuild SuperBar against v1.1 before you'll be able to use it
I would think of it from the point of view of Linking
Linking is the process of taking a class or interface and combining it into the run-time state of the Java Virtual Machine so that it can be executed.
Linking a class or interface involves verifying and preparing that
class or interface, its direct superclass, its direct superinterfaces,
and its element type (if it is an array type), if necessary.
If introducing a new change breaks the linking, then it is not source (code) compatible (as well as binary compatible)
If introducing a new change does not break the linking, then it is at least binary compatible
Related
WinRT's Windows::Media::Playback::MediaPlayer has support to adding video and audio effects (much like IMFMediaEngine), however I can't find a way to use existing IMFTransform's that I already use with IMFMediaEngineEx::InsertVideoEffect() in MediaPlayer::AddVideoEffect()
MediaPlayer::AddVideoEffect() only takes a string for the "activatableClassId", whereas IMFMediaEngineEx::InsertVideoEffect() allows me to pass in a pointer to my local IMFTransform directly. I don't want to registry a DLL with the system for the class to be activatable, I just want the IMFTransform to be registered locally in-process so that it can be discovered by the classId.
I've searched online but there is very little information. All I found was this Microsoft thread, an old article showing CGreyScale MFT using WRL, and this useful repository which uses an appxmanifest to registry the classes (not what I want to do).
These example seem useful and I implemented the decoration around my existing MFT however the example relies on registering the activatableClassId externally so I still can't tell how to do it in-process. The only thing I could find was RoRegisterActivationFactories() but there's very little information about this so I'm not sure.
Does anyone know how to do this?
Thanks,
Since the MediaPlayer API is WinRT, it will expect to use WinRT activated objects for effects. Alternatively, the lower level win32 MF Media Engine allows you to pass in an IMFActivate for any custom activation.
There are two ways to activate the MFT with WinRT:
Register the MFT to the registry and reference the CLSID, you can refer to this document.
Registration-Free WinRT(which requires the use of an application manifest), you can refer to this blog.
Unfortunately, this means that there is an appmanifest requirement if you wish to register the MFT in-process.
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
The package org.lwjgl.opengl contains a whole bunch of packages named from GL11 to GL44 - one for every version from OpenGL 1.1 to OpenGL 4.4.
What exactly does this mean? Does each of these packages contain a separate, working version of OpenGL, or does each package contain only items that were introduced in that version? How do I figure out what things are where?
It certainly looks like each class contains only the newly added values/methods. For example the GL44 class contains only a fairly small set of entry points matching new features added in OpenGL 4.4.
Adding a new interface for each version does have advantages:
Existing interfaces are not modified. It is mostly desirable not to modify interfaces once they were publicly exposed. Having various versions of the same interface can be problematic.
It makes it easier for programmers to target a specific OpenGL version, because you can tell which version each entry point is supported in based on the class name.
The downside is that you need to know (or look up) the version where each call was introduced, so that you know which class to use for the call.
I'm surprised that they did not establish an inheritance hierarchy between the classes. That would seem to give the best of both worlds:
Existing class interfaces are not modified when new versions are introduced.
Easy for programmers to target a specific maximum version by using that class.
No need for programmers to take into account the specific version where a call was introduced, as long as it's included in their target version.
This also make conceptual sense, because each version is an extension of the previous version, which matches a subclass relationship. The OpenGL ES Java bindings in Android uses this approach. GLES30 derives from GLES20. Therefore, if you're targeting ES 3.0, you can call all the entry points on GLES30, even the ones that were already present in ES 2.0.
I am using Delphi XE6 and using Datasnap and JSON in my project. There is a bug I want to correct in the VCL unit System.JSON.pas (in the TJSONString.ToString function) where it should be escaping backslash characters as well as quotes. In order to fix this I carried out the following :
Copied System.JSON.pas from the standard VCL source folder to my project source folder
Added System.JSON.pas to my project (using the newly copied file)
Fixed the bug and attempted to compile
I get the error 'Unit Data.DBXCommon was compiled with a different version of System.JSON.TJSONObject'
I can see that the Data.DBXCommon unit references System.JSON, so I guess the compiler is now seeing 2 versions - my fixed version and the standard VCL version.
What is the correct way to implement VCL changes to avoid this problem?
There are two common reasons for this issue:
You made changes to the interface section of the unit. You cannot do this without also re-compiling all units that use the unit you are modifying.
You re-compile the unit with different compiler options from those used to build it originally. Deal with that by ensuring the compiler options used to compile the unit you modify are the same as used by Embarcadero. Typically Embarcadero compiles with default options. Impose these directly in the source file being modified, right at the very top of the file.
Having said this, a recent question here on a similar topic could not be resolved using option 2 above. In that question, under XE6 only, the unmodified Classes unit could not be re-compiled and linked at all. Which makes me wonder if this particular technique has had its day. Perhaps it's not even possible. Before you give up, see if you can compile and link the unmodified unit.
More broadly, using a detour is generally an easier way to solve such problems as you face. Using a detour rather than re-compiling makes the management of the fix cleaner and simpler.
Update 1
I cannot get the unmodified System.JSON unit to re-compile and link. Which I think means that the issue raised in that other question is broader than just the Classes unit. I think you will find this a tricky hurdle to overcome and recommend the use of a detour.
Update 2
The problem that appears to have been introduced in XE6, seems to have been resolved by the release of XE7. The unmodified System.JSON unit will compile and link in XE7.
What if Delphi XE6 original System.JSON.dcu wasn't compiled with Delphi XE6 but it was compiled with one of the previous versions of Delphi.
You claim that you managed to implement your fix in Delphi XE2 using same approach by changing source and then recompiling System.JSON. SO I suggest you first make a comparison between original System.JSON files that ship with both Delphi XE2 and Delphi XE6.
If they are the same then the changed System.JSON.dcu that you managed to recompile with Delphi XE2 might also work with Delphi XE6.
I resolved a similar issue by :
Deleting the .dcu files which are on different versions ( i.e. conflicting files).
Re-build the project to create new .dcu files.
I am using Qt webkit Jambi API's to convert HTML to PDF.
My target is to create a jar for above conversion so that it could be used in a multithreading environment, but since QWebPage and QWebframe (QT webkit) are GUI classes, therefore the jar classes cannot be initialized from child threads.
So i am stuck as i don't know how to work around this problem.
Also i am a novice in QT , can anyone provide good reference about QT application's lifecycle, event loops and related stuff.
thanks in advance.
Ashish
Well, actually, I just use Firefox to do "Print to File" and select PDF as the filetype. But that's for manual work - although I suppose you could script Firefox.
I think in a Linux environment - and I'm assuming Linux/Unix because you mentioned Qt - that you could probably string together a couple of nx command-line apps. Possibly enscript has something that would help. If not, I'm pretty sure I've seen other solutions, just can't recall them off the top of my head. If you can transform the HTML to Postscript, getting a PDF out of it is trivial.
If HTML4 and (parts of) CSS1 suffice for your needs, then you can use QTextDocument together with QPrinter in a separate thread.
"Programming with Qt, Second Edition", O'Reilly, is excellent but only covers Qt3. A lot of the basic still apply to Qt 4.5.
"C++ GUI Programming with Qt 4 (2nd Edition)", ISBN 0132354160, is not bad.
The Qt docs contain examples and tutorials too.
It's not clear to me why you can't initialize a jar with GUI classes from within child threads. Is this an artificial limitation set on Jambi by the trolls?
I took note of this example on Rendering a webpage with Qt and Webkit to a QPixmap, which theoretically doesn't need to show anything on the screen. QWebPage and QWebFrame both inherit QObject. Using the sample code from the above link, it should be possible to get a webpage's rendered contents without a GUI.
My primary task was to get html to pdf conversion for printing the pdf.
I tried to get QT jambi (QT webkit C++ api also) to work in multithreaded environment but could not.
My final solution was as follows:
I used ‘wkhtmltopdf’ native binary from here,
wrote a java wrapper capturing the standard input and output streams.
Initialized the ‘wkhtmltopdf’ binary for each java thread that required the html to pdf conversion.
Also i never worked on erjiang's advice because by then I had moved out of the task and never got time to work on his advice.