dwm as default wm

[Moderator Brian Masinick]

Helpful

Up

0

::

Anonymous wrote:

I have the 6.2 dwm source tarball downloaded. on my laptop I’m going to git clone and build it.

You’ve got this @linuxdaddy!

Can’t wait to see it in action, best wishes!

--
Brian Masinick

[Member olsztyn]

Helpful

Up

0

::

Any suggestion how to define sound volume control hardware buttons (Vol +. Vol -) in config.h?
So far nothing I found on the web actually works and I am surprised Suckless omitted such basic function from default config.h…
On IceWM volume control works flawlessly, just for comparison…
Thanks and Regards…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member Xecure]

Helpful

Up

0

::

From: https://dwm.suckless.org/
[…]
* Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.
[…]

Not very friendly…

olsztyn wrote:

Any suggestion how to define sound volume control hardware buttons (Vol +. Vol -) in config.h?

Adapt these instructions:
https://gist.github.com/palopezv/efd34059af6126ad970940bcc6a90f2e
To alsa-mixer commands.
Example:

static const char *upvol[]   = { "/usr/bin/amixer", "sset", "Master", "5%+",     NULL };
static const char *downvol[] = { "/usr/bin/amixer", "sset", "Master", "5%-",     NULL };
static const char *mutevol[] = { "/usr/bin/amixer", "sset", "Master", "toggle",  NULL };

and then add them to the volume control keys as in the example linked above:

static Key keys[] = {
	{ 0,                       XF86XK_AudioLowerVolume, spawn, {.v = downvol } },
	{ 0,                       XF86XK_AudioMute, spawn, {.v = mutevol } },
	{ 0,                       XF86XK_AudioRaiseVolume, spawn, {.v = upvol   } },
};

And don’t forget to add the dependency
#include <X11/XF86keysym.h>

NOTE: I don’t use dwm. Let the experts improve or correct this answer.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Anonymous]

Helpful

Up

0

::

well Dwm isn’t for me after reading the website. they can keep people out as well
that want to be part of it with their pompous and arrogance..

This keeps its userbase small and elitist. No novices asking stupid questions.

[Moderator Brian Masinick]

Helpful

Up

0

::

@andyprough: You may be our resident expert these days regarding dwm unless our friend @manyroads: is also listening in.

--
Brian Masinick

[Member olsztyn]

Helpful

Up

0

::

Xecure wrote:

And don’t forget to add the dependency
#include <X11/XF86keysym.h>

Thank you Xecure!
I was previously testing this exactly code in config.h and did not work…
Of course – I forgot/did not include this header before C code compile. Instead I was using a local file with the same content. Somehow it made a difference.
Work well now, thanks to your pointing this out…
Thanks and Regards…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member olsztyn]

Helpful

Up

0

::

Xecure wrote:

From: https://dwm.suckless.org/
[…]
* Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.
[…]
Not very friendly…

Personally I do not take it too literally and I sense they did not mean anything condescending by wording this way. They stress the fact they rely on config file being in C as input to compilation in order to produce executable WM, which might sound restricting to those who are willing to venture to do so. I had nothing to do with C code for the past 20 years and very little before that. So it is almost as new thing to me to go through C code and figure out compile errors.

However, with regards to technical aspect of dwm:
Personally I see nothing wrong with using a ready to go, preconfigured and precompiled dwm distribution if it includes all needed functions, as discussed in the initial posts of this thread. Although to further customize a modification of config.h header and recompilation is required but no patches may be typically needed.
But again, I am new to dwm as well so resident experts, such as Andyprough and Koo and Xecure will be much more authoritative than such a novice user as I am…
Thanks again and Regards…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member andyprough]

Helpful

Up

0

::

Xecure wrote:

olsztyn wrote:

Any suggestion how to define sound volume control hardware buttons (Vol +. Vol -) in config.h?

Adapt these instructions:
https://gist.github.com/palopezv/efd34059af6126ad970940bcc6a90f2e
To alsa-mixer commands.
Example:

static const char *upvol[]   = { "/usr/bin/amixer", "sset", "Master", "5%+",     NULL };
static const char *downvol[] = { "/usr/bin/amixer", "sset", "Master", "5%-",     NULL };
static const char *mutevol[] = { "/usr/bin/amixer", "sset", "Master", "toggle",  NULL };

and then add them to the volume control keys as in the example linked above:

static Key keys[] = {
	{ 0,                       XF86XK_AudioLowerVolume, spawn, {.v = downvol } },
	{ 0,                       XF86XK_AudioMute, spawn, {.v = mutevol } },
	{ 0,                       XF86XK_AudioRaiseVolume, spawn, {.v = upvol   } },
};

And don’t forget to add the dependency
#include <X11/XF86keysym.h>

This worked for me. I don’t have dedicated volume keys on my keyboard, so I bound the volume control to Super-Shift-u (“up” volume by 5%), Super-Shift-d (“down” volume by 5%), and Super-Shift-m (“mute” volume). Here’s my lines from /usr/src/dwm/config.h:

1. I changed my mod key from left-Alt to the Super key, by changing line 53 in my config.h file (your line numbers may differ from mine) to read:
#define MODKEY Mod4Mask

2. I defined the commands as they did in your example, on lines 70-72 in my config.h file (again, your line numbers may differ – it’s the last three lines in my “/* commands */” section):

static const char *upvol[] = { "/usr/bin/amixer", "sset", "Master", "5%+", 	NULL };
static const char *downvol[] = { "/usr/bin/amixer", "sset", "Master", "5%-", 	NULL };
static const char *mutevol[] = { "/usr/bin/amixer", "sset", "Master", "toggle", NULL };

3. I assigned each command to its key combination, on lines 81-83 in my config.h file, in my “static Key keys[]” section:

{ MODKEY|ShiftMask,			XK_u,	   spawn,		   {.v = upvol } },
{ MODKEY|ShiftMask,			XK_d,	   spawn,		   {.v = downvol } },
{ MODKEY|ShiftMask,			XK_m,	   spawn,		   {.v = mutevol } },

4. Did a ‘sudo make install’, logged out and back in, and the volume controls are working.

Good stuff!

• This reply was modified 1 year, 9 months ago by andyprough.

[Member ex_Koo]

Helpful

Up

0

::

I like the fact that DWM is source compiled just for the learning experience, and it doesn’t stop there then you get to learn about coding. This is one thing I miss about Debian is compiling from source code its a fun way to learn.
One thing that surprised me was how many packages are installed with core x64 over 1100. ArchLabs I end up with about 850.

What I compile on antiX
13-gap
dwm
rofi 
ranger
cava
mpd
ncmpcpp
kitty <<<< curl
alacritty <<<< rust

• This reply was modified 1 year, 9 months ago by ex_Koo.
• This reply was modified 1 year, 9 months ago by ex_Koo.

[Moderator Brian Masinick]

Helpful

Up

0

::

@koo: I think that is the interesting thing about dwm too. We do have a good tiling window manager available, as anticapitalista has mentioned, so it’s not about availability, it’s about learning, experience and fun.

--
Brian Masinick

[Member blur13]

Helpful

Up

0

::

@Koo (post #64803)

Totally agree with this. Most packages on Debian are hopelessly out of date. Before I got the hang of how easy it is to compile from source I used to scour the internet for third party PPTs, but thats not so great from a security standpoint. I’ve noticed antiX does provide some newer versions of essentials like feh, mpv, and TLP than the ones available in the debian buster repos.

I also compiled Alacritty and really liked it, until I saw that it consumed about 40-50 MiB of memory. It has an insane scrollback buffer of 10 000 lines thats all pre-loaded. That can be changed to something more sensible (for my needs), like 100 lines. But that still leaves Alacritty taking up 30 MiB.

So I moved on to ST, and thats also compiled in a similar way to DWM with a config.h file. There is a popular preconfigured version of ST by lukesmithxyz that has some nice features like scrollback, solarized fonts, and common sense keybindings (ie VIM). But that version increased memory footprint from around 3 MiB to 12 MiB so now Im using vanilla ST. Just changed the font size and colors, and a few keybindings. The few times I need scrollback I just pipe it through Less, or use tmux.

[Member olsztyn]

Helpful

Up

0

::

blur13 wrote:

So I moved on to ST, and thats also compiled in a similar way to DWM with a config.h file. There is a popular preconfigured version of ST by lukesmithxyz that has some nice features like scrollback, solarized fonts, and common sense keybindings (ie VIM). But that version increased memory footprint from around 3 MiB to 12 MiB so now Im using vanilla ST. Just changed the font size and colors, and a few keybindings.

Although I do use ST when under DWM and it is extremely small memory footprint, nevertheless aside from necessity of modifying the font so to make it better for eyes I find it too rudimentary for extensive use, such as missing cut and paste.
So I find myself often switching to ROXTerm, already installed on antiX. Memory used by ROXTerm appears to be way higher than 12M, perhaps about 30M but it is only temporary for the time of ROXTerm use so I do not see much problem.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member olsztyn]

Helpful

Up

0

::

While testing dwm I am encountering a behavior which appears to me a bug:
– Starting an application in a tab, such as web browser. For simplicity it is the only app in that tab.
– After some use of this app I am closing it via Alt-Shift-c, as the default key binding to close app.
– Sometimes although the app appears to be closed the last image of the app remains displayed in the tab. Frozen of course. Expected behavior should be to clear display, as most often is the case.

Now, to be clear the dwm infrastructure seems fine, such as apps in other tabs are just fine, just the image of closed app in the tab where was previously active. Such tab is available to start another app, whereupon the new app replaces the previous dead image, no problem here.
Is this a known bug or just me? Just to mention, the dwm.c code is default 6.2 with no patches…
Thanks and Regards…

Update!:
looks like it was me after all, not any bug in dwm…
Switched testing to another dwm instance (on another Live usb stick), the same version and I am not able to re-create this behavior. DWM operates perfectly fine here and image of app is being cleared upon app closing.
There must have been some corruption on the other test instance of Live antiX/dwm.
Sorry for confusion…

Update #2:
After further testing of this on new instance of antiX/dwm it appears that this faulty behavior could be re-created after all… After a short time of operation of dwm an example of issue that came back:
– Open e.g. ROXTerm in any available tag.
– Close that ROXTerm via closing key sequence Alt-Shift-c.
– Image of ROXTerm remains on the screen. Although the tag is free (no square on tag) and available to start another app.
Looks more and more a bug, although just cosmetic… Image is not cleared on close.

• This reply was modified 1 year, 9 months ago by olsztyn.
• This reply was modified 1 year, 9 months ago by olsztyn.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member andyprough]

Helpful

Up

0

::

blur13 wrote:

So I moved on to ST, and thats also compiled in a similar way to DWM with a config.h file. There is a popular preconfigured version of ST by lukesmithxyz that has some nice features like scrollback, solarized fonts, and common sense keybindings (ie VIM). But that version increased memory footprint from around 3 MiB to 12 MiB so now Im using vanilla ST. Just changed the font size and colors, and a few keybindings. The few times I need scrollback I just pipe it through Less, or use tmux.

I did not think about using tmux with st – you are right, that makes st basically usable (in terms of scrollback and search features) without having to do a lot of patching of st. Very good, I think I’m hooked on tmux now.

[Moderator Brian Masinick]

Helpful

Up

0

::

Anonymous wrote:

well Dwm isn’t for me after reading the website. they can keep people out as well that want to be part of it with their pompous and arrogance.

This keeps its userbase small and elitist. No novices asking stupid questions.

OK, please allow me to comment. Everyone is still free to formulate their own opinion, but here is the jist of what is said that is “objectionable” to some people:

dwm is customized through editing its source code, which makes it extremely fast and secure – it does not process any input data which isn’t known at compile time, except window titles and status text read from the root window’s name. You don’t have to learn Lua/sh/ruby or some weird configuration file format (like X resource files), beside C, to customize it for your needs: you only have to learn C (at least in order to edit the header file).
Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.

Perhaps the “no novices asking stupid questions” is what offends some people. If so, there certainly are other choices available, even on our own antiX. The wording may be a bit strong, but it’s also true – because of the fact that it is a source code based window manager, it is only in binary form IF a distribution chooses to compile and build it, in which case, the “support”, if any, is the responsibility of the distribution, which probably has disclaimers that say things like: “This software is made freely available AS IS. You are welcome to use it without cost, but there are no warranties, expressed or otherwise. By choosing to use this software you do so at your own risk”.

Those may or may not be the exact words, but the simple fact is that the makers of dwm cannot be held responsible for source code that: 1) is made freely available, 2) carries no warranty, and 3) if built in binary form, is created and produced by someone ELSE.

Therefore, though their comment may come across in a crass, snotty manner, the reality is that it is the simple truth. The truth is also that their software is a fringe product. Though it has some features that a few people will like, the VAST majority of people will not, and therefore, even though their comment might come across unpleasantly, it’s also both accurate and true.

I’m not trying to be “mean” here any more than they are. They’re actually stating the truth.

Many of you remember Sheldon Cooper from Big Bang Theory. As a child, and also as an adult physics researcher, he often came across as rude, crass, … fill in the blank _____.

Most of the time, though rude sounding, he was generally truthful. I saw a Young Sheldon episode the other night where he “learned” to “Cheat” from his older brother, only to find out that his brother’s actions (and then his), had consequences.

So I return to the comment that was made. It was true; it does not take into consideration the “feelings” of novices, but it’s also truthful in expressing the thought that novices probably won’t (they aren’t and haven’t been) interested in dwm throughout its lifetime. We’re talking about it here, quite frankly, because we are geeks; maybe not quite like Sheldon Cooper, but geeks nevertheless.

Also, fans of Big Bang Theory MAY recall that at the very end, when Sheldon and Amy accepted their award, Sheldon HAD prepared an arrogant speech, bragging about his knowledge, years of work, and his final success. Instead, at the end, he realized just how much his friends and family had supported him, accepted him, though he rarely made any provisions for anyone else. In the end, Sheldon realized this and thanked each of his closest friends, then the story ended.

I suggest that being thankful for free software, whether from kind, compassionate individuals or from arrogant hotheads – or whatever you happen to feel about this person or that – it’s still FREELY AVAILABLE SOFTWARE. Each of us has the choice to use PROPRIETARY software, PAY for it, or choose from the many alternatives, and even then, choose stuff like antiX, dwm, HerbstluftWM – or we can go with IceWM or Fluxbox here, or we can move over to our relative, MX Linux, and use the Xfce desktop, the KDE desktop, the manyroads variations, including one with dwm, or we can use Fedora, Mageia, Arch, Linux From Scratch… the list goes on.

We have choices, each of us. We don’t have to choose the software HERE, though many of us WILL, and we do.

At the end of my own long-winded comments, let’s try to be helpful to one another. We do not have to agree on everything; that’s unrealistic. It IS nice, however, to have dialogs, and yet when we finish, we can thank each other for the thoughts, then each of us is free to make our own choice. Now THAT freedom I REALLY enjoy!

Best wishes to all!

--
Brian Masinick

[Author]

Posts