hyprwm/wlroots-hyprland
1
0
Fork 0
mirror of https://github.com/hyprwm/wlroots-hyprland.git synced 2024-11-26 22:55:58 +01:00
Code Issues Projects Releases Packages Wiki Activity

Merge pull request #116 from ascent12/contributing

Browse source 
Updated CONTRIBUTING.md
This commit is contained in:
Drew DeVault 2017-09-29 22:44:51 -04:00 committed by GitHub
commit 0c48ef5ad8
2 changed files with 146 additions and 152 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

312
CONTRIBUTING.md
View file

@ -1,9 +1,9 @@
# Contributing to wlroots # Contributing to wlroots
Contributing just involves sending a pull request. You will probably be more Contributing just involves sending a pull request. You will probably be more
successful with your contribution if you visit the [IRC successful with your contribution if you visit
channel](http://webchat.freenode.net/?channels=sway-devel&uio=d4) upfront and discuss [#sway-devel](https://webchat.freenode.net/?channels=sway-devel) on
your plans. irc.freenode.net upfront and discuss your plans.
## Pull Requests ## Pull Requests
@ -11,35 +11,36 @@ If you already have your own pull request habits, feel free to use them. If you
don't, however, allow me to make a suggestion: feature branches pulled from don't, however, allow me to make a suggestion: feature branches pulled from
upstream. Try this: upstream. Try this:
1. Fork sway 1. Fork wlroots
2. Clone your fork 2. `git clone https://github.com/username/wlroots && cd wlroots`
3. git remote add upstream https://github.com/SirCmpwn/wlroots 3. `git remote add upstream https://github.com/SirCmpwn/wlroots`
You only need to do this once. You're never going to use your fork's master You only need to do this once. You're never going to use your fork's master
branch. Instead, when you start working on a feature, do this: branch. Instead, when you start working on a feature, do this:
1. git fetch upstream 1. `git fetch upstream`
2. git checkout -b add-so-and-so-feature upstream/master 2. `git checkout -b add-so-and-so-feature upstream/master`
3. work 3. Add and commit your changes
4. git push -u origin add-so-and-so-feature 4. `git push -u origin add-so-and-so-feature`
5. Make pull request from your feature branch 5. Make a pull request from your feature branch
## Commit Messages ## Commit Messages
Please strive to write good commit messages. Here's some guidelines to follow: Please strive to write good commit messages. Here's some guidelines to follow:
The first line should be limited to 50 characters and should be a sentence that The first line should be limited to 50 characters and should be a sentence that
completes the thought [When applied, this commit will...] "Implement cmd_move" completes the thought [When applied, this commit will...] *"Implement
or "Fix #742" or "Improve performance of arrange_windows on ARM" or similar. cmd_move"* or *"Fix #742"* or *"Improve performance of arrange_windows on ARM"*
or similar.
The subsequent lines should be seperated from the subject line by a single The subsequent lines should be separated from the subject line by a single
blank line, and include optional details. In this you can give justification blank line, and include optional details. In this you can give justification
for the change, [reference Github for the change, [reference Github
issues](https://help.github.com/articles/closing-issues-via-commit-messages/), issues](https://help.github.com/articles/closing-issues-via-commit-messages/),
or explain some of the subtler details of your patch. This is important because or explain some of the subtler details of your patch. This is important because
when someone finds a line of code they don't understand later, they can use the when someone finds a line of code they don't understand later, they can use the
`git blame` command to find out what the author was thinking when they wrote `git blame` command to find out what the author was thinking when they wrote
it. It's also easier to review your pull requests if they're seperated into it. It's also easier to review your pull requests if they're separated into
logical commits that have good commit messages and justify themselves in the logical commits that have good commit messages and justify themselves in the
extended commit description. extended commit description.
@ -47,158 +48,153 @@ As a good rule of thumb, anything you might put into the pull request
description on Github is probably fair game for going into the extended commit description on Github is probably fair game for going into the extended commit
message as well. message as well.
See [here](https://chris.beams.io/posts/git-commit/) for more details.
## Coding Style ## Coding Style
wlroots is written in C with the same style as Sway. The style guidelines is wlroots is written in C with a style similar to the [kernel
[kernel
style](https://www.kernel.org/doc/Documentation/process/coding-style.rst), but style](https://www.kernel.org/doc/Documentation/process/coding-style.rst), but
all braces go on the same line (*"but K&R says so!" is a silly way of justifying with a few notable differences.
something*). Some points to note:
* Do not use typedefs unless you have a good reason Try to keep your code conforming to C11 and POSIX as much as possible, and do
* Do not use macros unless you have a *really* good reason not use GNU extensions.
* Align `case` with `switch`
* Tabs, not spaces
* `char *pointer` - note position of `*`
* Use logging with reckless abandon
* Always include braces for if/for/while/etc, even for one-liners
An example of well formatted code: ### Brackets
```C Brackets always go on the same line, including in functions.
#include <stdio.h> Always include brackets for if/while/for, even if it's a single statement.
#include <stdlib.h> ```c
#include "log.h" void function() {
#include "example.h" if (condition1) {
do_thing1();
struct foobar {
char *foo;
int bar;
long baz;
}; // Do not typedef without a good reason
int main(int argc, const char **argv) {
if (argc != 4) {
sway_abort("Do not run this program manually. See man 5 sway and look for output options.");
} }
if (!registry->desktop_shell) { if (condition2) {
sway_abort("swaybg requires the compositor to support the desktop-shell extension."); do_thing2();
}
int desired_output = atoi(argv[1]);
sway_log(L_INFO, "Using output %d of %d", desired_output, registry->outputs->length);
int i;
struct output_state *output = registry->outputs->items[desired_output];
struct window *window = window_setup(registry, 100, 100, false);
if (!window) {
sway_abort("Failed to create surfaces.");
}
window->width = output->width;
window->height = output->height;
desktop_shell_set_background(registry->desktop_shell, output->output, window->surface);
list_add(surfaces, window);
cairo_surface_t *image = cairo_image_surface_create_from_png(argv[2]);
double width = cairo_image_surface_get_width(image);
double height = cairo_image_surface_get_height(image);
const char *scaling_mode_str = argv[3];
enum scaling_mode scaling_mode;
if (strcmp(scaling_mode_str, "stretch") == 0) {
scaling_mode = SCALING_MODE_STRETCH;
} else if (strcmp(scaling_mode_str, "fill") == 0) {
scaling_mode = SCALING_MODE_FILL;
} else if (strcmp(scaling_mode_str, "fit") == 0) {
scaling_mode = SCALING_MODE_FIT;
} else if (strcmp(scaling_mode_str, "center") == 0) {
scaling_mode = SCALING_MODE_CENTER;
} else if (strcmp(scaling_mode_str, "tile") == 0) {
scaling_mode = SCALING_MODE_TILE;
} else { } else {
sway_abort("Unsupported scaling mode: %s", scaling_mode_str); do_thing3();
} }
}
for (i = 0; i < surfaces->length; ++i) { ```
struct window *window = surfaces->items[i];
if (window_prerender(window) && window->cairo) { ### Indentation
switch (scaling_mode) {
case SCALING_MODE_STRETCH: Indentations are a single tab.
cairo_scale(window->cairo,
(double) window->width / width, For long lines that need to be broken, the continuation line should be indented
(double) window->height / height); with an additional tab.
cairo_set_source_surface(window->cairo, image, 0, 0); If the line being broken is opening a new block (functions, if, while, etc.),
break; the continuation line should be indented with two tabs, so they can't be
case SCALING_MODE_FILL: misread as being part of the block.
{ ```c
double window_ratio = (double) window->width / window->height; really_long_function(argument1, argument2, ...,
double bg_ratio = width / height; argument3, argument4);
if (window_ratio > bg_ratio) { if (condition1 && condition2 && ...
double scale = (double) window->width / width; condition3 && condition4) {
cairo_scale(window->cairo, scale, scale); do_thing();
cairo_set_source_surface(window->cairo, image, }
0, ```
(double) window->height/2 / scale - height/2);
} else { Try to break the line in the place which you think is the most appropriate.
double scale = (double) window->height / height;
cairo_scale(window->cairo, scale, scale);
cairo_set_source_surface(window->cairo, image, ### Line Length
(double) window->width/2 / scale - width/2,
0); Try to keep your lines under 80 columns, but you can go up to 100 if it
} improves readability.
break;
} ### Names
case SCALING_MODE_FIT:
{ Function and type names should be prefixed with `wlr_submodule_` (e.g. `struct
double window_ratio = (double) window->width / window->height; wlr_drm_plane`, `wlr_output_set_cursor`). For static functions and types local
double bg_ratio = width / height; to a file, the names chosen aren't as important.
if (window_ratio > bg_ratio) { For include guards, use the header's filename relative to include. Uppercase
double scale = (double) window->height / height; all of the characters, and replace any invalid characters with an underscore.
cairo_scale(window->cairo, scale, scale);
cairo_set_source_surface(window->cairo, image, ### Construction/Destruction Functions
(double) window->width/2 / scale - width/2,
0); For functions that are responsible for constructing and destructing an object,
} else { they should be written as a pair of one of two forms:
double scale = (double) window->width / width; * `init`/`finish`: These initialize/deinitialize a type, but are **NOT**
cairo_scale(window->cairo, scale, scale); responsible for allocating it. They should accept a pointer to some
cairo_set_source_surface(window->cairo, image, pre-allocated memory (e.g. a member of a struct).
0, * `create`/`destroy`: These also initialize/deinitialize, but will return a
(double) window->height/2 / scale - height/2); pointer to a `malloc`ed chunk of memory, and will `free` it in `destroy`.
}
break; A destruction function should always be able to accept a NULL pointer or a
} zeroed value and exit cleanly; this simplifies error handling a lot.
case SCALING_MODE_CENTER:
cairo_set_source_surface(window->cairo, image, ### Error Codes
(double) window->width/2 - width/2,
(double) window->height/2 - height/2); For functions not returning a value, they should return a (stdbool.h) bool to
break; indicated if they succeeded or not.
case SCALING_MODE_TILE:
{ ### Macros
cairo_pattern_t *pattern = cairo_pattern_create_for_surface(image);
cairo_pattern_set_extend(pattern, CAIRO_EXTEND_REPEAT); Try to keep the use of macros to a minimum, especially if a function can do the
cairo_set_source(window->cairo, pattern); job. If you do need to use them, try to keep them close to where they're being
break; used and `#undef` them after.
}
default: ## Example
sway_abort("Scaling mode '%s' not implemented yet!", scaling_mode_str);
} ```c
struct wlr_backend *wlr_backend_autocreate(struct wl_display *display) {
cairo_paint(window->cairo); struct wlr_backend *backend;
if (getenv("WAYLAND_DISPLAY") || getenv("_WAYLAND_DISPLAY")) {
window_render(window); backend = attempt_wl_backend(display);
} if (backend) {
} return backend;
}
while (wl_display_dispatch(registry->display) != -1); }
for (i = 0; i < surfaces->length; ++i) { const char *x11_display = getenv("DISPLAY");
struct window *window = surfaces->items[i]; if (x11_display) {
window_teardown(window); return wlr_x11_backend_create(display, x11_display);
} }
list_free(surfaces);
registry_teardown(registry); // Attempt DRM+libinput
return 0;
struct wlr_session *session = wlr_session_create(display);
if (!session) {
wlr_log(L_ERROR, "Failed to start a DRM session");
return NULL;
}
int gpu = wlr_session_find_gpu(session);
if (gpu == -1) {
wlr_log(L_ERROR, "Failed to open DRM device");
goto error_session;
}
backend = wlr_multi_backend_create(session);
if (!backend) {
goto error_gpu;
}
struct wlr_backend *libinput = wlr_libinput_backend_create(display, session);
if (!libinput) {
goto error_multi;
}
struct wlr_backend *drm = wlr_drm_backend_create(display, session, gpu);
if (!drm) {
goto error_libinput;
}
wlr_multi_backend_add(backend, libinput);
wlr_multi_backend_add(backend, drm);
return backend;
error_libinput:
wlr_backend_destroy(libinput);
error_multi:
wlr_backend_destroy(backend);
error_gpu:
wlr_session_close_file(session, gpu);
error_session:
wlr_session_destroy(session);
return NULL;
} }
``` ```

4
README.md
View file

@ -7,9 +7,7 @@ This is a WIP: [status](https://github.com/SirCmpwn/wlroots/issues/9)
## Contributing ## Contributing
Development is organized in our [IRC See [CONTRIBUTING.md](https://github.com/SirCmpwn/wlroots/blob/master/CONTRIBUTING.md)
channel](http://webchat.freenode.net/?channels=sway-devel&uio=d4), #sway-devel on
irc.freenode.net. Join us and ask how you can help!
## Building ## Building