For more complex patch sets, it’d be best just to use git. Keep an unpatched build in a separate branch from one you want to customize, then make separate branches for each patch and merge as needed. Git apply offers similar functionality to patch.
I just wanted to say that you're the reason I switched to dwm, and I've been dying to try Gentoo as well because of your videos. Good stuff dude, keep it up
Great video. Thanks for keeping true to the actual worklflow of patching the files. For me, after a couple of clean patches after fresh install, it regularly fails and I have resort to manual patching. Really like your videos dude 👍
To generate config.h from config.def.h use the command 'make' without any arguments. You have to delete config.h if it rxists before running make. Since the patches modify config.def.h, I initially copy config.def.h to config.def.h.original in case I ever want to reset dwm or st to their original state. The config.def.h.original only need be created one time.
wont 'config.h' be generated only if it doesnt exist? im just starting with patching, but after modifying 'config.h' and running 'sudo make clean install' (or simply 'sudo make', for what it matters), my changes to 'config.h' are still there. that said, i would think it is best to keep 'config.def.h' intact and work on 'config.h' instead. this way if you mess things up, you can just delete your broken 'config.h' and regenerate one with the original content from 'config.def.h'...
as i understand it, config.def.h is the default config, and config.h is your user config. if config.h exists, it's used; if it doesn't exist, config.def.h is copied over to config.h before compilation. so, you shouldnt completely trash your config.def.h and rename it, you should keep it around as an emergency fallback config.h with all the default settings known to work for your set up of dwm+patches, and when you install a new patch, just go into config.def.h and find the new lines and copy them over (plus whatever personal settings you want) to your config.h file manually.
Including a *.c file from a header file is a bit peculiar, although it technically works. You could instead patch dwm.c with the content of shiftview.c.
I'm new to tailing window managers like i3 & dwm. I have feeling that these WMs tend to have all opened apps are visible at all time. So its not best to use in smaller screen size.
Thanks. It looks good. I am currently on i3 but I might give this a try. One question, does dwm have smart gaps like i3, i.e., no gaps when there is a single window in a tag/workspace? I really like that feature.
you can find it in your include folders. one is xkbcommon and another one is x11 xkblib for some reasons, youtube keep deleting my straightforward directory comments so i guess youtube sucks mad dick...
No. As long as you use the same build of dwm, you won't need to re-patch them. Newer patches seem to be for newer version of the program with source changes, but most people don't "update" the program since it would require redownloading and re-applying all patches.
@@bubbyroosh4038 Then you are running an old version of st and missing out on new features. Applying new patches is very quick unless they don't work with the new st version.
@@randomuser2579 If you're using a suckless program why would you update it to get a new feature :| If you get a build that you like, you don't need to update it (unless you want the new features) as some patches may become incompatible/outdated.
@@bubbyroosh4038 this reasoning would be true to any software, not only suckless stuff. if you are happy with v1, why bother updating to v2? well, because in 99% of the cases we do want the new features! and that kinda makes your point irrelevant, albeit correct. the diff with suckless is that you may (very unlikely) lose your own mods if they are no longer supported by the new version. you would still need to re-patch the new version, but that shouldn't be much of an effort anyway, as already pointed out.
Man, I like your content but you gotta learn to zoom in bruhh. I couldn't see shit in my mobile and now I'm on my PC and still have a little difficulty. Not everyone has a huge ass monitor.
Holy shit I've been begging people to explain this to me all i got was the standard hah lol nub answer arch people tend to give.
Thanks for this dude.
For more complex patch sets, it’d be best just to use git. Keep an unpatched build in a separate branch from one you want to customize, then make separate branches for each patch and merge as needed. Git apply offers similar functionality to patch.
This is really the best way to apply patches and keep suckless software updated.
fakeventer sus!!
Yes! Use git. That's why git was created!
@@chuchomucho6655 SUS SUS SUS
Bruh that's an amazing idea. How didn't I think of that before. Thanks, fr.
I just wanted to say that you're the reason I switched to dwm, and I've been dying to try Gentoo as well because of your videos.
Good stuff dude, keep it up
This is the best video on dwm i have ever seen!
what a wonderful man.
most elitis won't explain so detail like this
Great video. Thanks for keeping true to the actual worklflow of patching the files. For me, after a couple of clean patches after fresh install, it regularly fails and I have resort to manual patching. Really like your videos dude 👍
To generate config.h from config.def.h use the command 'make' without any arguments. You have to delete config.h if it rxists before running make. Since the patches modify config.def.h, I initially copy config.def.h to config.def.h.original in case I ever want to reset dwm or st to their original state. The config.def.h.original only need be created one time.
Very helpful and straight to the point. Thank you for providing the tutorial. Much appreciated and desperately needed!! Keep them coming! :-)
You really wanna patch (.def) instead of (.h) since the Makefile will generate (.h) automatically so your changes will be lost
wont 'config.h' be generated only if it doesnt exist?
im just starting with patching, but after modifying 'config.h' and running 'sudo make clean install' (or simply 'sudo make', for what it matters), my changes to 'config.h' are still there.
that said, i would think it is best to keep 'config.def.h' intact and work on 'config.h' instead.
this way if you mess things up, you can just delete your broken 'config.h' and regenerate one with the original content from 'config.def.h'...
just have to *mv config.def.h config.h"* to replace your config.def.h as config.h, then you do sudo make clean install
as i understand it, config.def.h is the default config, and config.h is your user config. if config.h exists, it's used; if it doesn't exist, config.def.h is copied over to config.h before compilation. so, you shouldnt completely trash your config.def.h and rename it, you should keep it around as an emergency fallback config.h with all the default settings known to work for your set up of dwm+patches, and when you install a new patch, just go into config.def.h and find the new lines and copy them over (plus whatever personal settings you want) to your config.h file manually.
or just you git
You can edit the GRUB resolution in /etc/default/grub while working in a VM to set a proper resolution.
Elitism is bs. You've earned a new subscriber for calling it out.
They didn't though, they said "appealing to normies eventually hurts the product"
Thanks. I already knew this, but still helped a lot.
Including a *.c file from a header file is a bit peculiar, although it technically works. You could instead patch dwm.c with the content of shiftview.c.
100% yes! Include it in dwm.c instead!
add .c to the Makefile
yep. that makes much more sense!
add extra .c files to the Makefile, include .h files in .c that needs the definitions.
What colors are you using in your terminal?
couldnt u make the fonts larger?
Great video! I am still confused though, what is the point of having a config.h and a config.def.h?
(.def) has definitions the Makefile will use to generate (.h)
(.h) will be included in the actual code including defs in the (.def)
I'm new to tailing window managers like i3 & dwm.
I have feeling that these WMs tend to have all opened apps are visible at all time. So its not best to use in smaller screen size.
alt+m will full-screen whichever window your mouse is hovering over, and alt+t will switch back to tile mode
Thanks. It looks good. I am currently on i3 but I might give this a try. One question, does dwm have smart gaps like i3, i.e., no gaps when there is a single window in a tag/workspace? I really like that feature.
here is a suggestion, please increase the size of whatever you're showing, and extra increase the size of terminal font..
I just patched a zoom feature into my terminal emulator, should be better going forward.
Great video, thank you!!
Can anyone share some resources on keyboard keywords? Like in xkb keymappings, there are some keywords like Prior Next Super and whatnot...
you can find it in your include folders. one is xkbcommon and another one is x11 xkblib
for some reasons, youtube keep deleting my straightforward directory comments so i guess youtube sucks mad dick...
I wonder why is config.def.h being patched and what's the reason behind separating this file and config.h?
config.def.h gets copied to config.h if config.h does not yet exist. I believe "def" is for "default".
what if a new version of patch get released? do i have to re-patch it with the newer diff?
No. As long as you use the same build of dwm, you won't need to re-patch them. Newer patches seem to be for newer version of the program with source changes, but most people don't "update" the program since it would require redownloading and re-applying all patches.
nice, thanx :D
@@bubbyroosh4038 Then you are running an old version of st and missing out on new features. Applying new patches is very quick unless they don't work with the new st version.
@@randomuser2579 If you're using a suckless program why would you update it to get a new feature :| If you get a build that you like, you don't need to update it (unless you want the new features) as some patches may become incompatible/outdated.
@@bubbyroosh4038 this reasoning would be true to any software, not only suckless stuff. if you are happy with v1, why bother updating to v2? well, because in 99% of the cases we do want the new features! and that kinda makes your point irrelevant, albeit correct.
the diff with suckless is that you may (very unlikely) lose your own mods if they are no longer supported by the new version. you would still need to re-patch the new version, but that shouldn't be much of an effort anyway, as already pointed out.
Really glad I found your channel! You have helped me a few times already! =^_^=
"Betty Crockett" :D
Great guide
Great stuff! If you can zoom in a bit would be greater
how to make auto start app ?
in .xinitrc file:
app-name &
app2-name &
There is also a patch for dwm to autostart but I think this is easier
why is he doing this manually instead of using patch?
Dwm moveresize does not work
JIT, I downloaded dwm.
well all I need now is to buy myself a buttonboard :P
thank you
#including a .c file... 🤔😬
Man, I like your content but you gotta learn to zoom in bruhh. I couldn't see shit in my mobile and now I'm on my PC and still have a little difficulty. Not everyone has a huge ass monitor.
It's a damn shame shame your videos and most of the videos by others about suckless, are not suckless.
What colors are you using in your terminal?
Its gruvbox