mcpcpc

Map out your floor, see how materials move, and let the planner find an arrangement that saves time and walking.

A Python SDK for interacting with the Public Access to Court Electronic Records (PACER) Case Locator (PCL) API.

XCB is closer to the X protocol, making it significantly smaller and generally faster (and more responsive) than Xlib.

The argument of simplicity for source is relative to the API implementation. In this use case, the XCB API is the clear winner (imho).

oh god. commence operation “spam the random name generator”!

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?

ah. well my google-foo sucks. wikipedia even has an article. again, i appreciate you pointing this out. not sure what i will do yet though. :(

some interesting tips in that article. thanks for posting it!

Just a quick glance at the source files for the two WMs you mentioned (along with a few others):

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. =)

Trying to put together a few example patches for xwm (i.e. focus borders and workspace). But once I get some bandwidth, I plan to provide some comparison data. =)

Very good question! It's been a combination of techniques, but no Docker. I started my initial verification over a SSH/VNC session (e.g. x11vnc) on KISS Linux, which is what i personally run. Lately, I have been hosting various virtual machines and testing on multiple distribution snapshots (i.e. Debian, Arch, etc.)

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.

Thanks! The challenge is keeping it from growing ;)

Thanks! It's been an almost 8mo journey learning C to get to this point. Ultimately it was the people that I interacted with and the user contributions that propelled me to make xwm.

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.

Oh man. I should have known, lol. Well I may need to consider a "rebranding". Thanks for pointing this out

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

new link: https://i.redd.it/ve0ra9qip7y51.png

thanks! I spent quite a bit of time stripping out as many dependencies as i could.

will update the screenshot link shortly.

screenshot (in use): https://i.redd.it/ve0ra9qip7y51.png

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!

will try to address the malloc concerns asap

thanks! i should note that channel indication exists already. it will appear, however, only for channels other than the one connected to initially.

interesting argument. will look into it

i appreciate the honest feedback! definitely a work in progress and i have learned a lot since i started ~1mo ago on this. will take your suggestions and add them to my ever growing “todo” list. ;)

will fix that. thank you!

definitely a good idea. will add that to the “todo” list

oohh interesting. will throw this in as an “example”. thanks!

the suckless IRC clients are awesome! in fact, `sic` was my “go to” before writing `kirc`. I’m definitely not trying to compete with those, especially their file-based approach (which is great for users that work across channels) but rather offer a lightweight and “clean-looking” solution for the casual user.

good question! no real reason, other than C99 being the standard that i started development in. With that said, I see no reason not to switch ;)