Re: [dev] dwm: Maybe a combination of columns and grids?

[sewn]

On January 26, 2024 1:57:07 PM GMT+03:00, Greg Reagle  
wrote:
>On Thu, Jan 25, 2024, at 8:16 PM, lain. wrote:
>> On 2024年01月25日 14:48, the silly Greg Reagle claimed to have said:
>>> Salutations.  Is there already a dwm layout patch for what I describe below?
>>> 
>>> I love the way that the columns patch handles the master area, i.e. the 
>>> ability to control its width and number of windows, and that the windows in 
>>> the master area take up the full height of the display.  In the stacking 
>>> area, though, I'd love for those windows to be managed like a (gapless) 
>>> grid.  In this context gapless does not mean a few pixels, but a big chunk 
>>> missing.
>>> 
>>> Does it already exist?  Thanks!
>>
>> Yes, this sounds like the default behavior of DWM.
>
>The default behavior of dwm is to stack the stacking area, not to manage it as 
>a grid.
>

You can emulate a grid-like layout in the default dwm layout by incrementing 
the amount of masters (incnmaster, mod+I)

Re: [dev] dwm: Maybe a combination of columns and grids?

[Greg Reagle]

On Thu, Jan 25, 2024, at 8:16 PM, lain. wrote:
> On 2024年01月25日 14:48, the silly Greg Reagle claimed to have said:
>> Salutations.  Is there already a dwm layout patch for what I describe below?
>> 
>> I love the way that the columns patch handles the master area, i.e. the 
>> ability to control its width and number of windows, and that the windows in 
>> the master area take up the full height of the display.  In the stacking 
>> area, though, I'd love for those windows to be managed like a (gapless) 
>> grid.  In this context gapless does not mean a few pixels, but a big chunk 
>> missing.
>> 
>> Does it already exist?  Thanks!
>
> Yes, this sounds like the default behavior of DWM.

The default behavior of dwm is to stack the stacking area, not to manage it as 
a grid.

Re: [dev] dwm: Maybe a combination of columns and grids?

[lain.]

On 2024年01月25日 14:48, the silly Greg Reagle claimed to have said:
> Salutations.  Is there already a dwm layout patch for what I describe below?
> 
> I love the way that the columns patch handles the master area, i.e. the 
> ability to control its width and number of windows, and that the windows in 
> the master area take up the full height of the display.  In the stacking 
> area, though, I'd love for those windows to be managed like a (gapless) grid. 
>  In this context gapless does not mean a few pixels, but a big chunk missing.
> 
> Does it already exist?  Thanks!

Yes, this sounds like the default behavior of DWM.

-- 
lain.

Did you know that?
90% of all emails sent on a daily basis are being sent in plain text, and it's 
super easy to intercept emails as they flow over the internet?
Never send passwords, tokens, personal information, or other volunerable 
information without proper PGP encryption!

If you're writing your emails unencrypted, please consider sending PGP 
encrypted emails for security reasons.
You can find my PGP public key at: https://fair.moe/lain.asc

Every good email client is able to send encrypted emails.
If yours can't, then you should consider switching to a secure email client, 
because yours just sucks.

My recommendations are Claws Mail or NeoMutt.
For instructions on how to encrypt your emails:
https://unixsheikh.com/tutorials/gnupg-tutorial.html


signature.asc
Description: PGP signature

Re: [dev] [dwm][PATCH] Add function to exec into another executable

[Dmitry Bogatov]

On Sat, Jul 15, 2023 at 08:48:29PM +0600, NRK wrote:
> Hi Dmitry,
> 
> >  but I don't need to restart X, which is much more annoying.
> 
> There's no need to patch anything to achieve this. You can do something
> like this in your xinitrc:
> 
>   while :; do dwm; done
> 
> This will re-run dwm after it quits. And if you want to quit for real,
> then you can just invoke `shutdown`.

Or exec into runsv(8). You are right, thank you for the nice idea.
Nevermind the patch.

Re: [dev] [dwm][PATCH] Add function to exec into another executable

[NRK]

Hi Dmitry,

>  but I don't need to restart X, which is much more annoying.

There's no need to patch anything to achieve this. You can do something
like this in your xinitrc:

while :; do dwm; done

This will re-run dwm after it quits. And if you want to quit for real,
then you can just invoke `shutdown`.

- NRK

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

[Spenser Truex]

On 23/05/26 11:07AM, v4hn wrote:
> On Fri, May 26, 2023 at 02:50:20AM -0300, Spenser Truex wrote:
> > I just want my windows to open where I opened
> > them. There is no kitchen sink included.
>
> I would like that too, but the linked project doesn't do it.
> It doesn't even work when ran through `dmenu`, but instead hides/unhides
> whatever window you focused before you opened dmenu. :)

That's true, sorry I was unclear. That's what I'm trying to do with it.
I think it can be done with a POSIX queue.
>
>
> v4hn
>
> --
> Michael 'v4hn' Görner, M.Sc. Cognitive Science, Research Associate
> Universität Hamburg
> Faculty of Mathematics, Informatics and Natural Sciences
> Department of Informatics
> Group Technical Aspects of Multimodal Systems
>
> Vogt-Kölln-Straße 30
> D-22527 Hamburg
>
> Room: F-315
> Phone: +49 40 42883-2432
> Website: https://tams.informatik.uni-hamburg.de/people/goerner/



-- 
CAEE B377 FC82 BAF9 102C  D22F C5CE D003 1AA8 E281
Spenser Truexhttps://equwal.com


signature.asc
Description: PGP signature

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

[Santtu Lakkala]

On 26.5.2023 9.19, NRK wrote:> `system` is a function that should never 
be used unless the person is

aware of all the shell shenanigans that can bite back. The above is an
extreme example, but *any* character that has special meaning to shell
can cause problems.

You should instead look into exec and/or posix_spawn functions before
going any further.


Yes, this, system() is most of the time both the wrong way and the hard 
way. Created a PR[0] to demonstrate how to use posix_spawnp() instead.


Also, as a sidenote; there is no C--, there's nothing -- about C.

[0]: https://github.com/equwal/swallow-c--/pull/2

--
Santtu

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

[v4hn]

On Fri, May 26, 2023 at 02:50:20AM -0300, Spenser Truex wrote:
> I just want my windows to open where I opened
> them. There is no kitchen sink included.

I would like that too, but the linked project doesn't do it.
It doesn't even work when ran through `dmenu`, but instead hides/unhides
whatever window you focused before you opened dmenu. :)


v4hn

-- 
Michael 'v4hn' Görner, M.Sc. Cognitive Science, Research Associate
Universität Hamburg
Faculty of Mathematics, Informatics and Natural Sciences
Department of Informatics
Group Technical Aspects of Multimodal Systems

Vogt-Kölln-Straße 30
D-22527 Hamburg

Room: F-315
Phone: +49 40 42883-2432
Website: https://tams.informatik.uni-hamburg.de/people/goerner/


signature.asc
Description: PGP signature

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

[NRK]

On Thu, May 25, 2023 at 07:42:04PM -0300, Spenser Truex wrote:
> I converted this swallow program to C, not that it makes any difference
> at this code size. It's just a couple of malloc'd strings.
> 
> https://github.com/equwal/swallow-c--

$ ./swallow '$(rm -fr $HOME)'

`system` is a function that should never be used unless the person is
aware of all the shell shenanigans that can bite back. The above is an
extreme example, but *any* character that has special meaning to shell
can cause problems.

You should instead look into exec and/or posix_spawn functions before
going any further.

- NRK

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

[Spenser Truex]

On 23/05/26 07:24AM, Sagar Acharya wrote:
> Beautiful code. As a rookie user, how will this code be used? Can this be a 
> complete Xenocara/Xorg alternative?
> Thanking you

A very humourous response. I just want my windows to open where I opened
them. There is no kitchen sink included.

It is used like this

./swallow mpv

cheers

> Sagar Acharya
> http://humaaraartha.in 
>
>
>
> 26 May 2023, 05:45 by tr...@equwal.com:
>
> > Greetings,
> >
> > I converted this swallow program to C, not that it makes any difference
> > at this code size. It's just a couple of malloc'd strings.
> >
> > https://github.com/equwal/swallow-c--
> >
> > I'd like to make it actually transfer the terminal's focus rather than
> > async open and hide itself. That way you get the program you opened in the
> > tag you opened it in, which is something I've been trying to do for a
> > long time in multiple window managers.
> >
> > The author pointed out that "startup hooks" can do this in some window
> > managers, but I like the idea of not even having that be part of the WM
> > itself.
> >
> >
> > --
> > CAEE B377 FC82 BAF9 102C  D22F C5CE D003 1AA8 E281
> > Spenser Truexhttps://equwal.com
> >
>

-- 
CAEE B377 FC82 BAF9 102C  D22F C5CE D003 1AA8 E281
Spenser Truexhttps://equwal.com


signature.asc
Description: PGP signature

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

[Sagar Acharya]

Beautiful code. As a rookie user, how will this code be used? Can this be a 
complete Xenocara/Xorg alternative?
Thanking you
Sagar Acharya
http://humaaraartha.in 



26 May 2023, 05:45 by tr...@equwal.com:

> Greetings,
>
> I converted this swallow program to C, not that it makes any difference
> at this code size. It's just a couple of malloc'd strings.
>
> https://github.com/equwal/swallow-c--
>
> I'd like to make it actually transfer the terminal's focus rather than
> async open and hide itself. That way you get the program you opened in the
> tag you opened it in, which is something I've been trying to do for a
> long time in multiple window managers.
>
> The author pointed out that "startup hooks" can do this in some window
> managers, but I like the idea of not even having that be part of the WM
> itself.
>
>
> -- 
> CAEE B377 FC82 BAF9 102C  D22F C5CE D003 1AA8 E281
> Spenser Truexhttps://equwal.com
>

Re: [dev] [dwm] DWM Multihead Missing Cursor

[fossy]

Hi.
I think you 2nd monitor ate the cursor, you should keep it on a leash.

I know it's off-topic, but cmon, humor is healthy

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[Hiltjo Posthuma]

On Sat, Apr 08, 2023 at 11:02:56PM +0200, Storkman wrote:
> On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> > Hello everyone,
> > 
> > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> > handling` [1] commit, since dmenu_extended does not change anything here,
> > is this a regression or bug introduced with this commit or
> > dmenu_extended need to adapt to conform the change? thanks.
> 
> From sigaction(2):
> > A child created via fork(2) inherits a copy of its parent's signal 
> > dispositions.
> > During an execve(2), the dispositions of handled signals are reset to the 
> > default;
> > the dispositions of ignored signals are left unchanged.
> 
> This would explain why running programs affected by this through st works,
> since it runs "signal(SIGCHLD, SIG_DFL)" before executing the shell 
> (st.c:715).
> 
> Adding "signal(SIGCHLD, SIG_DFL)" before execvp in spawn() at dwm.c:1657 fixes
> anki and mpv with youtube-dl for me.
> 
> > 
> > [1] https://github.com/MarkHedleyJones/dmenu-extended/
> > [2] 
> > https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html
> > 
> 

Thanks,

I've committed a fix based on your suggestion to dwm.
I also committed it for tabbed as it had a similar change.

If there are further iterations or patch suggestions feel free to reply,

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[pfx]

Voila, one single line of change make dmenu_extended_run launch again!

git diff dwm.c 
diff --git a/dwm.c b/dwm.c
index c2bd871..f8f83f8 100644
--- a/dwm.c
+++ b/dwm.c
@@ -1653,6 +1653,7 @@ spawn(const Arg *arg)
if (dpy)
close(ConnectionNumber(dpy));
setsid();
+   signal(SIGCHLD, SIG_DFL);
execvp(((char **)arg->v)[0], (char **)arg->v);
die("dwm: execvp '%s' failed:", ((char **)arg->v)[0]);

On 08.04.23 23:02, Storkman wrote:
> On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> > Hello everyone,
> > 
> > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> > handling` [1] commit, since dmenu_extended does not change anything here,
> > is this a regression or bug introduced with this commit or
> > dmenu_extended need to adapt to conform the change? thanks.
> 
> From sigaction(2):
> > A child created via fork(2) inherits a copy of its parent's signal 
> > dispositions.
> > During an execve(2), the dispositions of handled signals are reset to the 
> > default;
> > the dispositions of ignored signals are left unchanged.
> 
> This would explain why running programs affected by this through st works,
> since it runs "signal(SIGCHLD, SIG_DFL)" before executing the shell 
> (st.c:715).
> 
> Adding "signal(SIGCHLD, SIG_DFL)" before execvp in spawn() at dwm.c:1657 fixes
> anki and mpv with youtube-dl for me.
> 
> > 
> > [1] https://github.com/MarkHedleyJones/dmenu-extended/
> > [2] 
> > https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html
> > 
> 

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[Storkman]

On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> Hello everyone,
> 
> I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> handling` [1] commit, since dmenu_extended does not change anything here,
> is this a regression or bug introduced with this commit or
> dmenu_extended need to adapt to conform the change? thanks.

>From sigaction(2):
> A child created via fork(2) inherits a copy of its parent's signal 
> dispositions.
> During an execve(2), the dispositions of handled signals are reset to the 
> default;
> the dispositions of ignored signals are left unchanged.

This would explain why running programs affected by this through st works,
since it runs "signal(SIGCHLD, SIG_DFL)" before executing the shell (st.c:715).

Adding "signal(SIGCHLD, SIG_DFL)" before execvp in spawn() at dwm.c:1657 fixes
anki and mpv with youtube-dl for me.

> 
> [1] https://github.com/MarkHedleyJones/dmenu-extended/
> [2] 
> https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html
> 

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[Страхиња Радић]

On 23/04/08 07:24PM, p...@mailbox.org wrote:
> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };

How about:

> > (Try changing your
> > dmenu_extended keybind to something else and see if that works or not).

1. What happens if you use:

static const char *dmenu_extend[] = { "dmenu_run", NULL };

2. What happens when you run from the terminal emulator:

2.a:
$ dmenu_extended_run

2.b:
$ which dmenu_extended_run

3. What happens if you add the path obtained from 2.b to the command

> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
 ^-- here, before 'd'?



signature.asc
Description: PGP signature

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[pfx]

I built dwm based on https://aur.archlinux.org/packages/dwm-git

> diff config.h src/dwm/config.def.h
> 62d61
> < static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
> 67d65
> < { MODKEY,   XK_o,  spawn,  {.v = 
> dmenu_extend } },

in config.h involved only those two lines of change

> uname -a
> Linux hostname 6.2.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 07 Apr 2023 
> 02:10:43 + x86_64 GNU/Linux


On 08.04.23 21:17, Hiltjo Posthuma wrote:
> Hi,
> 
> Please provide more information about your operating system etc.
> 
> This is with vanilla dwm and only the above change applied? (If not please do
> so).
> 
> Thanks,
> 
> -- 
> Kind regards,
> Hiltjo
> 

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[Hiltjo Posthuma]

On Sat, Apr 08, 2023 at 07:24:07PM +0200, p...@mailbox.org wrote:
> - patch is disabled
> - `dwm 2> ~/dwm.log` shows nothing
> 
> define command as
> 
> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
> 
> bind the command to a keyboard shortcut
> 
> static Key keys[] = {
> MODKEY,   XK_o,  spawn,  {.v = 
> dmenu_extend } },
> ...
> };
> 
> same config, revert to 89f9905 dmenu_extend just works.
> 
> On 08.04.23 21:45, NRK wrote:
> > Hi,
> > 
> > On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> > > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> > > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> > > handling` [1] commit, since dmenu_extended does not change anything here,
> > > is this a regression or bug introduced with this commit or
> > > dmenu_extended need to adapt to conform the change? thanks.
> > 
> > You'll need to provide more information. What does your config look
> > like? Does dwm print any error message to stderr? Did you try to
> > reproduce with a vanilla dwm? Etc.
> > 
> > Without providing more information it's not possible to say what's going
> > on here, especially because that commit doesn't really do anything to
> > process launching. Which takes me to the question, how did you verify
> > that it's this commit that's causing the problem?
> > 
> > Because the commit right before it (89f9905 grabkeys: Avoid missing
> > events when a keysym maps to multiple keycodes) seems like something
> > that might actually mess with keybinds. (Try changing your
> > dmenu_extended keybind to something else and see if that works or not).
> > 
> > - NRK
> > 
> 

Hi,

Please provide more information about your operating system etc.

This is with vanilla dwm and only the above change applied? (If not please do
so).

Thanks,

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[pfx]

- patch is disabled
- `dwm 2> ~/dwm.log` shows nothing

define command as

static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };

bind the command to a keyboard shortcut

static Key keys[] = {
MODKEY,   XK_o,  spawn,  {.v = 
dmenu_extend } },
...
};

same config, revert to 89f9905 dmenu_extend just works.

On 08.04.23 21:45, NRK wrote:
> Hi,
> 
> On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> > handling` [1] commit, since dmenu_extended does not change anything here,
> > is this a regression or bug introduced with this commit or
> > dmenu_extended need to adapt to conform the change? thanks.
> 
> You'll need to provide more information. What does your config look
> like? Does dwm print any error message to stderr? Did you try to
> reproduce with a vanilla dwm? Etc.
> 
> Without providing more information it's not possible to say what's going
> on here, especially because that commit doesn't really do anything to
> process launching. Which takes me to the question, how did you verify
> that it's this commit that's causing the problem?
> 
> Because the commit right before it (89f9905 grabkeys: Avoid missing
> events when a keysym maps to multiple keycodes) seems like something
> that might actually mess with keybinds. (Try changing your
> dmenu_extended keybind to something else and see if that works or not).
> 
> - NRK
> 

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[NRK]

Hi,

On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> handling` [1] commit, since dmenu_extended does not change anything here,
> is this a regression or bug introduced with this commit or
> dmenu_extended need to adapt to conform the change? thanks.

You'll need to provide more information. What does your config look
like? Does dwm print any error message to stderr? Did you try to
reproduce with a vanilla dwm? Etc.

Without providing more information it's not possible to say what's going
on here, especially because that commit doesn't really do anything to
process launching. Which takes me to the question, how did you verify
that it's this commit that's causing the problem?

Because the commit right before it (89f9905 grabkeys: Avoid missing
events when a keysym maps to multiple keycodes) seems like something
that might actually mess with keybinds. (Try changing your
dmenu_extended keybind to something else and see if that works or not).

- NRK

Re: [dev] dwm 6.4 compilation error on FreeBsd

[beastie]

On Thu, 16 Feb 2023 12:23:00 +0600
NRK  wrote:

> 
> I think we might need to define `_XOPEN_SOURCE=700L`. Does this fix
> the issue:
> 
>   diff --git a/config.mk b/config.mk
># flags
>   -CPPFLAGS = -D_DEFAULT_SOURCE -D_BSD_SOURCE
> -D_POSIX_C_SOURCE=200809L -DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}
> +CPPFLAGS = -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE=700L
> -DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}
> 
> - NRK
> 

Yes, this fixes the issue, thank you for your support :D

- Beastie <3

Re: [dev] dwm 6.4 compilation error on FreeBsd

[Hiltjo Posthuma]

On Thu, Feb 16, 2023 at 06:07:02PM +1300, beastie wrote:
> Hello I am experiencing an error when trying to compile the latest
> version of dwm from https://git.suckless.org/dwm,
> 
> Here is the commit that I think is causing the issue:
> https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html
> 
> here is the error output: https://pst.moe/paste/pdnucy
> 
> Thanks,
> Beastie
> 

Hello,

Just a reminder again to you (and others) to really send more information about
your system and how to reproduce the issue.  For example which version of
FreeBSD do you use?

I have some older FreeBSD 10 or 11 system somewhere I think, so will test it
with that, probably this weekend,

-- 
Kind regards,
Hiltjo

Re: [dev] dwm 6.4 compilation error on FreeBsd

[NRK]

> dwm.c:1549:31: error: use of undeclared identifier 'SA_NOCLDWAIT'
> sa.sa_flags = SA_NOCLDSTOP | SA_NOCLDWAIT | SA_RESTART;
>  ^
> dwm.c:1549:46: error: use of undeclared identifier 'SA_RESTART'
> sa.sa_flags = SA_NOCLDSTOP | SA_NOCLDWAIT | SA_RESTART;

Both of those are specified by POSIX and the FreeBSD manpage has it as well:
https://man.freebsd.org/cgi/man.cgi?query=sigaction=0=0=FreeBSD+13.1-RELEASE+and+Ports=default=html

I think we might need to define `_XOPEN_SOURCE=700L`. Does this fix the
issue:

diff --git a/config.mk b/config.mk
 # flags
-CPPFLAGS = -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809L 
-DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}
+CPPFLAGS = -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE=700L 
-DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}

- NRK

Re: [dev] [dwm] [st] benefits (or not) of -march=x86-64-v3 and gcc optimizations

[Laslo Hunhold]

On Tue, 7 Feb 2023 10:30:24 +0200
Κρακ Άουτ  wrote:

Dear Κρακ,

> I have compiled dwm & st using -march=x86-64-v3 (tried
> -march=x86-64-v2 also). To be honest they are both (dwm & st) fast
> and snappy with their default configuration and I cannot spot any
> difference when compiled with -march=x86-64-v3 or v2. Is there any
> point adding them?
> 
> Related, would -O2 or -O3 flags give any benefit?
> 
> As I mentioned, in practice I don't see any differences. I'm
> wondering if theoretically there could be some positive effect.
> People who know how exactly the code works are better suited to
> supply a definitive answer than me, that's why I'm posting here.

what Petr and Roberto said, but also: The -Os flag (i.e. go for
smallest size) often yields more performant code than -O2 or -O3.

As a general note: I found the use of efficent and smart data
structures to always be the best way to dramatically speed up code.
It's very inconsistent to rely on "smart" optimizations by the
compiler, and even though they can go very far, they can rarely beat
well-thought-out data structures.

With best regards

Laslo

Re: [dev] [dwm] [st] benefits (or not) of -march=x86-64-v3 and gcc optimizations

[Petr Šabata]

It's extremely unlikely you could observe any difference using these
tools on any remotely modern hardware. In practical terms it doesn't
matter.

But if you want to satisfy your curiosity, you could do some
profiling, I guess; or decompile the binaries and eyeball the
generated instructions. I'd suspect the results would be nearly
identical, however, considering what and how these programs do.

P

On Tue, Feb 7, 2023 at 9:37 AM Κρακ Άουτ  wrote:
>
> I have compiled dwm & st using -march=x86-64-v3 (tried -march=x86-64-v2 
> also). To be honest they are both (dwm & st) fast and snappy with their 
> default configuration and I cannot spot any difference when compiled with 
> -march=x86-64-v3 or v2. Is there any point adding them?
>
> Related, would -O2 or -O3 flags give any benefit?
>
> As I mentioned, in practice I don't see any differences. I'm wondering if 
> theoretically there could be some positive effect. People who know how 
> exactly the code works are better suited to supply a definitive answer than 
> me, that's why I'm posting here.
>
>

Re: [dev] [dwm] [st] benefits (or not) of -march=x86-64-v3 and gcc optimizations

[Roberto E. Vargas Caballero]

Hi,

On Tue, Feb 07, 2023 at 10:30:24AM +0200, Κρακ Άουτ wrote:
> As I mentioned, in practice I don't see any differences. I'm wondering if 
> theoretically there could be some positive effect. People who know how 
> exactly the code works are better suited to supply a definitive answer than 
> me, that's why I'm posting here.

There are interactive programs, so almost all the time is wasted waiting
for user input. Don't try to optimize for things that don't need to be
optimized ;)

Regards,

Re: [dev] [dwm] Bluetooth XF86 keys not working

[Anskrevy]

On 1/16/23 22:23, Storkman wrote:



On January 17, 2023 3:03:52 AM UTC, Anskrevy  
wrote:

I've got XF86XK_AudioPlay bound in my config.h with the necessary
include file, and this hotkey works when I use my keyboard. However,
when sent from a pair of bluetooth headphones the hotkey isn't
triggered. I've got the following xev output which shows the two keys
are slightly different



This was actually recently fixed.
https://git.suckless.org/dwm/commit/89f9905714c1c1b2e8b09986dfbeca15b68d8af8.html


So I was reinventing the wheel. Thanks for pointing this out!

Re: [dev] [dwm] Bluetooth XF86 keys not working

[Storkman]

On January 17, 2023 3:03:52 AM UTC, Anskrevy  
wrote:
>I've got XF86XK_AudioPlay bound in my config.h with the necessary
>include file, and this hotkey works when I use my keyboard. However,
>when sent from a pair of bluetooth headphones the hotkey isn't
>triggered. I've got the following xev output which shows the two keys
>are slightly different
>

This was actually recently fixed.
https://git.suckless.org/dwm/commit/89f9905714c1c1b2e8b09986dfbeca15b68d8af8.html

Re: [dev] [dwm] view() and toggleview() functions

[NRK]

On Mon, Jan 16, 2023 at 08:21:57PM +0900, A Farzat wrote:
> Btw, on the email subject it says [SPAM Warning!]. Is it anything I need
> to be concerned with?

No, you're good. It was just a false positive on my end and I forgot to
remove that before replying.

- NRK

Re: [dev] [dwm] Obtain focused monitor

[A Farzat]

On 23/01/12 11:35am, Gauthier Östervall wrote:
> On Sun, 8 Jan 2023 at 11:21, A Farzat  wrote:
> >
> > Is there a way to obtain the currently focused monitor in dwm? I want to
> > use it in my script to control which monitor gets its brightness
> > modified.
> 
> Do you mean obtain from outside the dwm process? Not directly, that I
> am aware of. But you could try and query X for that. This SO answer
> might be of interest: https://unix.stackexchange.com/a/677884
> 
> selmon is not a command, it's a global variable. It's not accessible
> outside the dwm process, if you don't make it accessible by modifying
> dwm. It also points to a dwm monitor struct, it holds data for the
> internals of dwm. You could probably use it to find out what you need,
> but I'm not sure it would be the simplest way.

Thank you for your elaboration. Yes, querying X is much simpler and more
portable, but the best answers I found tell you on which monitor your
cursor is, which in dwm is not necessarily your focused monitor.

I was actually thinking about doing what you suggested in your second
paragraph. My plan was to make dwm listen for a signal, at which it
writes the value of the current monitor to a file. The problem is that
is too complex for such a simple function. There is also the question of
portability.

My other approach would be trying to copy what dmenu does - it checks
the position of the currently focused window, or the cursor if no window
is focused. Not fool-proof but much simpler and more portable. The
problem is I hardly know anything about X. I tried copying the code from
dmenu and removing the extra parts, and this is what I got:

```c
#include 
#include 
#include 
#include 

#define MAX(A, B)   ((A) > (B) ? (A) : (B))
#define MIN(A, B)   ((A) < (B) ? (A) : (B))
#define INTERSECT(x,y,w,h,r)  (MAX(0, MIN((x)+(w),(r).x_org+(r).width)  - \
MAX((x),(r).x_org)) * MAX(0, MIN((y)+(h),(r).y_org+(r).height) - \
MAX((y),(r).y_org)))

static int screen;
static Display *dpy;
static Window root;

int main(void)
{
if (!(dpy = XOpenDisplay(NULL))) {
fputs("cannot open display\n", stderr);
return 1;
}
screen = DefaultScreen(dpy);
root = RootWindow(dpy, screen);
int x, y, i, j;
unsigned int du;
Window w, dw, *dws;
XWindowAttributes wa;
XineramaScreenInfo *info;
Window pw;
int a, di, n, area = 0;

i = 0;
if ((info = XineramaQueryScreens(dpy, ))) {
XGetInputFocus(dpy, , );
if (w != root && w != PointerRoot && w != None) {
/* find top-level window containing current input focus */
do {
if (XQueryTree(dpy, (pw = w), , , , ) && dws)
XFree(dws);
} while (w != root && w != pw);
/* find xinerama screen with which the window intersects most */
if (XGetWindowAttributes(dpy, pw, ))
for (j = 0; j < n; j++)
if ((a = INTERSECT(wa.x, wa.y, wa.width, wa.height, 
info[j])) > area) {
area = a;
i = j;
}
}
/* no focused window is on screen, so use pointer location instead */
if (!area && XQueryPointer(dpy, root, , , , , , , ))
for (i = 0; i < n; i++)
if (INTERSECT(x, y, 1, 1, info[i]))
break;

XFree(info);
}

printf("Monitor: %d\n", i);
}
```

If there is any improvement I can do, I would be grateful for letting me
know.

> What's not clear is what format you need for your script. What does
> the script need, in order to work? If you only need stuff from X,
> asking X directly is probably simpler, there's already an API. It also
> would make your tool more agnostic, it would probably work with other
> WM using X.

What I need is the number of the focused monitor, so that when I press
my keybinding, the script adjusts the current monitor instead of all the
monitors. I call also use the program to obtain the correct brightness
for the statusbar based on which monitor it is currently appearing on.

I'm sorry for making this bigger than it is supposed to be, but I think
this is also an oppurtunity for me to learn a thing or two about how
these programs work.

Best regards,
Farzat


signature.asc
Description: PGP signature

Re: [dev] [dwm] Obtain focused monitor

[Gauthier Östervall]

On Sun, 8 Jan 2023 at 11:21, A Farzat  wrote:
>
> Is there a way to obtain the currently focused monitor in dwm? I want to
> use it in my script to control which monitor gets its brightness
> modified.

Do you mean obtain from outside the dwm process? Not directly, that I
am aware of. But you could try and query X for that. This SO answer
might be of interest: https://unix.stackexchange.com/a/677884

selmon is not a command, it's a global variable. It's not accessible
outside the dwm process, if you don't make it accessible by modifying
dwm. It also points to a dwm monitor struct, it holds data for the
internals of dwm. You could probably use it to find out what you need,
but I'm not sure it would be the simplest way.

What's not clear is what format you need for your script. What does
the script need, in order to work? If you only need stuff from X,
asking X directly is probably simpler, there's already an API. It also
would make your tool more agnostic, it would probably work with other
WM using X.

Re: [dev] [dwm] Obtain focused monitor

[Tom Schwindl]

Hi,

On Sun Jan 8, 2023 at 11:40 AM CET, A Farzat wrote:
> On 23/01/08 11:32am, Hiltjo Posthuma wrote:
> > On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote:
> > > Is there a way to obtain the currently focused monitor in dwm? I want to
> > > use it in my script to control which monitor gets its brightness
> > > modified.
> > > 
> > > Regards,
> > > Farzat
> > 
> > selmon
> > 
> > -- 
> > Kind regards,
> > Hiltjo
> > 
>
> And how do I access that command? If possible I want to access it from
> a shell script.
>
> I am open to modifying the dwm source code if necessary.
>
> Regards,
> Farzat

selmon isn't a command. It's a variable in the source code located at
dwm.c:269 (upstream). You could write a function like the following to dump
its value to stdout/stderr. Now you have to figure out where to call it.

--
Best Regards,
Tom Schwindl


diff --git a/dwm.c b/dwm.c
index 03baf42b3502..4fa8253c91e0 100644
--- a/dwm.c
+++ b/dwm.c
@@ -234,6 +234,7 @@ static int xerror(Display *dpy, XErrorEvent *ee);
 static int xerrordummy(Display *dpy, XErrorEvent *ee);
 static int xerrorstart(Display *dpy, XErrorEvent *ee);
 static void zoom(const Arg *arg);
+static void dumpmon(void);
 
 /* variables */
 static const char broken[] = "broken";
@@ -276,6 +277,13 @@ static Window root, wmcheckwin;
 struct NumTags { char limitexceeded[LENGTH(tags) > 31 ? -1 : 1]; };
 
 /* function implementations */
+static void
+dumpmon(void)
+{
+   if (selmon)
+   fprintf(stdout, "%d\n", selmon->num);
+}
+
 void
 applyrules(Client *c)
 {

Re: [dev] [dwm] Obtain focused monitor

[Hiltjo Posthuma]

On Sun, Jan 08, 2023 at 07:40:21PM +0900, A Farzat wrote:
> On 23/01/08 11:32am, Hiltjo Posthuma wrote:
> > On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote:
> > > Is there a way to obtain the currently focused monitor in dwm? I want to
> > > use it in my script to control which monitor gets its brightness
> > > modified.
> > > 
> > > Regards,
> > > Farzat
> > 
> > selmon
> > 
> > -- 
> > Kind regards,
> > Hiltjo
> > 
> 
> And how do I access that command? If possible I want to access it from
> a shell script.
> 
> I am open to modifying the dwm source code if necessary.
> 
> Regards,
> Farzat

Hi,

For example using the dmenumon variable, it is set in spawn():
http://git.suckless.org/dwm/commit/ba56fe9fea0a28d8184a727a987836a0903e2682.html

Hope this helps,

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Obtain focused monitor

[A Farzat]

On 23/01/08 11:32am, Hiltjo Posthuma wrote:
> On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote:
> > Is there a way to obtain the currently focused monitor in dwm? I want to
> > use it in my script to control which monitor gets its brightness
> > modified.
> > 
> > Regards,
> > Farzat
> 
> selmon
> 
> -- 
> Kind regards,
> Hiltjo
> 

And how do I access that command? If possible I want to access it from
a shell script.

I am open to modifying the dwm source code if necessary.

Regards,
Farzat


signature.asc
Description: PGP signature

Re: [dev] [dwm] Obtain focused monitor

[Hiltjo Posthuma]

On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote:
> Is there a way to obtain the currently focused monitor in dwm? I want to
> use it in my script to control which monitor gets its brightness
> modified.
> 
> Regards,
> Farzat

selmon

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] dmenu dwm wrong screen

[Hiltjo Posthuma]

On Fri, Oct 28, 2022 at 11:07:44AM +0200, Yan Doroshenko wrote:
> Helo,
> 
> 
> I have a strange behavior of dmenu inside dwm with two monitors. dmenu is
> displayed on the screen with the mouse cursor (instead of the active one) if
> there are no windows open on any screen. Otherwise it works fine.
> 
> 
> Is this expected behavior?
> 
> 
> Thanks,
> 
> Yan
> 
> 

Hi,

Thanks for reporting it. It was changed in dwm 6.4, but since multiple users
has asked (it doesn't seem to be some edge-case) I've reverted back the change
in the git version of dwm.

See also:
https://git.suckless.org/dwm/commit/ba56fe9fea0a28d8184a727a987836a0903e2682.html
https://git.suckless.org/dwm/commit/c2b748e7931e5f28984efc236f9b1a212dbc65e8.html

-- 
Kind regards,
Hiltjo

Re: [dev] dwm 6.4 bug

[spaceman]

NRK writes:
> I had bought up this issue in the past and the conclusion was that there
> should just be a comment added [0] as users are treated as programmers.
>
> [0]: https://lists.suckless.org/hackers/2208/18484.html
>
> - NRK
>

I should have read the archives before emailing.

Thanks for the information.

Regards,
spaceman

Re: [dev] dwm 6.4 bug

[Tom Schwindl]

> I had bought up this issue in the past and the conclusion was that there
> should just be a comment added [0] as users are treated as programmers.
>
> [0]: https://lists.suckless.org/hackers/2208/18484.html
>

So be it! :-)
A user report is a good reason for adding the comment.

--
Best Regards,
Tom Schwindl

Re: [dev] dwm 6.4 bug

[NRK]

On Wed, Oct 26, 2022 at 02:10:19PM +, Tom Schwindl wrote:
> However, a length check & truncation
> of the last char doesn't seem harmful at all. Thoughts?

I had bought up this issue in the past and the conclusion was that there
should just be a comment added [0] as users are treated as programmers.

[0]: https://lists.suckless.org/hackers/2208/18484.html

- NRK

Re: [dev] dwm 6.4 bug

[Tom Schwindl]

Hi,

On Tue Oct 25, 2022 at 5:03 PM CEST, spaceman wrote:
> Hi,
>
> While compiling dwm on slackware 15 I get the following (with 
> _FORTIFY_SOURCE=3):

And therein lies the catch. The call to strncpy(3) copies the symbol of the
currently selected layout to the layout symbol (ltsymbol) which will later be
printed to the bar. The maximum length of this symbol is 16 chars and normally
this isn't an issue since those symbols do not consist of large strings.
But in case someone decides to create a longer symbol text, this would overflow.
Given that we compile with -Wall, the compiler would probably emit a warning
and the user should notice his mistake. However, a length check & truncation
of the last char doesn't seem harmful at all. Thoughts?

> In file included from /usr/include/string.h:519,
>  from dwm.c:29:
> In function 'strncpy',
> inlined from 'arrangemon' at dwm.c:400:2,
> inlined from 'arrange' at dwm.c:394:3,
> inlined from 'arrange' at dwm.c:384:1:
> /usr/include/bits/string_fortified.h:95:10: warning: '__builtin_strncpy' 
> specified bound 16 equals destination size [-Wstringop-truncation]
>95 |   return __builtin___strncpy_chk (__dest, __src, __len,
>   |  ^~
>96 |   __glibc_objsize (__dest));
>   |   ~
> In function 'strncpy',
> inlined from 'arrangemon' at dwm.c:400:2,
> inlined from 'arrange' at dwm.c:391:3:
> /usr/include/bits/string_fortified.h:95:10: warning: '__builtin_strncpy' 
> specified bound 16 equals destination size [-Wstringop-truncation]
>95 |   return __builtin___strncpy_chk (__dest, __src, __len,
>   |  ^~
>96 |   __glibc_objsize (__dest));
>   |   ~
> In function 'strncpy',
> inlined from 'setlayout' at dwm.c:1508:2:
> /usr/include/bits/string_fortified.h:95:10: warning: '__builtin_strncpy' 
> specified bound 16 equals destination size [-Wstringop-truncation]
>95 |   return __builtin___strncpy_chk (__dest, __src, __len,
>   |  ^~
>96 |   __glibc_objsize (__dest));
>
> This was enough to stop me updating from 6.3.
>

The last time I could find a modified strncpy in the logs in one of those
places is somewhere around 2009. This isn't something introduced lately and
should also occur when building older versions of dwm.

--
Best Regards,
Tom Schwindl

Re: [dev] [dwm]: something like the xfce scale all windows feature

[T Taylor Gurney]

On Thu, Jun 30, 2022 at 01:09:04PM -0800, Britton Kerin wrote:
> I've got one of the high-res monitors and everything looks really
> tiny.  I notec xfce4 has this
> "scale everything by 2" feature that addresses this, what's the
> easiest way to get this in dwm?
> 
> I didn't see any patch saying it does it, might have missed one though
> there are so many now :)
> 

With dwm I just use something like the following, which is in my .xinitrc:

  xrandr --output eDP-1 --scale 0.5

I'm sure there are other ways to do it that make things look nicer, but my
guess is that this is the simplest.

Taylor

Re: [dev] [dwm]: something like the xfce scale all windows feature

[Nick]

Quoth Britton Kerin:
> I've got one of the high-res monitors and everything looks really
> tiny.  I notec xfce4 has this
> "scale everything by 2" feature that addresses this, what's the
> easiest way to get this in dwm?

You can just make the font bigger in dwm's config.h, and the border 
size if you want. That's the extent to which dwm is involved, as 
it's just a window manager.

I'm guessing you want other programs to do scaling - there are 
different environment variables to set for different GUI toolkits, 
this webpage gives a reasonable overview - set these in your 
.xprofile or wherever you see fit: 
https://wiki.archlinux.org/title/HiDPI#GUI_toolkits

Re: [dev] [dwm] Xorg crashed if I ran Pale Moon in dwm

[Kyryl Melekhin]

Hi, just don't use version 31, it's just broken IIRC.
Compile 29.4.6

Re: [dev] [dwm] Xorg crashed if I ran Pale Moon in dwm

[Страхиња Радић]

On 22/06/22 01:04, p...@mailbox.org wrote:
> > the discussion https://forum.palemoon.org/viewtopic.php?f=3=28505

[   140.237] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not supported. 
Supported versions are: 1.10, 1.20, and 1.00 ES

^ This is most probably caused by mismatched/misconfigured video drivers and/or
misconfigured X.Org (try asking on the forums of your distro instead).

dwm is very simple and doesn't use fancy GL APIs, unlike bloated web browsers
like Palemoon, so this has nothing to do with it.


signature.asc
Description: PGP signature

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

[Hiltjo Posthuma]

On Tue, May 24, 2022 at 10:06:21PM -0400, Christopher Brown wrote:
> I am using the latest git version, so I reverted the commit. However,
> I am still experiencing the issue after doing that.
> 
> Christopher
> 
> On Sat, May 7, 2022 at 12:15 PM Hiltjo Posthuma  
> wrote:
> >
> > On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote:
> > > Hello,
> > >
> > > I have been intermittently encountering an issue where dwm messes up
> > > my monitor resolutions when powering on my two monitors. Frequently,
> > > both screens will be combined on one monitor while the other monitor
> > > does not receive input. The "Two independent outputs" section of the
> > > multi monitor dwm documentation seems to describe what I am
> > > experiencing. I tried using the xrandr options it mentions, but I will
> > > still sometimes encounter the issue. Does anyone know how to prevent
> > > this from happening?
> > >
> > > Thank you,
> > > Christopher
> > >
> >
> > Hi Christopher,
> >
> > Do you run the latest git version?
> >
> > Can you try the commit
> > https://git.suckless.org/dwm/commit/d93ff48803f04f1363bf303af1d7e6ccc5cb8d3f.html
> > or if you run the git version revert the commit and see if it solves the 
> > issue?
> >
> > --
> > Kind regards,
> > Hiltjo
> >
> 

Hi Christopher,

OK thanks for testing and reporting back atleast,

I'm not sure what the issue is.

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

[Christopher Brown]

I am using the latest git version, so I reverted the commit. However,
I am still experiencing the issue after doing that.

Christopher

On Sat, May 7, 2022 at 12:15 PM Hiltjo Posthuma  wrote:
>
> On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote:
> > Hello,
> >
> > I have been intermittently encountering an issue where dwm messes up
> > my monitor resolutions when powering on my two monitors. Frequently,
> > both screens will be combined on one monitor while the other monitor
> > does not receive input. The "Two independent outputs" section of the
> > multi monitor dwm documentation seems to describe what I am
> > experiencing. I tried using the xrandr options it mentions, but I will
> > still sometimes encounter the issue. Does anyone know how to prevent
> > this from happening?
> >
> > Thank you,
> > Christopher
> >
>
> Hi Christopher,
>
> Do you run the latest git version?
>
> Can you try the commit
> https://git.suckless.org/dwm/commit/d93ff48803f04f1363bf303af1d7e6ccc5cb8d3f.html
> or if you run the git version revert the commit and see if it solves the 
> issue?
>
> --
> Kind regards,
> Hiltjo
>

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

[Pontus Stenetorp]

On Sat 07 May 2022, Yan Doroshenko wrote:
> 
> Not sure if this is of any help, but I was having troubles with DWM on
> two monitors as well, one screen was not recognized by DWM.
> 
> A 1 second delay before running my screen layout script was enough to
> fix it, here's an explanation:
> 
> https://wiki.archlinux.org/title/xrandr#Setting_resolution_from_.xinitrc_doesn't_work

Is the “right way” (tm) to do it not to set things up in your Xorg.conf though? 
I am assuming that your errors have something to do with the state of X when 
dwm is started, thus surely the way way to solve it should be to ensure that X 
is in the state you want *before* dwm is launched, no?

I know the Xorg.conf syntax and documentation is a bit of a mess, but I have 
never encountered any issues interacting with a WM once I got it configured.

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

[Yan Doroshenko]

On 07.05.22 18:13, Hiltjo Posthuma wrote:

On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote:

Hello,

I have been intermittently encountering an issue where dwm messes up
my monitor resolutions when powering on my two monitors. Frequently,
both screens will be combined on one monitor while the other monitor
does not receive input. The "Two independent outputs" section of the
multi monitor dwm documentation seems to describe what I am
experiencing. I tried using the xrandr options it mentions, but I will
still sometimes encounter the issue. Does anyone know how to prevent
this from happening?

Thank you,
Christopher


Hi Christopher,

Do you run the latest git version?

Can you try the commit
https://git.suckless.org/dwm/commit/d93ff48803f04f1363bf303af1d7e6ccc5cb8d3f.html
or if you run the git version revert the commit and see if it solves the issue?

Not sure if this is of any help, but I was having troubles with DWM on 
two monitors as well, one screen was not recognized by DWM.


A 1 second delay before running my screen layout script was enough to 
fix it, here's an explanation:


https://wiki.archlinux.org/title/xrandr#Setting_resolution_from_.xinitrc_doesn't_work


Regards,

Yan



OpenPGP_signature
Description: OpenPGP digital signature

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

[Hiltjo Posthuma]

On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote:
> Hello,
> 
> I have been intermittently encountering an issue where dwm messes up
> my monitor resolutions when powering on my two monitors. Frequently,
> both screens will be combined on one monitor while the other monitor
> does not receive input. The "Two independent outputs" section of the
> multi monitor dwm documentation seems to describe what I am
> experiencing. I tried using the xrandr options it mentions, but I will
> still sometimes encounter the issue. Does anyone know how to prevent
> this from happening?
> 
> Thank you,
> Christopher
> 

Hi Christopher,

Do you run the latest git version?

Can you try the commit
https://git.suckless.org/dwm/commit/d93ff48803f04f1363bf303af1d7e6ccc5cb8d3f.html
or if you run the git version revert the commit and see if it solves the issue?

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

[Markus Wichmann]

On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote:
> Hello,
>
> I have been intermittently encountering an issue where dwm messes up
> my monitor resolutions when powering on my two monitors. Frequently,
> both screens will be combined on one monitor while the other monitor
> does not receive input. The "Two independent outputs" section of the
> multi monitor dwm documentation seems to describe what I am
> experiencing. I tried using the xrandr options it mentions, but I will
> still sometimes encounter the issue. Does anyone know how to prevent
> this from happening?
>
> Thank you,
> Christopher
>

dwm is unlikely to be the culprit here, although it also doesn't help
any. dwm only consumes the Xinerama information, it does not perform any
settings itself. So whatever is going wrong is likely to be with the
startup of your X server. I would suggest you investigate how the server
starts in your case, and how it attempts to deal with multiple displays.

Ciao,
Markus

Re: [dev] [dwm] Multihead Issues Autostart

[NRK]

On Sun, May 01, 2022 at 06:57:33PM +0200, Yan Doroshenko wrote:
> (stupid qustion alert)
> 
> But how can I try, whether my xrandr in autostart works, if I run version
> with no autostart patch?
> 

Hi Yan,

You don't need a patch to execute something at startup. If you're using
startx directly, then look into `xinitrc` (man 1 xinit has some
examples). And if you're using some login/display manager then look into
it's documentation instead.

- NRK

Re: [dev] [dwm] Multihead Issues Autostart

[Yan Doroshenko]

On 01.05.22 15:10, Hiltjo Posthuma wrote:

On Sun, May 01, 2022 at 12:56:50PM +0200, Yan Doroshenko wrote:

Hello,


I'm using DWM on two monitors with cool_autostart patch and in the autostart
array I'm running xrandr to set the monitor layout.

Quite often a situation happens when the second monitor is enabled (arandr
displays it as active and in correct position, feh sets the background on
it), but is unrecognized by DWM (there's no panel on it and windows can not
be moved onto it). Any change in display layout fixes the issue and DWM
recognizes the second screen.


Do you have any ideas as to why it can be happening?


Thanks,

Yan


Can you try the latest git version (without patches)?


(stupid qustion alert)

But how can I try, whether my xrandr in autostart works, if I run 
version with no autostart patch?




OpenPGP_signature
Description: OpenPGP digital signature

Re: [dev] [dwm] Multihead Issues Autostart

[Hiltjo Posthuma]

On Sun, May 01, 2022 at 12:56:50PM +0200, Yan Doroshenko wrote:
> Hello,
> 
> 
> I'm using DWM on two monitors with cool_autostart patch and in the autostart
> array I'm running xrandr to set the monitor layout.
> 
> Quite often a situation happens when the second monitor is enabled (arandr
> displays it as active and in correct position, feh sets the background on
> it), but is unrecognized by DWM (there's no panel on it and windows can not
> be moved onto it). Any change in display layout fixes the issue and DWM
> recognizes the second screen.
> 
> 
> Do you have any ideas as to why it can be happening?
> 
> 
> Thanks,
> 
> Yan
> 

Can you try the latest git version (without patches)?

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] [dwm] possible regression in 8806b6e

[Hiltjo Posthuma]

On Mon, Apr 25, 2022 at 05:38:35PM +0100, Chris Down wrote:
> Hiltjo Posthuma writes:
> > Whats the similar issue exactly? Does this issue also happen when bisecting 
> > the
> > same commit (so its a also regression)?
> 
> For 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size
> hints"), the issue is that c->isfixed may not be set early, which might
> affect whether we intend to make the window floating or not.
> 
> For bece862a0fc4 ("manage: For isfloating/oldstate check/set, ensure trans
> client actually exists"), the issue is that some non-SDL client which
> actually _should_ float have WM_TRANSIENT_FOR set to the root window. I
> posted about this on hackers@ a few weeks ago.[0]
> 
> For 8806b6e23793, I think the change I suggested should be sufficient, but
> would like to get confirmation from Ethan first and then will submit it as a
> proper patch.
> 

Yes please

> For bece862a0fc4, I think it might just need to be reverted unless more
> specific logic can be applied, since it seems over the top to add more logic
> just to reliably distinguish SDL clients from other affected clients.
> 

I've reverted the patch. It can be reworked to fix both issues (the regression 
and the initial
reason it was posted) maybe.

> In both cases the symptoms are that some subset of clients may not float
> when they should, but in the case of 8806b6e23793 it's "fixed" windows where
> the dimensions are fixed in size hints, and in the case of bece862a0fc4 it's
> windows with WM_TRANSIENT_FOR set to the root window (like the gpg2
> pinentry).
> 
> 0: https://lists.suckless.org/hackers/2203/18220.html

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] [dwm] possible regression in 8806b6e

[Chris Down]

Ethan Marshall writes:

Completely fixed. All affected windows now behave as they did before the
patch - so, problem solved on my end.

Thanks for all your help Chris.


Excellent, thanks for getting back. I've submitted it as a proper patch.

Re: [dev] [dwm] possible regression in 8806b6e

[Ethan Marshall]

Completely fixed. All affected windows now behave as they did before the
patch - so, problem solved on my end.

Thanks for all your help Chris.

Ethan

Re: [dev] [dwm] possible regression in 8806b6e

[Chris Down]

Hiltjo Posthuma writes:

Whats the similar issue exactly? Does this issue also happen when bisecting the
same commit (so its a also regression)?


For 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size hints"), 
the issue is that c->isfixed may not be set early, which might affect whether 
we intend to make the window floating or not.


For bece862a0fc4 ("manage: For isfloating/oldstate check/set, ensure trans 
client actually exists"), the issue is that some non-SDL client which actually 
_should_ float have WM_TRANSIENT_FOR set to the root window. I posted about 
this on hackers@ a few weeks ago.[0]


For 8806b6e23793, I think the change I suggested should be sufficient, but 
would like to get confirmation from Ethan first and then will submit it as a 
proper patch.


For bece862a0fc4, I think it might just need to be reverted unless more 
specific logic can be applied, since it seems over the top to add more logic 
just to reliably distinguish SDL clients from other affected clients.


In both cases the symptoms are that some subset of clients may not float when 
they should, but in the case of 8806b6e23793 it's "fixed" windows where the 
dimensions are fixed in size hints, and in the case of bece862a0fc4 it's 
windows with WM_TRANSIENT_FOR set to the root window (like the gpg2 pinentry).


0: https://lists.suckless.org/hackers/2203/18220.html


signature.asc
Description: PGP signature

Re: [dev] [dwm] possible regression in 8806b6e

[Jochen Sprickerhof]

* Hiltjo Posthuma  [2022-04-25 18:13]:

On Mon, Apr 25, 2022 at 04:00:21PM +0200, Jochen Sprickerhof wrote:

Hi Chris,

* Chris Down  [2022-04-25 14:47]:
> I'm still unable to reproduce the issue, but I am curious, does this fix
> things? :-)
>
> diff --git a/dwm.c b/dwm.c
> index 0fc328a..f2a10c0 100644
> --- a/dwm.c
> +++ b/dwm.c
> @@ -1061,6 +1061,7 @@ manage(Window w, XWindowAttributes *wa)
>XSetWindowBorder(dpy, w, scheme[SchemeNorm][ColBorder].pixel);
>configure(c); /* propagates border_width, if size doesn't change */
>updatewindowtype(c);
> +  updatesizehints(c);
>updatewmhints(c);
>XSelectInput(dpy, w, 
EnterWindowMask|FocusChangeMask|PropertyChangeMask|StructureNotifyMask);
>grabbuttons(c, 0);
>
> My guess is that the pinentry that you're using relies on early
> c->isfixed logic, whereas the one Sebastian and I are using relies on
> WM_TRANSIENT_FOR, so the issue I reported and the one you reported have
> different causes, despite having different symptoms.
>
> If this fixes it, please let me know and I'll send it as a proper patch.

This fixes a similar issue for me.

Thanks!

Jochen


Whats the similar issue exactly?


The splash screen of Jameica https://www.willuhn.de/products/jameica/ 
(Java platform) has a floating window without 8806b6e resp. the change 
above. (I don't really care for the splash screen, only noticed the 
behavior change.)



Does this issue also happen when bisecting the
same commit (so its a also regression)?


Yes. I also tested bece862 but it made no difference.

Cheers Jochen


signature.asc
Description: PGP signature

Re: [dev] [dwm] possible regression in 8806b6e

[Hiltjo Posthuma]

On Mon, Apr 25, 2022 at 04:00:21PM +0200, Jochen Sprickerhof wrote:
> Hi Chris,
> 
> * Chris Down  [2022-04-25 14:47]:
> > I'm still unable to reproduce the issue, but I am curious, does this fix
> > things? :-)
> > 
> > diff --git a/dwm.c b/dwm.c
> > index 0fc328a..f2a10c0 100644
> > --- a/dwm.c
> > +++ b/dwm.c
> > @@ -1061,6 +1061,7 @@ manage(Window w, XWindowAttributes *wa)
> > XSetWindowBorder(dpy, w, scheme[SchemeNorm][ColBorder].pixel);
> > configure(c); /* propagates border_width, if size doesn't change */
> > updatewindowtype(c);
> > +   updatesizehints(c);
> > updatewmhints(c);
> > XSelectInput(dpy, w, 
> > EnterWindowMask|FocusChangeMask|PropertyChangeMask|StructureNotifyMask);
> > grabbuttons(c, 0);
> > 
> > My guess is that the pinentry that you're using relies on early
> > c->isfixed logic, whereas the one Sebastian and I are using relies on
> > WM_TRANSIENT_FOR, so the issue I reported and the one you reported have
> > different causes, despite having different symptoms.
> > 
> > If this fixes it, please let me know and I'll send it as a proper patch.
> 
> This fixes a similar issue for me.
> 
> Thanks!
> 
> Jochen

Whats the similar issue exactly? Does this issue also happen when bisecting the
same commit (so its a also regression)?

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] [dwm] possible regression in 8806b6e

[Jochen Sprickerhof]

Hi Chris,

* Chris Down  [2022-04-25 14:47]:
I'm still unable to reproduce the issue, but I am curious, does this 
fix things? :-)


diff --git a/dwm.c b/dwm.c
index 0fc328a..f2a10c0 100644
--- a/dwm.c
+++ b/dwm.c
@@ -1061,6 +1061,7 @@ manage(Window w, XWindowAttributes *wa)
XSetWindowBorder(dpy, w, scheme[SchemeNorm][ColBorder].pixel);
configure(c); /* propagates border_width, if size doesn't change */
updatewindowtype(c);
+   updatesizehints(c);
updatewmhints(c);
XSelectInput(dpy, w, 
EnterWindowMask|FocusChangeMask|PropertyChangeMask|StructureNotifyMask);
grabbuttons(c, 0);

My guess is that the pinentry that you're using relies on early 
c->isfixed logic, whereas the one Sebastian and I are using relies on 
WM_TRANSIENT_FOR, so the issue I reported and the one you reported 
have different causes, despite having different symptoms.


If this fixes it, please let me know and I'll send it as a proper patch.


This fixes a similar issue for me.

Thanks!

Jochen


signature.asc
Description: PGP signature

Re: [dev] [dwm] possible regression in 8806b6e

[Chris Down]

Hi Ethan,

I'm still unable to reproduce the issue, but I am curious, does this fix 
things? :-)


diff --git a/dwm.c b/dwm.c
index 0fc328a..f2a10c0 100644
--- a/dwm.c
+++ b/dwm.c
@@ -1061,6 +1061,7 @@ manage(Window w, XWindowAttributes *wa)
XSetWindowBorder(dpy, w, scheme[SchemeNorm][ColBorder].pixel);
configure(c); /* propagates border_width, if size doesn't change */
updatewindowtype(c);
+   updatesizehints(c);
updatewmhints(c);
XSelectInput(dpy, w, 
EnterWindowMask|FocusChangeMask|PropertyChangeMask|StructureNotifyMask);
grabbuttons(c, 0);

My guess is that the pinentry that you're using relies on early c->isfixed 
logic, whereas the one Sebastian and I are using relies on WM_TRANSIENT_FOR, so 
the issue I reported and the one you reported have different causes, despite 
having different symptoms.


If this fixes it, please let me know and I'll send it as a proper patch.

Thanks,

Chris

Re: [dev] [dwm] possible regression in 8806b6e

[Ethan Marshall]

Just re-ran the bisection and got 8806b6e on both stock dwm and my
build. Reverting this commit fixes this change in both. Reverting
bece862 has no change in either, so I would assume we can eliminate that
commit as the issue.

Could this be related to the handling of fixed-size windows? I was under
the impression that windows of a fixed size are treated as automatically
floating by dwm. Could that have been thrown off by this new size logic?

Ethan

On 23/04/22 10:16am, Chris Down wrote:
> Hi Ethan,
> 
> Just checking, are you sure this bisects to 8806b6e23793 ("manage:
> propertynotify: Reduce cost of unused size hints")? I saw this issue prior
> to making this patch and bisected to bece862a0fc4 ("manage: For
> isfloating/oldstate check/set, ensure trans client actually exists"). I
> reported this last month here[0].
> 
> I would be surprised if this commit is the cause because I use gpg-askpass
> and the Chromium system printing dialog fairly regularly, although of course
> anything is possible.
> 
> If you're sure it bisects to this commit and not bece862a0fc4, let me know.
> Thanks!
> 
> Chris
> 
> 0: https://lists.suckless.org/hackers/2203/18220.html
> 

Re: [dev] [dwm] possible regression in 8806b6e

[Sebastian LaVine]

On Sat Apr 23, 2022 at 4:28 AM EDT, Chris Down wrote:
> Sebastian LaVine writes:
> >I believe this is known unintended behavior from the patch. I reverted it on 
> >my personal branch.
>
> It looks like you reverted commit bece862a0fc4 ("manage: For 
> isfloating/oldstate check/set, ensure trans client actually exists"), not 
> this 
> commit, right?[0]

Ah yep, sorry for the confusion. I had assumed that was the patch being
talked about and didn't double-check my memory. I was recalling this
message on the hackers list (which...I see you submitted, lol):

https://lists.suckless.org/hackers/2203/18220.html

> In which case that makes me even more confident that bece862a0fc4 ("manage: 
> For 
> isfloating/oldstate check/set, ensure trans client actually exists") is the 
> cause, not 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size 
> hints").
>
> 0: https://git.sr.ht/~smlavine/dwm/commit/c6b8143

Re: [dev] [dwm] possible regression in 8806b6e

[Chris Down]

Sebastian LaVine writes:

I believe this is known unintended behavior from the patch. I reverted it on my 
personal branch.


It looks like you reverted commit bece862a0fc4 ("manage: For 
isfloating/oldstate check/set, ensure trans client actually exists"), not this 
commit, right?[0]


In which case that makes me even more confident that bece862a0fc4 ("manage: For 
isfloating/oldstate check/set, ensure trans client actually exists") is the 
cause, not 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size 
hints").


0: https://git.sr.ht/~smlavine/dwm/commit/c6b8143

Re: [dev] [dwm] possible regression in 8806b6e

[Chris Down]

Hi Ethan,

Just checking, are you sure this bisects to 8806b6e23793 ("manage: 
propertynotify: Reduce cost of unused size hints")? I saw this issue prior to 
making this patch and bisected to bece862a0fc4 ("manage: For 
isfloating/oldstate check/set, ensure trans client actually exists"). I 
reported this last month here[0].


I would be surprised if this commit is the cause because I use gpg-askpass and 
the Chromium system printing dialog fairly regularly, although of course 
anything is possible.


If you're sure it bisects to this commit and not bece862a0fc4, let me know. 
Thanks!


Chris

0: https://lists.suckless.org/hackers/2203/18220.html

Re: [dev] [dwm] possible regression in 8806b6e

[Hiltjo Posthuma]

On Sat, Apr 23, 2022 at 12:39:28AM +0100, Ethan Marshall wrote:
> Hi all,
> 
> I recently noticed that certain dialog windows (such as the Chromium
> system printing dialog and gpg-askpass popups) were being managed as
> tiled windows, rather than floating. This changed recently, so I
> bisected down to this commit:
> 
> 8806b6e2379372900e3d9e0bf6604bc7f727350b is the first bad commit
> commit 8806b6e2379372900e3d9e0bf6604bc7f727350b
> Author: Chris Down 
> Date:   Thu Mar 17 15:56:13 2022 +
> 
> manage: propertynotify: Reduce cost of unused size hints
> ...
> 
> dwm/dwm.c | 8 +---
> 
> Is this intended behavior? Or is this a bug introduced by this patch?
> 
> Thanks
>   Ethan
> 

Hi,

Thanks for the report. It is not known and intended behavior. The patch
shouldn't cause a regression.

@Chris: can you look at it and see if this is an actual regression and send an
updated patch if it is?

Thanks,

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] possible regression in 8806b6e

[Sebastian LaVine]

I believe this is known unintended behavior from the patch. I reverted it on my 
personal branch.


 Original Message 
From: Ethan Marshall 
Sent: April 22, 2022 11:39:28 PM UTC
To: dev@suckless.org
Subject: [dev] [dwm] possible regression in 8806b6e

Hi all,

I recently noticed that certain dialog windows (such as the Chromium
system printing dialog and gpg-askpass popups) were being managed as
tiled windows, rather than floating. This changed recently, so I
bisected down to this commit:

8806b6e2379372900e3d9e0bf6604bc7f727350b is the first bad commit
commit 8806b6e2379372900e3d9e0bf6604bc7f727350b
Author: Chris Down 
Date:   Thu Mar 17 15:56:13 2022 +

manage: propertynotify: Reduce cost of unused size hints
...

dwm/dwm.c | 8 +---

Is this intended behavior? Or is this a bug introduced by this patch?

Thanks
Ethan


---
Sebastian LaVine | https://smlavine.com

Re: [dev] dwm oddity

[Greg Minshall]

Greg and N, thanks.  in fact, adding focusonclick, i no longer see the
problem (well, so far, but long enough to make me think it is resolved).
cheers, Greg

Re: [dev] dwm oddity

[NRK]

On Sun, Apr 03, 2022 at 03:10:48PM -0700, Greg Minshall wrote:
> likely, the heel of my palm is making some (light?) contact with the
> touch pad.

Hi Greg,

You could probably try the "focusonclick" patch[0] to confirm your
suspicion. I personally use it because I find that feature annoying.

But on monocle layout, I don't think it should be possible for the mouse
cursor to change focus. So your problem is probably related to some
patch you're using. Try using vanilla dwm without any patches and see if
you still run into the issue.

[0]: https://dwm.suckless.org/patches/focusonclick/

- NRK

Re: [dev] dwm oddity

[Greg Reagle]

I have not experienced this.

On Sun, Apr 3, 2022, at 6:10 PM, Greg Minshall wrote:
> hi.  i'm using dwm v6.2 under Arch linux.  my own source build.  i'm
> using the "taggrid" patch.  my laptop has a touch pad.
>
> when i am in monocle mode (which i mostly am), every now and then when i
> type a key, i end up in a situation where the application hasn't changed
> (i.e., is what is showing on the screen), but the keyboard focus (and
> the "title" on the bar, next to the tags) changes to one of the
> non-visible apps.  likely, the heel of my palm is making some (light?)
> contact with the touch pad.
>
> i'm wondering if anyone has seen this, or has any thoughts?
>
> cheers, Greg

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

[Ethan Marshall]

> I agree, some advantage I can think of is it would support on a multi-monitor
> support with 10 or more monitors. Otherwise I prefer the current code.

I would suggest that the support of 10 or more monitors is not worth
the added complexity, given how small the proportion of people will be
with such hardware. Part of writing software is making compromise. For
the same reason why it is often better to use fixed-size input buffers
in C, with the risk of cutting off attempts at passing huge inputs, it
is similarly fine to assume that ten monitors is a good maximum - in
this case, anyway. Incorrect behaviour is tolerated if such behaviour
exceeds software design parameters. GIGO.

I do agree that special cases are best to be avoided, but there's
nothing really stopping you from creating another special case for
whatever applications you want to spawn on a specific monitor, passing
such a parameter.

Ethan

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

[Hiltjo Posthuma]

On Thu, Feb 17, 2022 at 11:12:23AM +0100, Страхиња Радић wrote:
> On 22/02/17 01:08, NRK wrote:
> > Assuming there isn't, one alternative could be just using env vars.
> 
> Why would an environment variable be preferable here to a command line
> parameter?
> 
> Environment variables are clunky, messy, insecure, prone to errors, race
> conditions and the whims of a particular setup. They should be avoided 
> whenever
> possible. The suckless way is to have configuration done in config.h instead.
> 
> In this specific example, having a separate dmenumon, which would have to be
> updated, is needed because of C.  It is needed to pass ASCII character for the
> monitor number, which thus has to be constructed by using the expression:
> 
>   '0' + selmon->num
> 
> but we can't use this expression directly in place of dmenumon to initialize
> dmenucmd, because it is not allowed to have non-constant initializer elements 
> in
> C. (Try it as an exercize - you'll get a compilation error.)
> 
> I guess the room for improvement would be to move the code to reassign 
> dmenumon
> to some other (more "optimal") place than spawn function, but I don't see the
> realistic gain from doing that, or need, outside of some abstract purism.

I agree, some advantage I can think of is it would support on a multi-monitor
support with 10 or more monitors. Otherwise I prefer the current code.

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

[Страхиња Радић]

On 22/02/17 01:08, NRK wrote:
> Assuming there isn't, one alternative could be just using env vars.

Why would an environment variable be preferable here to a command line
parameter?

Environment variables are clunky, messy, insecure, prone to errors, race
conditions and the whims of a particular setup. They should be avoided whenever
possible. The suckless way is to have configuration done in config.h instead.

In this specific example, having a separate dmenumon, which would have to be
updated, is needed because of C.  It is needed to pass ASCII character for the
monitor number, which thus has to be constructed by using the expression:

'0' + selmon->num

but we can't use this expression directly in place of dmenumon to initialize
dmenucmd, because it is not allowed to have non-constant initializer elements in
C. (Try it as an exercize - you'll get a compilation error.)

I guess the room for improvement would be to move the code to reassign dmenumon
to some other (more "optimal") place than spawn function, but I don't see the
realistic gain from doing that, or need, outside of some abstract purism.


signature.asc
Description: PGP signature

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

[NRK]

On Wed, Feb 16, 2022 at 05:39:14PM +0100, Hiltjo Posthuma wrote:
> whats the solution/patch?

If there is a "standard" (or at least conventional) way of communicating
the active monitor between wm and other X clients then it's probably
best to follow that.

Assuming there isn't, one alternative could be just using env vars. dwm
would set an env var, say $DWM_CURRENT_MONITOR inside spawn() and
`dmenu_run` can be adjusted to utilize that `-m "$DWM_CURRENT_MONITOR"`
or fallback to some default if the env var doesn't exist.

This would remove the need to special case dmenucmd and would allow
other scripts/programs spawned via dwm to utilize this env var as well.

On Wed, Feb 16, 2022 at 05:39:14PM +0100, Hiltjo Posthuma wrote:
> Whats the issue

Wouldn't consider it an "issue", but rather a place for potential
improvement.

- NRK

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

[Hiltjo Posthuma]

On Wed, Feb 16, 2022 at 05:52:48PM +0600, NRK wrote:
> Hi,
> 
> Currently dmenumon and dmenucmd are hardcoded into spawn(), I noticed
> this after I removed `dmenumon` (as I don't use multimonitor) from
> config.h and saw that the compilation failed.
> 
>   if (arg->v == dmenucmd)
>   dmenumon[0] = '0' + selmon->num;
> 
> While this way of doing things "works", I do wonder if hardcoding things
> like this is the best way to go about solving the issue.
> 
> - NRK
> 

Hi,

Whats the issue and whats the solution/patch?

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Version bump to 6.3

[Quentin Rameau]

> Hi,

Hello,

> Out of curiosity, why the version bump of dwm to 6.3? I haven't seen any
> major changes in logs or news.

I suppose this depends by what you expect as being a major change.

There still have been several changes since the last release from three
years ago.

Version bumps (as in new releases) are for helping packager having a
more up-to-date version of suckless software.

The rest of people use the git version.

Re: [dev] [dwm] default window attaching behaviour

[NRK]

On Wed, Dec 01, 2021 at 12:26:22AM +1000, dther wrote:
> and only launch new "temporary" terminals when I need to run and see
> the output of a command. If I need an TUI volume mixer or something,
> I'd launch it as a tmux window or in floating mode to avoid disturbing
> my layout.

Hi,

You should consider using a "scratchpad" for this purpose. There's a
couple scratchpad patches it in the wiki.

I personally didn't like them though, I don't remember why exactly but
it had something to do with messing up my tag-based workflow.

- NRK

Re: [dev] [dwm] default window attaching behaviour

[lincoln auster]

Hi,

> My tendency is to launch a few "big" programs, most of which can't
> easily run in a terminal (a browser, a terminal running tmux and/or an
> image editor), and only launch new "temporary" terminals when I need
> to run and see the output of a command. If I need an TUI volume mixer
> or something, I'd launch it as a tmux window or in floating mode to
> avoid disturbing my layout.

I do something pretty similar with dwm, under the (usually correct)
assumptions that windows made earlier stick around for less time. I
found I really like unilaterally opening windows floating and centered
by default and then popping them into the tiled layout if I need them to
stick around. It's a pretty simple modification, but I've attached the
patch I use just in case you or anyone on this list would find it helpful!

--
lincoln auster
they/them
From 10f3e8380ee4d1c8acbf7f2da97a47dada93f03e Mon Sep 17 00:00:00 2001
From: elm auster 
Date: Thu, 16 Sep 2021 21:51:40 -0600
Subject: [PATCH] center and float windows by default

---
 dwm.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/dwm.c b/dwm.c
index 5e4d494..77dea02 100644
--- a/dwm.c
+++ b/dwm.c
@@ -286,7 +286,7 @@ applyrules(Client *c)
XClassHint ch = { NULL, NULL };
 
/* rule matching */
-   c->isfloating = 0;
+   c->isfloating = 1;
c->tags = 0;
XGetClassHint(dpy, c->win, );
class= ch.res_class ? ch.res_class : broken;
@@ -1040,11 +1040,13 @@ manage(Window w, XWindowAttributes *wa)
applyrules(c);
}
 
-   if (c->x + WIDTH(c) > c->mon->mx + c->mon->mw)
-   c->x = c->mon->mx + c->mon->mw - WIDTH(c);
-   if (c->y + HEIGHT(c) > c->mon->my + c->mon->mh)
-   c->y = c->mon->my + c->mon->mh - HEIGHT(c);
+   /* center the window */
+   c->x = c->mon->mx + c->mon->mw / 2 - c->w / 2;
+   c->y = c->mon->my + c->mon->mh / 2 - c->h / 2;
+
c->x = MAX(c->x, c->mon->mx);
+   c->y = MAX(c->y, c->mon->my);
+
/* only fix client y-offset, if the client center might cover the bar */
c->y = MAX(c->y, ((c->mon->by == c->mon->my) && (c->x + (c->w / 2) >= 
c->mon->wx)
&& (c->x + (c->w / 2) < c->mon->wx + c->mon->ww)) ? bh : 
c->mon->my);
-- 
2.31.1

Re: [dev] [dwm] default window attaching behaviour

[dther]

On 21/11/29 01:23PM, Mateusz Okulus wrote:
> On 21/11/29 06:25PM, dther wrote:
> > I've been thinking about dwm's default behaviours, ,,,
> 
> As you say you launch new programs as you need them. This means the
> launched program should have highest priority because you want to use it
> right now. <...>
> so you want to open it, do something with it, then close it.

I see- I'd made an assumption here that I now realise doesn't apply to
all users. My tendency is to launch a few "big" programs,
most of which can't easily run in a terminal
(a browser, a terminal running tmux and/or an image editor), and only launch
new "temporary" terminals when I need to run and see the output of a
command. If I need an TUI volume mixer or something, I'd launch it as a tmux
window or in floating mode to avoid disturbing my layout.

> I'm not quite sure what do you mean by displacing the entire stack.
> <...>
> This might be confusing, but only if you open the window for later use.

Realised this is my personal preference- since most of my windows are
long running, I find it useful for them to occupy the same visual area
at all times, in case I need to look at them for reference.

> You'd need to be more specific about your use cases.
> <...> If my assumptions are correct, I'd reconsider if you really need that
> many programs opened in one view. I'd split programs between tags and
> use solutions like tmux or built-in windows.

You're probably right, honestly. My windows are tagged by "purpose"
(e.g. document paging, editing, etc),
and rather than using them like workspaces, I use a heavily modified
version of the old workspaces patch, with each "workspace" being like its
own dwm instance. I'm realising now that my ad-hoc tmux implementation
is hiding the fact that I'm using way too many windows at once.

Thanks for the explanation. Made me rethink how I use my windows,
and that I could probably do with a major rework of my dwm instance.

> All that being said, it was probably just for consistency. You'd
> expect new windows to go on the top of the stack, not the bottom.
> Whether it'd be better for most workflows probably wasn't even
> considered.

This makes sense ._.

Re: [dev] [dwm] default window attaching behaviour

[Mateusz Okulus]

On 21/11/29 06:25PM, dther wrote:
> I've been thinking about dwm's default behaviours, and one of them
> that's always confused me is how newly attached windows, by default,
> launch as the "master". Why is this the case? Intuitively, when I begin
> working, I launch the most important program first, and launch new
> programs as I need them. I'd imagine at least 50% of people follow this
> strategy of launching new windows as well. In general, older windows
> are more "important". Why displace not only the master client,
> but the *entire stack*, for the window least likely to remain useful?
>
> I realise that this is a problem that can be easily solved with a patch
> (and, in fact, I use attachbelow for this reason), but given how common
> (I imagine) the above strategy is, my question is-
> would it be reasonable for dwm's master branch include some way to toggle
> an alternative "attachbottom" strategy?
>
> I'd also like to know if I'm correct about my assumptions.
> Do give thoughts if your "window initialisation"
> thought process is completely different from mine.

As you say you launch new programs as you need them. This means the
launched program should have highest priority because you want to use it
right now.

Older windows are more long lived and important, but in the moment you
want your attention on the new window. It'll be probably a short lived
one too, so you want to open it, do something with it, then close it.

I'm not quite sure what do you mean by displacing the entire stack. I'd
assume you mean the fact that windows are displayed from to bottom of
the stack, so when you add a new windows all windows shift by one place.
This might be confusing, but only if you open the window for later use.

You'd need to be more specific about your use cases. The way I use it is
to launch long lived windows first, and then when I need to change
volume or change music I have a hotkey that opens a terminal with
appropriate program. I want it to be the master, so I can make some
quick changes and close it, and get back to what I was doing. If it
launched at the bottom I'd need to switch to it, make it fullscreen or
new master manually and shortly after close it.

If you mean instead the process of initial initialization of several
long lived programs then attaching to bottom might be helpful. If I
wanted to have a terminal with vim and some other application always
opened I'd probably do it in this order and then I'd need to swap them.

I personally treat tags as workspaces and rarely have more than one
window per tag. I prefer to use tmux, vim windows etc. If I didn't use
tmux, I'd need to have ~6 terminals opened in one "workspace". I'd
probably open them from first to last, but then dwm would place them
from last to first. It would probably get annoying quickly, and I'd
switch it as you did. If I wanted to launch a short lived program I
wouldn't have a problem with additional key chord to go from master to
last window. Even with a bigger screen I'd probably need to make it a
new master or fullscreen it, but it wouldn't be so bad, if done rarely.

I'd guess most people don't start that many windows per view, so the
benefit of new programs being new masters outweighs the reversed order
when launching many programs at once initially.

If my assumptions are correct, I'd reconsider if you really need that
many programs opened in one view. I'd split programs between tags and
use solutions like tmux or built-in windows.

All that being said, it was probably just for consistency. You'd
expect new windows to go on the top of the stack, not the bottom.
Whether it'd be better for most workflows probably wasn't even
considered.

Regards,
mokulus


signature.asc
Description: PGP signature

Re: [dev] [dwm] dwm breaks on synchronized screens

[Thomas Oltmann]

Hi again,

In terms of reproducing this behaviour, all that it seems to take for me is
to 'mirror' the screens, optionally with some windows already open,
and then try to
open/move some more windows. It was relatively consistent so far in
that strange things happened pretty quickly.

I use lxrandr to configure the mirrored screen setup, since that
interface literally has a button to do just that.
I should note that my two displays have differing resolutions
(differing aspect ratios, in fact).
The main (Laptop) monitor has a resolution of 1366 x 768.
The beamer I don't actually know, but it's some sort of 4:3 so I
reckon 1024 x 768, in case that helps.

The issue that v4hn has described sounds like a plausible cause for
the problems I'm having.
I very specifically get the feeling that dwm thinks it is managing two
independent monitors, when there is in
fact only one, leading to such things like active windows getting
stacked directly on top of each other in tiled mode.

Cheers,
  Thomas Oltmann


Am Fr., 12. Nov. 2021 um 12:33 Uhr schrieb v4hn :
>
> Hey everyone,
>
> I can verify issues with multi-monitor setups when screens are 
> overlapping/mirrored.
> I usually avoid this by working with independent screens as well.
>
> With XINERAMA support in dwm you can dynamically configure monitors via 
> xrandr.
> If you configure them to coincide, e.g.,
> `xrandr --output  --auto --same-as `,
> it seems that at least for some configurations dwm creates separate `Monitor` 
> structs
> unconditionally and you can cycle through the monitors via shortcuts.
> But because they overlap you will not even see the bar for one of the monitors
> and window management is screwed up as well.
> Notice that there is actually logic in the code that should prevent this
> for the case where virtual screen positions coincide. (`isuniquegeom`)
>
> Along the same lines of code I recently noticed that dynamically adding an
> independent/unique screen via xrandr can change the Monitor->physical screen 
> association
> and thus move all existing windows to a different physical screen.
> Maybe it's a different bug altogether though, I did not have time to 
> investigate.
>
>
> v4hn
>
> On Fri, Nov 12, 2021 at 09:18:22AM +0100, Laslo Hunhold wrote:
> > On Thu, 11 Nov 2021 19:34:08 +0100
> > Thomas Oltmann  wrote:
> >
> > Dear Thomas,
> >
> > > What do I do about this?
> > > Is it even a bug or just me using dwm for stuff it's not intended to
> > > do? One way or another, how can I do my presentations without
> > > fighting the WM all the time?
> >
> > do you have a way so we can reproduce this?
> >
> > With best regards
> >
> > Laslo
> >
>
> --
> Michael 'v4hn' Görner, M.Sc. Cognitive Science, PhD Student
> Universität Hamburg
> Faculty of Mathematics, Informatics and Natural Sciences
> Department of Informatics
> Group Technical Aspects of Multimodal Systems
>
> Vogt-Kölln-Straße 30
> D-22527 Hamburg
>
> Room: F-315
> Phone: +49 40 42883-2432
> Website: https://tams.informatik.uni-hamburg.de/people/goerner/

Re: [dev] [dwm] dwm breaks on synchronized screens

[v4hn]

Hey everyone,

I can verify issues with multi-monitor setups when screens are 
overlapping/mirrored.
I usually avoid this by working with independent screens as well.

With XINERAMA support in dwm you can dynamically configure monitors via xrandr.
If you configure them to coincide, e.g.,
`xrandr --output  --auto --same-as `,
it seems that at least for some configurations dwm creates separate `Monitor` 
structs
unconditionally and you can cycle through the monitors via shortcuts.
But because they overlap you will not even see the bar for one of the monitors
and window management is screwed up as well.
Notice that there is actually logic in the code that should prevent this
for the case where virtual screen positions coincide. (`isuniquegeom`)

Along the same lines of code I recently noticed that dynamically adding an
independent/unique screen via xrandr can change the Monitor->physical screen 
association
and thus move all existing windows to a different physical screen.
Maybe it's a different bug altogether though, I did not have time to 
investigate.


v4hn

On Fri, Nov 12, 2021 at 09:18:22AM +0100, Laslo Hunhold wrote:
> On Thu, 11 Nov 2021 19:34:08 +0100
> Thomas Oltmann  wrote:
> 
> Dear Thomas,
> 
> > What do I do about this?
> > Is it even a bug or just me using dwm for stuff it's not intended to
> > do? One way or another, how can I do my presentations without
> > fighting the WM all the time?
> 
> do you have a way so we can reproduce this?
> 
> With best regards
> 
> Laslo
> 

-- 
Michael 'v4hn' Görner, M.Sc. Cognitive Science, PhD Student
Universität Hamburg
Faculty of Mathematics, Informatics and Natural Sciences
Department of Informatics
Group Technical Aspects of Multimodal Systems

Vogt-Kölln-Straße 30
D-22527 Hamburg

Room: F-315
Phone: +49 40 42883-2432
Website: https://tams.informatik.uni-hamburg.de/people/goerner/


signature.asc
Description: PGP signature

Re: [dev] [dwm] dwm breaks on synchronized screens

[Laslo Hunhold]

On Thu, 11 Nov 2021 19:34:08 +0100
Thomas Oltmann  wrote:

Dear Thomas,

> What do I do about this?
> Is it even a bug or just me using dwm for stuff it's not intended to
> do? One way or another, how can I do my presentations without
> fighting the WM all the time?

do you have a way so we can reproduce this?

With best regards

Laslo

Re: [dev] [dwm] Possible bug in resizemouse function

[Hiltjo Posthuma]

On Sat, Oct 16, 2021 at 10:18:18PM +0800, Xu Lu wrote:
> The related code is in line 1326-1332 in dwm.c (current git HEAD):
> 
>   if (c->mon->wx + nw >= selmon->wx && c->mon->wx + nw <= selmon->wx + 
> selmon->ww
>   && c->mon->wy + nh >= selmon->wy && c->mon->wy + nh <= selmon->wy + 
> selmon->wh)
>   {
>   if (!c->isfloating && selmon->lt[selmon->sellt]->arrange
>   && (abs(nw - c->w) > snap || abs(nh - c->h) > snap))
>   togglefloating(NULL);
>   }
> 
> This outer if statement dates back to 13 years ago in [1]. The changes
> in movemouse in [1] got removed in [2]. The changes in resizemouse is
> neither perfect. Width and height are compared with coordinates, which
> is not a proper way. As a result, it does not work well, e.g., for
> multi-monitor setup.
> 
> 
> The expected behavior should be to constraint the resizing within the
> window area of the current monitor.
> 
> Now, in a multi-monitor set-up, start two windows in one monitor. Try
> resize the window in the stack. During resize, move the cursor directly
> into the other monitor to the right(suppose it is set up that way).
> This way, the window will be resized. But, if there was one window,
> the same action won't resize it.
> 
> 
> Possible solutions:
> 
> I am not a C developer, but I tried some changes and works for me (even
> works with patches like resizecorners):
> 
>   if (ev.xmotion.x >= selmon->wx && ev.xmotion.x <= selmon->wx + 
> selmon->ww
>   && ev.xmotion.y >= selmon->wy && ev.xmotion.y <= selmon->wy + 
> selmon->wh)
> 
> Or, with the help of 'INTERSECT' macro:
> 
>   if (INTERSECT(ev.xmotion.x, ev.xmotion.y, 1, 1, selmon) == 1)
> 
> The two are basically equivalent to each other. This tests whether the
> cursor is inside the monitor's window area, not sure if that's still
> the same intention as before.
> 
> Or, remove the outer if like in [2]. So the resizing is not constrained
> by the window area.
> 
> [1]: 
> https://git.suckless.org/dwm/commit/71365a524f67235024de7db277c63f8ac4f46569.html
> [2]: 
> https://git.suckless.org/dwm/commit/5b238c8dab945023b6a16a6c9f642b11137f2204.html
> 

Hi,

Thank you for the feedback. I've looked at it on a multi-monitor setup and also
discussed it on IRC with other people and the current behaviour seems expected.

Unless I misunderstand the issue I think it is not a bug.

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[Mateusz Okulus]

On 21/06/29 03:38PM, Hadrien Lacour wrote:
> The point of sxhkd isn't really itself, but having your daemon I/O completely
> available through IPC. This is a big advantage, as it allows the most
> power/freedom when interacting with it; especially through scripting.

But scripting what exactly? Can you give an example?

I guess you could write a script that automatically creates a detailed
setup for you, but compare that with dmw functionality - I'm fairly sure
the only options to change would be tag set, mfact, nmaster and layout.
All that can easily be configured at once by writing a simple function.
So the need for scripting in itself is an indication for overly,
unnecessarily complex setup.

In general I'd agree with modularity, but it always comes with some
overhead, and in this case with no additional benefit.

Regards,
mat


signature.asc
Description: PGP signature

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[qsmodo]

By definition, window managers manage windows. So, if I had not tried dwm yet,
I would guess that it would not take care of spawning windows.

> sxhkd complicates the setup with little additional benefit.

That's a fair point. Without noticing it I was assuming that other people
also relied on a key daemon to launch programs. Since I cannot back up
such a claim, I must, on second thought, agree with you. After all, in the
most simple of setups (no key daemon, no launcher such as dmenu), the spawn
function enables one to at least spawn a terminal emulator.

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[Kyryl Melekhin]

Splitting of code into separate programs in a lot of cases can create
more bloat. Unix philosophy is not the be all end all; you have to
weigh the benefits and drawbacks to see where it makes sense. In this
case using dwm for all your shortkeys is less bloat than using sxhkd
which does a lot more stuff like read config files, etc. Practicality
takes over some theoretical "definition".

Regards,
Kyryl

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[qsmodo]

I appreciate the discussion.

Jun 29, 2021, 07:04 by quinq@fifth.space:

> You are mistaken there, I don't think a software can take pride in
> something (here dwm), and the more closer community taking care of it
> (suckless) doesn't believe in "keeping its userbase small and elitist".
>
> On the contrary, I think most people there enjoy producing software
> that looks good to them, and it's always nice to see others finding
> in it some use for themselves too.
>
> What you may think about though, is that there is little interest in
> dealing with acting consumers who just ask for something they want,
> thinking the world revolves around their own centric view.
> Suckless isn't selling products, its writing softwares that are useful
> for somebody, and sharing them.
>
> Most people come with a good attitude whith the will to learn in order
> to make the modifications they want for themselves, and they find help
> in the community for starting up or when there's a blocking point.
> Sometimes the change they need is also a good improvement and will be
> included in the software, sometimes it's not and will not.
>
> Also, novices are welcome to ask questions, there are no stupid
> questions as long as there is a will to learn and a minimum effort in
> reading documentation pointed out by people and what is being explained
> when questions being answered.
>
> There's nothing elitist about this, the whole wiki is open to anybody
> who think they can push a sensible modification, trusting people to be
> responsible for what they do.
>
I'm glad that, as this one I'm responding to, all the other answers had a 
different — and similar — take on the elitism quote (I assume you all 
recognized it, but to err on the safe side, it's at 
).

However, worded at it is now, I think we will agree that for someone on the 
outside it will come out as proud or warding off, whereas something like "we 
have no interest in being very popular or trendy; our software will not be 
expanded to adapt to every user's possible particular taste" might be more to 
the point here raised and does look quite healthy.

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[Hadrien Lacour]

On Tue, Jun 29, 2021 at 01:48:51PM +0200, Mateusz Okulus wrote:
> sxhkd complicates the setup with little additional benefit.

The point of sxhkd isn't really itself, but having your daemon I/O completely
available through IPC. This is a big advantage, as it allows the most
power/freedom when interacting with it; especially through scripting.

And of course, it's very easy to replace something like sxhkd.

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[Sebastian LaVine]

On Tue Jun 29, 2021 at 10:46 AM EDT,  wrote:
> By definition, window managers manage windows. So, if I had not tried
> dwm yet,
> I would guess that it would not take care of spawning windows.

What world do you live in where the behavior of window managers is to
not take care of spawning windows? Off the top of my head, I cannot
think of one, except maybe bspwm (which I am not that familiar with),
which has an even smaller rounding error of users than dwm.

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[Mateusz Okulus]

On 21/06/29 01:16AM, qsm...@tutanota.com wrote:
> The existence of the spawn function in dwm surprises me. Wouldn't it
> be more consistent with Suckless' values (simplicity, minimalism,
> modularity) if the job of spawning commands were relegated to a hotkey
> daemon, such as xbindkeys or sxhkd?

I think you fell for the trap of thinking that more split programs means
that the whole setup is simpler. That's not always the case.

spawn is just simple wrapper of standard fork into execvp. You also get
SHCMD which is also very simple and avoids using
{ .v = { "cmd", (char *)NULL } all the time.

sxhkd complicates the setup with little additional benefit. The dwm
specific keybindings need to stay in config anyway. The only keybindings
you could move are the spawn one as you say. What do you get from moving
them to sxhkd? You have slightly simpler syntax (little benefit) and if
you switch wm you don't need to switch these keybindings, they work in
every x wm (again little benefit, why are you switching wms so often?)

I'm open to arguments why using sxhkd would make things simpler and
easier.

Regards,
mat


signature.asc
Description: PGP signature

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[Страхиња Радић]

On 21/06/29 02:04, qsm...@tutanota.com wrote:
> However, worded at it is now, I think we will agree that for someone on the
> outside it will come out as proud or warding off, whereas something like "we
> have no interest in being very popular or trendy; our software will not be
> expanded to adapt to every user's possible particular taste" might be more to
> the point here raised and does look quite healthy.

The sentence is precise and to the point. There's no need to change it to
cater to those who are *intrinsically* disinterested in:

- configuring programs by changing the source code 

- using command line programs, often several at a time, working together through
  pipes

- foregoing flashy UI libraries which just add eye candy and megabytes of
  pointless code

and by extension, those disinterested in using suckless programs. It is their
preference that sets them apart, and there's nothing wrong in that. Why force
them to use suckless software when they don't want to? Those who do want to use
it, understand and respect its philosophy will not be turned off.



signature.asc
Description: PGP signature

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[Quentin Rameau]

> […] but dwm takes pride in "keeping its userbase small and elitist, 
> withoutnovices asking stupid questions".

You are mistaken there, I don't think a software can take pride in
something (here dwm), and the more closer community taking care of it
(suckless) doesn't believe in "keeping its userbase small and elitist".

On the contrary, I think most people there enjoy producing software
that looks good to them, and it's always nice to see others finding
in it some use for themselves too.

What you may think about though, is that there is little interest in
dealing with acting consumers who just ask for something they want,
thinking the world revolves around their own centric view.
Suckless isn't selling products, its writing softwares that are useful
for somebody, and sharing them.

Most people come with a good attitude whith the will to learn in order
to make the modifications they want for themselves, and they find help
in the community for starting up or when there's a blocking point.
Sometimes the change they need is also a good improvement and will be
included in the software, sometimes it's not and will not.

Also, novices are welcome to ask questions, there are no stupid
questions as long as there is a will to learn and a minimum effort in
reading documentation pointed out by people and what is being explained
when questions being answered.

There's nothing elitist about this, the whole wiki is open to anybody
who think they can push a sensible modification, trusting people to be
responsible for what they do.

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[lincoln auster]

Hi,

> The existence of the spawn function in dwm surprises me. Wouldn't it be
> more consistent with Suckless' values (simplicity, minimalism,
> modularity) if the job of spawning commands were relegated to a hotkey
> daemon, such as xbindkeys or sxhkd?

The way it is now, the job of handling keypresses is done solely within dwm:
remember, dwm also captures and handles keychords wrt window management. I think
using that pre-existing infrastructure to also spawn commands is a smaller
solution, as it's just one less program (a dedicated keychord daemon that you
don't need) and 9/10/whatever SLOC.

One could, of course, go the bspwm/berry/etc route and have window management
occur via IPC, and then have a more capable keychord daemon deal with
everything. I think there's an argument to be made for that approach, but on the
whole I think the simple nature of dwm's keychord listening discourages any
setup that's too complex, which I personally like.

> ... dwm takes pride in "keeping its userbase small
> and elitist, without novices asking stupid questions".

And as a side note: stupid questions are important. Being elitist is just
irritating. I'm a novice, I ask stupid questions, and simple source code
happily answers them. I don't think we should actively let "being elitist"
influence design: we should allow and encourage an understanding of software
through simple and open design.

Thanks,

Lincoln Auster
They/Them

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[Страхиња Радић]

On 21/06/29 10:03, Martin Tournoij wrote:
> > It is true that some people could be driven away after being greeted 
> > with a black screen without any preconfigured keybinding to open a 
> > terminal or dmenu, but dwm takes pride in "keeping its userbase small 
> > and elitist, withoutnovices asking stupid questions".
> 
> That has never been part of the appeal for me. Suckless are tools for
> *advanced* users, yes, and elides most "hand-holding" which makes it
> better for folks like us. By extension this means it's somewhat
> "elitist", but I've never considered that a a goal in and of itself.

I'd just add that (true, intrinsic) elitism, in relation to autonomy in learning
and exploring software, or even coming up with solutions to problems on one's
own, is not a bad thing. Not everything needs to cater to the ignorant masses.
No corporate edge needs to be gained by having a larger userbase.  By catering
to the masses, software inevitably goes against the suckless principles, adding
unnecessary features and dependencies.



signature.asc
Description: PGP signature

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

[Martin Tournoij]

On Tue, Jun 29, 2021, at 07:16, qsm...@tutanota.com wrote:
> The existence of the spawn function in dwm surprises me. Wouldn't it be 
> more consistent with Suckless' values (simplicity, minimalism, 
> modularity) if the job of spawning commands were relegated to a hotkey 
> daemon, such as xbindkeys or sxhkd?

My own take is that it's all about benefit vs. cost. The spawn()
function is currently 11 lines and completely stand-alone (i.e. it
doesn't hook in to any other logic). The cost and complexity is very
low, and the benefit is very high.

If you want to take suckless to the extreme then much of dwm could be
removed. Why implement tiling or shortcuts to move windows in dwm? You
can arrange windows with an external program after all. I actually did
this back when I tried cwm for a bit as it lacked some stuff I
missed.[1] It was fun to play around, but I don't think it was any less
complex than having these things in dwm.

Related thing I wrote some time ago:
https://www.arp242.net/stupid-light.html

And I talk a little bit about suckless specifically in a follow-up comment:
https://lobste.rs/s/95hsvw/stupid_light_software#c_cixacv


> It is true that some people could be driven away after being greeted 
> with a black screen without any preconfigured keybinding to open a 
> terminal or dmenu, but dwm takes pride in "keeping its userbase small 
> and elitist, withoutnovices asking stupid questions".

That has never been part of the appeal for me. Suckless are tools for
*advanced* users, yes, and elides most "hand-holding" which makes it
better for folks like us. By extension this means it's somewhat
"elitist", but I've never considered that a a goal in and of itself.

[1]:
  
https://github.com/arp242/dotfiles/blob/7cc513b935a84289afbdde39e0ee04bf80c97234/local-bin/local/bin/cwm-w-tile
  
https://github.com/arp242/dotfiles/blob/7cc513b935a84289afbdde39e0ee04bf80c97234/local-bin/local/bin/cwm-w-mv
  
https://github.com/arp242/dotfiles/blob/7cc513b935a84289afbdde39e0ee04bf80c97234/local-bin/local/bin/cwm-w-place

Re: [dev] [dwm] Hide window content when moving/resizing windows

[Страхиња Радић]

On 21/02/10 08:09, Κράκ Άουτ wrote:
> resources. So if the if-block is removed you get the opposite of 0/sec.
> 
The if block includes not only the condition "if (/*...*/)", but also
the line or a block of code following it, whose execution is controlled by the
condition.



signature.asc
Description: PGP signature

Re: [dev] [dwm] Hide window content when moving/resizing windows

[Κράκ Άουτ]

Στις 10/2/21 4:46 μ.μ., ο/η Страхиња Радић έγραψε:

On 21/02/10 01:10, Κράκ Άουτ wrote:

So, looking at your code, can I limit updates to 1/sec instead of
60/sec? Changing this line,
`if ((ev.xmotion.time - lasttime) <= (1000 / 60))`
to
`if ((ev.xmotion.time - lasttime) <= (1000 / 1))`
would be enough?

Can I also achieve 0/sec somehow? I suggested 1/sec because division by
zero is not possible.


I'm not familiar with the context of the quoted code, but it looks like
if checks for the time difference between the current time and last recorded
time. The check succeeds if the difference is 1000/60 ~ 17 in the first case and
1000 in the second case. As the divisor gets closer to zero, the threshold
against which the difference is tested becomes greater. As you said, division by
zero is not possible. The division is there in the first place purely for the
sake of code clarity, the difference is an integer constant and can be specified
as just a single number, without the division.

From the purely logical standpoint, "achieving 0/sec" would be
equivalent to not executing the code in the if-block at all, and would be best
accomplished by commenting the block out.



Hello Страхиња,

You are obviously right regarding 1000/60. But if I understood well,
Hiltjo's commit induced a limit; if it's removed, then dwm will try to
update the fastest possible, faster than 60/sec, taking up more
resources. So if the if-block is removed you get the opposite of 0/sec.

Re: [dev] [dwm] Hide window content when moving/resizing windows

[Страхиња Радић]

On 21/02/10 03:46, Страхиња Радић wrote:
> time. The check succeeds if the difference is 1000/60 ~ 17 in the first case 
> and
> 1000 in the second case. As the divisor gets closer to zero, the threshold

*is lesser than or equal to



signature.asc
Description: PGP signature

Re: [dev] [dwm] Hide window content when moving/resizing windows

[Страхиња Радић]

On 21/02/10 01:10, Κράκ Άουτ wrote:
> So, looking at your code, can I limit updates to 1/sec instead of
> 60/sec? Changing this line,
> `if ((ev.xmotion.time - lasttime) <= (1000 / 60))`
> to
> `if ((ev.xmotion.time - lasttime) <= (1000 / 1))`
> would be enough?
> 
> Can I also achieve 0/sec somehow? I suggested 1/sec because division by
> zero is not possible.

I'm not familiar with the context of the quoted code, but it looks like
if checks for the time difference between the current time and last recorded
time. The check succeeds if the difference is 1000/60 ~ 17 in the first case and
1000 in the second case. As the divisor gets closer to zero, the threshold
against which the difference is tested becomes greater. As you said, division by
zero is not possible. The division is there in the first place purely for the
sake of code clarity, the difference is an integer constant and can be specified
as just a single number, without the division. 

From the purely logical standpoint, "achieving 0/sec" would be
equivalent to not executing the code in the if-block at all, and would be best
accomplished by commenting the block out.


signature.asc
Description: PGP signature