Configuration is done with config.h. Read the comments in the generated config.h to edit it according to your needs...

>Configuration is done with config.h. Read the comments in the generated config.h to edit it according to your needs. Defaults are stored in config.def.h.
>...
>Me: "Okay, cool. Now... where is it?"
>"Maybe should I search for it?"
>Pcmanfm: "Nothing found."
>"Gee uhhhhhh maybe I should re-read the whole thing?"
>Nothing whatsoever, other than a simple "You edit the configuration via (file)".
So.................... is it expecting me to have the ability/mind power to guess because, you know.... I'VE NEVER DONE IT BEFORE!
I mean, geeze... is it so hard to say "The file is stored at (location). You can edit it from there"? Like what in the bloody tits, it's like linux users are a bunch of egocentrists or a bunch of schizos

Attached: index.jpg (300x168, 9K)

Other urls found in this thread:

wiki.debian.org/Dwm
twitter.com/SFWRedditGifs

>falling for the suckless meme

>Uses suckless software which is aimed at configurability and small size instead of all the other available options for convenience

I agree that that part is a bit confusing. config.h is generated upon building the project the first time, so you would probably need to read the Makefile in order to know before you see it. You can, however, edit config.def.h in order to change the default settings, and I think you are able to just cp config.def.h config.h and continue normally, but the info should be in the READEME.

Wait, so I'm supposed to recompile it everytime I change its settings? Well, damnit. Makes sense... even if I find it somewhat unnecessary.

I think that the idea behind it is that it reduces code complexity and runtime execution. As most customizable things are 'thunk' at runtime, it runs faster than things that need to dynamically read configs at runtime. However, with current computer speeds, you won't notice a speed difference with DWM, st, surf, etc. Compiling them should also be fast on a modern machine, as in less than 1 minute per compile IIRC, so compiling each time the config changes isn't really an issue, it's just bothersome.
On the other hand, reducing code complexity is a good thing due to making things like debugging easier.

>as in less than 1 minute per compile IIRC
More like less than a second.

cp config.def.h config.h
Why did you even think going for suckless software was a good idea if you can't even figure this one out?

>is it expecting me to have the ability/mind power to guess
Yeah, they literally say that on their website.

Attached: suckless_dwm.png (776x54, 11K)

based

>find . -name config.h
Wow, sure is hard to find a file in a folder

Suckless is a fucking joke.
There is literally no documentation anywhere that tells what the xfps and actionfps variables actually do in st and what the difference between them is.
Grow out of the pseudominimalost phase and use well-designed, modular software that has real functionality.

Attached: 149f32e12eba032f7738fdc60bc0d8ca.jpg (1920x1080, 136K)

Yet their mailing list is constantly littered with inane questions with even more idiotic answers.

>this keeps the userbase small and elitist
Lmao, do they actually believe this? If anything it's going to attract the novices that just started getting into software development and still think they're hot shit for running ./configure && make.

What other terminal do you suggest? No xresources-configured garbage please.

Emacs.

This. Deliberately stating that you want your community to be "elitist" is the worst thing you can do if you actually want an elitist community.

dude just read this wiki.debian.org/Dwm
and read config.h like a css file
make ur changes and don't fuck with it

retard, not even a sucklessfag I don't use the software. but is piss easy to compile and configure those

Stop using pseudominimalist software.

Attached: lisp_awakened_one.jpg (2189x2570, 3.3M)

Based lisplord.

Thanks for your time to enlighten me, user.
Pic related just happened to me -- because of you.

Attached: 033172391439095c5505c35f38a11a5b.gif (480x320, 165K)