Wanting to take advantage (for the first time) of the open-source nature of open-source software, I want to edit part of Google Chrome. I know exactly which source file to edit, and it's a very small change. However, the entire compressed source distribution tarball is about a gigabyte, and I can't even imagine how painful the recompiling process would be, not to mention how much disk space it would use.
So, the question is: Is there any better way to modify the program than to recompile the entire thing? It seems to be quite a painful thing to do for small changes.
No, there is no other way recompiling Chromium. I recommend you to use the Google Chrome Extensions API if you can. If you want to recompile Google Chrome, the steps are pretty easy, everything is explained in http://dev.chromium.org/developers Some tips (since I am a Chromium contributor)
For a quick start guide: https://docs.google.com/present/view?id=dd9mrt45_0dmtd49c6
Read documentation: http://dev.chromium.org/developers
Make sure you have 10GB of space.
Make sure you have a fast computer (64bit), the more cores/mem the better.
The source code is "not" just 1GB, it is more, after you checkout the sources, you would need to sync your DEPS (thirdparty) via gclient sync That will add another couple of GB.
It will take a lot of time to compile (~1 hour) on modern PCs. If you have a very fast computer, the time of compilation would decrease exponentially.
According to you comments above, you would need to checkout the source at least once, we use Git or SVN for that (read the documentations, we have explained as much as we can on the site). Once you finished compilation, you can always update your source (the same way you update your repository (git pull, gclient sync) Then incremental buildings will be around 5-10 minutes depending what you have changed.
Please follow the documentation (http://dev.chromium.org), I am saying that again because the Chromium community worked hard to make these documentations up-to date, they help new comers get familiar with the project.
Chromium is big, but fun to work with, have fun hacking :)
The open sourced Chromium is not the same thing as Google Chrome. Some specific features (like H264 support) are available in Chrome, but not Chromium. You cannot "build" Chrome; you can build Chromium.
A more feasible approach to make your modification might be to write it as an Extension.
Related
I've been experimenting with using Chrome DevTools as my primary authoring tool, and am now mostly using them.
As I continue to increase my usage, I'm running into some pain points.
Usually, when I begin working on a project, I now create a dedicated Chrome profile for it. I do this automatically by invoking Chrome with the --user-data-dir flag and storing the browser profile right within the project.
Then I go into the tools, set up my workspace, map my local directories, and so forth. This works great.
What doesn't work so great is that this is a very repetitive process. I'd love to be able to specify the workspace mappings within the project somehow, and then generate the appropriate profile. I'd also love to be able to set other preferences (like indentation, and various other settings on the DevTools "General" page) in a standard way.
I've thought of three ways this might be possible:
There might be an API for this, but I doubt it, as programmatic manipulation of browser preferences obviously is disfavored (but would someone have carved out an exception for DevTools?),
There might be a way to import/export DevTools preferences, and I might be able to generate the import format,
I might be able to figure out where they're stored in the user directory, and manipulate them myself (so far I haven't, though).
There's also one partial solution I've considered:
I might be able to copy a "template" browser profile to get some of the shared settings above. Then I'd still have to do the workspace mapping each time, but I might be able to get away with not doing the rest.
One really elaborate strategy I could try would be to use browser automation, as suggested in Google Chrome - how can i programmatically enable chrome://flags some of the modules from disable mode to enabled mode? ... but that seems like overkill even as I start using the stuff more heavily; I don't think I'm quite ready to invest that kind of up-front effort in it.
Is anyone familiar enough with how the Chrome DevTools preferences work to judge which strategies might be most promising?
There is no way easily sync DevTools settings. They are stored in localstorage scoped to the DevTools. Which means they are in a special sqlite DB which isn't easy to transfer between machines (plus you'd bring all the other stuff with it.)
Sadly, you are left porting this all around by-hand with each new machine.
After publishing a new version of our extension to production, we sometimes see a weird behavior:
The extension on the browsers seems to be only partly updated (after given some time).
Our internal version number (part of our code) shows in such cases a previous version number, although some features and resources from the newer version already exist.
We have seen this occasionally in all browsers and on different operating systems.
Any idea why is that and what can be done?
Note: our extention.js and popup.html files are about 380kb (I don't know if that makes any difference).
Whilst I don't know the specifics of your scenario, in general, updates are automatically checked for and pulled if required by the extension several times a day. If there is anything that interrupts the process such as connectivity problems, then a partial update may occur though there are mechanisms in place to try and protect against this. Also, note that resources update if there are changes to one of the core files (extension.js or background.js).
[Disclosure: I am a Crossrider employee]
I would like to provide an installation of Chrome (or probably Chromium?) that comes pre-installed with my extension, installed to a separate folder and has the --enable-experimental-extension-apis turned-on by default. Would also be cool to be able to customize the looks and feels to be more suitable for my brand.
Does anyone know if its allowed by Google's TOS? Is it possible? Was it done before? Is there any easy way to do that, without hacking around on Chromium source code?
If you know enough C to modify some code, mini_installer is a good place to start. This is what people would be downloading anyway, so tweaking some of the code there to suit your needs would be the best bet. Install it where you like, make whatever changes before/after the install, etc.
Otherwise, you could write some kind of script that downloads and runs the installer, and then changes settings. For compatibility with your apparent target audience, a simple batch script would be the best bet.
Another option is Chromium Portable. You make any changes you like, and upload a zip file. All they have to do is download and unzip it. Most users can manage that, but pictures on the download page don't hurt. You could also write a small program or script to download the zip file, unzip it, and run anything that needs to be run (or Chromium it self).
It's technically possible and allowed. Indeed, there are a number of forks of Chromium, such as Iron and Comodo Dragon.
Whether it's a good idea is another question entirely. Unless you're prepared to maintain your fork on a long-term basis (and in particular, to provide software updates to your users on a frequent basis), it's probably not a good idea. You'd probably do better to instruct your users to install Google Chrome normally, then give them a link to install your extension.
As far as experimental extension APIs go, I'd avoid them. They may be removed or changed significantly in future versions of Chrome. If you must use them, just instruct the user on how to enable them.
Google has open-sourced the auto update mechanism used in Google Chrome as Omaha.
It seems quite complicated and difficult to configure for anybody who isn't Google. What is the experience using Omaha in projects? Can it be recommended?
We use Omaha for our products. Initially there was quite a bit of work to change hardcoded URLs and strings. We also had to implement the server ourselves, because there was not yet an open source implementation. Today, I would use omaha-server.
There are no regrets with ditching our old client update solution and going with Omaha.
Perhaps, you can leverage the courgette algorithm, which is the update mechanism that is used in Google Chrome. It is really easy to use and apply to your infrastructure. Currently, it just works for Windows operating systems. Windows users of Chrome receive updates in small chunks, unlike Mac and Linux users who still receive the chunks in total size.
You can find the source code here in the Chromium SVN repository. It is a compression algorithm to apply small updates to Google Chrome instead of sending the whole distribution all the time. Rather than push the whole 10 MB to the user, you can push just the diff of the changes.
More information on how Courgette works can be found here and the official blog post about it here.
It works like this:
server:
hint = make_hint(original, update)
guess = make_guess(original, hint)
diff = bsdiff(concat(original, guess), update)
transmit hint, diff
client
receive hint, diff
guess = make_guess(original, hint)
update = bspatch(concat(original, guess), diff)
When you check out the source, you can compile it as an executable (right click compile in Visual Studio) and you can use the application in that form for testing:
Usage:
courgette -dis <executable_file> <binary_assembly_file>
courgette -asm <binary_assembly_file> <executable_file>
courgette -disadj <executable_file> <reference> <binary_assembly_file>
courgette -gen <v1> <v2> <patch>
courgette -apply <v1> <patch> <v2>
Or, you can include that within your application and do the updates from there. You can imitate the Omaha auto update environment by creating your own service that you periodically check and run Courgette.
I've been using Omaha in various projects since 2016. The projects had between a handful and millions of update clients. Target operating systems were mostly Windows, but also some Linux devices and (via Sparkle) macOS.
Omaha is difficult to set up because it requires you to edit Google's C++ implementation. You also need a corresponding server. The standard implementation is omaha-server and does not come from Google. However, in return it also supports Sparkle for automatic updates on Mac (hence why I mentioned Sparkle above).
While setting up the above components is difficult, once they are configured they are work extremely well. This is perhaps not surprising given that Google use Omaha to update millions (billions?) of devices.
To help others get started with Omaha, I wrote a tutorial that gives a quick overview of how it works.
UPDATE
Customizing google omaha isn't that easy espacialy if you have no knowledge about c++, python or com.
Updates aren't published that frequently
crystalnix/omaha is managed by the community and they try to merge the main repo into their's; additional features are implemented and basic things are fixed
google/omaha is more active and changes from google are added but not frequently
To implement manual updates in any language you can use the com classes
Resume
google omaha is still alive but in a lazy way
bugs are fixed but do not expect hotfixes
google omaha fits for windows client apps supported from windows vista and upwards
the server side I'm using supports also sparkle for crossplatform support
feedbacks and crashes are also supported on the server
feedbacks are sent with the google protocol buffers
crash handling is done with breakpad
I personaly would go for google omaha instead of implementing my own solution. However we will discuss this internal.
In the .NET world you might want to take a look at ClickOnce deployment.
An auto-update mechanism is something I'd personally code myself, and always have in the past. Unless you have a multi-gigabyte application and want to upload bits and pieces only, just rely on your own code/installer. That said, I've not looked at Google's open source library at all.. and didn't even know it existed. I can't imagine it offering anything superior to what you could code yourself, and with your own code you aren't bound by any licensing restrictions.
I have a unique and interesting difficulty: I need to find a way to (semi-)permanently store an html page on the iPhone, but the protocol and method I choose is up to me: for example, I could request that the files be packaged in a zip archive, then download it via a URL and unzip it on the iPhone to store/view. I think it would be complicated to download the page using straight html (see this question), and URLCache seems to be designed to download one resource at a time.
Does anyone have any suggestions for a system that will make this task relatively simple without adding significant time to till I can display the page on-screen?
I decided to go with the suggestion by Kalle, since I didn't need the zip program to do any heavy lifting. Unzipping is surprisingly fast, so it suits my purposes very well. I may have to clean up the code a bit though.