sherpa_41
is a toy browser engine, based somewhat on
Limpet's Let's build a browser engine!
with architectures introduced in CS3251.
This app is meant to be explorative in nature, and is not designed to be especially robust, or even useful.
USAGE: sherpa_41 [options]
OPTIONS:
--html <file> HTML file to parse (Default: examples/sherpa-webpage.html)
--css <file> CSS file to parse (Default: examples/sherpa-webpage.css)
-W, --width <size> Browser width, in pixels (Default: 2880)
-H, --height <size> Browser height, in pixels (Default: 1620)
-o, --out <file> Output file (Default: output.png)
-h, --help Show this help screen
Almost any file type designed to show images can be used as the output file.
.png
, .pdf
, .jpg
are all great options, and you can even output to a
.html
file if you want.
An example of a custom invocation:
sherpa_41 --html index.html --css style.css -W 1800 -H 1200 -o myIndex.jpg
First, you will need CMake and Magick++.
Clone the repo and its dependencies, then make the project:
git clone --recursive https://github.com/ayazhafiz/sherpa_41.git
cd sherpa_41 && cmake .
make
./sherpa_41-test && ./sherpa_41
A summary of development notes is lower on this document.
-
The HTML parser currently supports elements, comments, and text nodes.
-
The CSS parser currently supports tag, class, id, and wildcard selectors, and has support for text, color (RGB/A, #HEX), and numerical unit declarations.
-
The Display module can currently issue commands to render rectangular block nodes.
-
Sherpa's Canvas renderer can currently generate basic webpages like the header.
-
There is no GUI renderer (yet?!). Until one is made, the front-end is really just an image. But a cool, nicely-rendered image, because sherpa has awesome renderers.
-
JavaScript is turned off by default, and can't be turned on. You may say JavaScript is unsupported. I say you're right.
-
If you patch this project, I'd love to see what you do. An issue or pull request is the easiest channel for communication.
When adding a new feature or module to sherpa_41
, please also add appropriate
GTests for it in tests/
. Generally,
the structure of the tests/
directory should mirror that of src/
.
Before submitting a PR, please take care that your changes pass on Travis.
The Travis build will fail if the codebase is not formatted to the
.clang-format
spec provided. To format the code, run something like
clang-format -i {src,tests}/**/*.(h|cpp)
.
In order of importance, Sherpa's main design goals are sound architecture, memory and type safety, and efficiency.
-
Sound architecture - because
sherpa_41
is meant to be easy to explore and extend, reusable components and solid design patterns are valued overwhelmingly above succinctness and efficiency (of course, these aren't mutually exclusive). -
Memory and type safety -
sherpa_41
's memory philosophy is Rust's in a C++ wrapper. RAII, smart pointers, and move semantics are... the move. Here may be where C++ idioms stray the most, with sherpa using static methods like::from
to return unique pointers to polymorphic objects. -
Efficiency -
sherpa_41
has no excuse not to go fast. This mostly means avoiding object transmutation. The performance of renderers could be improved significantly.
idk, i got a sherpa jacket and thought the word sounded ambiguous enough to be a spectacular project name.