webkit based web browser for Enlightenment
Log | Files | Refs | LICENSE

commit b1f9cf4cfc64484735cf9f2e16941234f5aa51ce
parent 138c82e18904fb3938f3b1e6540779f9b4b5341d
Author: Kyle Milz <>
Date:   Tue, 25 Sep 2012 19:46:16 -0600

add license, etc files from vimprobable source

AINSTALL | 6++++++
ALICENSE | 26++++++++++++++++++++++++++
APATCHES | 158+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 190 insertions(+), 0 deletions(-)

diff --git a/INSTALL b/INSTALL @@ -0,0 +1,6 @@ +1. Edit config.h and Makefile +2. make + You need: libwebkit-1.0 >= 1.1.11 + libgtk+-2.0 + libsoup-2.4 +3. Optionally, make install diff --git a/LICENSE b/LICENSE @@ -0,0 +1,26 @@ +Copyright (c) 2009 Leon Winter +Copyright (c) 2009-2012 Hannes Schueller +Copyright (c) 2009-2010 Matto Fransen +Copyright (c) 2010-2011 Hans-Peter Deifel +Copyright (c) 2010-2011 Thomas Adam +Copyright (c) 2011 Albert Kim +Copyright (c) 2011 Daniel Carl +Copyright (c) 2012 Matthew Carter + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN +THE SOFTWARE. diff --git a/PATCHES b/PATCHES @@ -0,0 +1,158 @@ +Submitting Patches +================== + +Repository Overview +=================== + +Vimprobable uses git [1], a distributed revision control system. This +document is not intended to explain the git internals, for that there's +already a wealth of documentation on the Internet. + +The main Vimprobable git repository [2] has two main branches: + +master +vimprobable1 + +where master is for development on vimprobable2 and vimprobable1 is obviously +for vimprobable1 only. + +When submitting a patch, the feature should be made on top of the master +branch, unless there is a good reason for knowing that the fix is wholly +applicable to vimprobable1. In the general case though, most features are +submitted against master, and then manually ported to vimprobable1 where +applicable by the maintainer. Not all features of Vimprobable2 are applicable +to Vimprobable1. + +Preamble +======== + +If you've never used git before, git tracks meta-data about the committer +and the author, as part of a commit, hence: + +$ git config [--global] "Your name" +$ git config [--global] "" + +Note that, if you already have this in the global ~/.gitconfig option, then +this will be used. Setting this per-repository would involve not using the +"--global" flag above. If you wish to use the same credentials always, +pass the "--global" option, as shown. + +This is a one-off operation once the repository has been cloned, assuming +this information has ever been set before. + +Coding style +============ + +Vimprobable uses four spaces by default, rather than literal hard tabs. +Most editors by default honour hard tabs only. If you're using Vim (which +isn't an unreasonable assumption ;)) you can set the following: + +:set expandtab ts=4 sts=4 sw=4 + +This should help reduce the number of whitespace fixups needed. + +Use of topic branches +===================== + +Git's use of branches makes it very easy to separate out different topics +from one another -- hence, for any feature or patch developed, they should +be done in their own topic branch, which is branched from the current HEAD +of origin/vimprobable. Hence: + +$ git checkout master +$ git pull +$ git checkout my-new-feature + +Which at this point on means that you're on the "my-new-feature" branch, and +can then hack away. When you've got a series of changes, it's best to +consider how to commit them. Blindly doing: + +$ git commit -a + +which would commit all changes, won't make for a easy patch review, and will +likely just pollute the main git history with unnecessary noise. Not to +mention, if a bug is discovered, finding it in amongst a huge code commit +like that would be rather annoying. So instead, stage all the changes +you're doing logically together -- break up the feature into four or five +patches, or how ever many made sense. + +For example, if you were writing a new feature, you might have: + +* A patch to include any new header files. +* A patch for any new function prototypes. +* A patch per new function as it's written (or more, depending on the + complexity). + +This is nothing more than doing a: + +$ git add foo.h +$ git commit + +[Write commit message] + +... do some more hacking. + +$ git add main.c +$ git add utilities.c +$ git commit + +Working out what's changed +========================== + +Once you're happy with the commits on the "my-new-feature" branch, you'll +obviously want to check that they still work on top of any new code that +might have been committed to the upstream branches since you creates the +"my-new-feature" branch. This is important as you'll be basing your patches +against that. Hence: + +$ git checkout master +$ git pull +$ git checkout my-new-feature + +(Note: It's conceivable here that the "my-new-feature" branch might undergo +rebasing against origin/vimprobable2 -- although that's not being mentioned +here in the general case, but would equally be acceptable.) + +Compiling/Testing patches +========================= + +Before you send patches to the mailing list, please ensure that you compile +Vimprobable using the V_DEBUG target, as in the following: + +$ make clean && make V_DEBUG=1 + +This not only compiles with "-g -ggdb" (for debug symbols), but also runs +some sanity check to ensure you've not missed anything. If you have, fix up +any warnings or errors, and repeat the above command until it's clean. + +Generating patches to send to the mailing list +============================================== + +So, you've been working hard on your new feature, all your changes are sat +in a local topic branch; "my-new-feature", and you want to submit them to +the list. You've already updated your copy of the vimprobable2 branch, and +your "my-new-feature" branch is checked-out, hence: + +$ git format-patch -M -n --cover-letter -o patch_store master + +Which will place a series of numbered commits in a directory called +"patch_store". These can then be sent to the list [3] using the +"git send-email" command. + +Note that if this is more a bug-fix, or a single patch, it's not always +necessary to generate a cover-letter -- so that option to "git format-patch" +can be elided if necessary, but it doesn't really matter. + +External hosting and pull-requests +================================== + +Alternatively, if using a hosted Git service [4], then it's acceptable +that a pull-request can be issued on a branch against a repository. + +References +========== + +[1] +[2] +[3] +[4] -- or --