mcpcpc
Intent-Driven Text Transformation for the Terminal
Catclock for Wayland
pacersdk: Python SDK for accessing the Pacer API
Quart Extension for the Authlib Library
Installing 9front OS on a Linode VM
X Server and VNC on a Linode VM
The argument of simplicity for source is relative to the API implementation. In this use case, the XCB API is the clear winner (imho).
Taking a closer look at the original xwm, this project has long since been dead. i wonder if it would be fair to say the acronym itself could be used, as tribute to the original? or is that too confusing?
cwm-----> 6328 cloc, http://ix.io/2DGD
evilwm--> 3257 cloc, http://ix.io/2DGI
dwm-----> 2505 cloc, http://ix.io/2DGQ
xwm------> 301 cloc, http://ix.io/2DGE
tinywm---> 115 cloc, http://ix.io/2DGR
I think it would be unfair to compare xwm to either based on the sheer difference in cloc (10x+). A better comparison would be to dwm, bluewm, tinywm, lainwm or any of the smaller code-base projects.
From a philosophical standpoint, xwm is written using the XCB protocol while the other two are written using Xlib. The "X New Developer's Guide" is a good reference to understand the difference: https://www.x.org/wiki/guide/xlib-and-xcb/
From a sheer dependency standpoint, xwm has fewer than the rest. There are obvious drawbacks to this, but I intentionally left xwm as "barebones" as possible, to allow the community to expand, patch, tweak and modify. This is consistent with the Suckless Philosophy of programming (https://suckless.org/philosophy/), which is based on the Unix Philosophy of programming.
Additionally, I have opted not to have a run-time config file. Everyone seems to have a config file these days that is either placed in an obscure directory, "hidden" from plain site or cluttering my home directory. I hate config files (and they hate me). Not doing so forces the user to glimpse into the source which, to me, is a habit that all existing and new Unix users should be doing.
Amongst other things, I provide no out-of-box multi-monitor support, no menu bar, no title bars, no tab focus or or any other feature that a regular user would find essential. Instead, these features will be offered as patches, which the user must learn how to apply themselves.
I hope that information helps answer your question a bit. =)
I switch my process frequently as I move around quite a bit, making development work fairly tedious. I am sure that there is a better way, but this is what I found works for me at the moment.
I intentionally omitted a screenshot in the README as xwm, by itself, is not attractive. Also, really I wanted to leave ricing/tweak/patching to be entirely user contribution driven. I may consider, though, adding a directory in the patches (https://github.com/mcpcpc/xwm-patches) repo for user contributed screenshots though.
Any other advice for checking for naming conflicts? I used github, google and repology.org and was excited when I saw no hits on the name. =S
will update the screenshot link shortly.
Took heavy inspiration from dwm, bluewm, tinywm, lainwm and the likes to create what I would consider a minimally viable window manager solution. The project is C99 POSIX and MISRA compliant, which promotes portability, security and safety of the source.
I would say the target audience are those that spend most of their time staring at a single terminal and periodically need to jump into a GUI based application (e.g. web browser). There are many projects like this, but I am hoping to improve on previous ones by reducing the overall complexity (per the KISS principle) and improve upon documentation.
I am still developing my C programming skills, so all feedback is welcomed. =)
Enjoy!
Xwm – a tiny XCB floating window manager
“Producing Open Source Software” by Karl Fogel
Ask HN: GitHub project SEO
I’ve been working on a GitHub project (https://github.com/mcpcpc/kirc) for the past ~1 month, posted to HN about 2 weeks ago and received some incredible feedback (thank you!), and now i am focused on search engine optimization (SEO) to make my project easier to find.My question is, what steps should GitHub developers take to establish higher search engine ranking?