Open source writes:
Some people like me find it beautiful, simple, and comfortable eye,
It's a personal preference at the end of the day, it's just a simple
patch for those who want it.
This mailing list is for mainline patch submissions and discussion, please
submit other things to the
Hiltjo Posthuma writes:
I don't think there can be any zombies since it is run in setup() before any
processes can spawn (via keybindings etc) or am I overlooking something
obvious?
You can have zombies from what's spawned in .xinitrc or similar, because
usually the final step is `exec dwm'.
Hiltjo Posthuma writes:
- sigchld(0);
+ if (signal(SIGCHLD, SIG_IGN) == SIG_ERR)
+ die("can't ignore SIGCHLD:");
I didn't test it yet, so maybe I'm misremembering/misreading the patch, but I
don't think this will work: SIG_IGN will ignore new children, but it won't
Thanks NRK for bringing this one up again :-)
NRK writes:
If there's any specific issue with Chris' patch which is blocking the
merge then I'd be happy to address them.
Likewise -- happy to act on any feedback.
I've been running this for the last half a year or so and haven't noticed any
It's not uncommon for one keysym to map to multiple keycodes. For
example, the "play" button on my keyboard sends keycode 172, but my
bluetooth headphones send keycode 208, both of which map back to
XF86AudioPlay:
% xmodmap -pke | grep XF86AudioPlay
keycode 172 = XF86AudioPlay
Hiltjo Posthuma writes:
Thanks for the patch, I will probably look at it further this weekend.
Thanks for looking! :-)
Should syms be checked before XFree(syms) or can the return value not be NULL?
I was going to say that it's not possible even with a race with a new mapping,
since
It's not uncommon for one keysym to map to multiple keycodes. For
example, the "play" button on my keyboard sends keycode 172, but my
bluetooth headphones send keycode 208, both of which map back to
XF86AudioPlay:
% xmodmap -pke | grep XF86AudioPlay
keycode 172 = XF86AudioPlay
Hey Hiltjo,
Chris Down writes:
signal() semantics are pretty unclearly specified. For example,
depending on OS kernel and libc, the handler may be returned to SIG_DFL
(hence the inner call to readd the signal handler). Moving to
sigaction() means the behaviour is consistently defined.
Using
Quentin Rameau writes:
I beg to differ when the code declares something const but later then decides
>The constness is “maintained” here, the function gets a "const FcChar8 *"
That's quite different: the code passes it a FcChar8* which it then treats as a
const FcChar8*. Case in point, GCC
Quentin Rameau writes:
Hi Quentin,
Hey Cris,
In general the existing code seems confused, no?
A code isn't confused, the reader might be though.
I beg to differ when the code declares something const but later then decides
it isn't ;-)
Is there something you are not actually
Hi Quentin,
Quentin Rameau writes:
Those don't “cast away constantness”, they are just cast.
Hmm? For example, for the FC/Xft types, fontname is declared as const by
xfont_create, but then we cast away its constness when passing it to
FCNameParse. The same goes for text, which we claim is
The Arg union is generally passed to functions called from a Key or
Button. One of its members, "v", allows passing a `const void *` with
the receiving function determining the intent and casting as
appropriate.
There are a few places in the dwm code where we cast away the constness
of this
.
These changes primarily avoid casting away const unnecessarily. They
also make sure that we don't accidentally introduce non-const behaviour
in future, and potentially UB.
>From my side I've been using these patches for years, and they work
well.
Chris Down (2):
drw: Maintain const-correctn
We retrieve these from their respective functions arguments as const,
and can trivially respect that.
---
drw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drw.c b/drw.c
index ced7d37..b9fa818 100644
--- a/drw.c
+++ b/drw.c
@@ -119,7 +119,7 @@ xfont_create(Drw *drw,
NRK writes:
ping!
In case this got lost in the noise :)
Thanks for the poke :-)
From my side, I've been running with this patch for a couple of weeks and
everything works fine, so I think it's good to go.
Chris Down writes:
sigprocmask() only returns an error if you pass an invalid first
argument, but we're using SIG_SETMASK as part of the userspace ABI
contract, so that doesn't seem very relevant.
(One could make the same argument about sigaction(), of course -- that's mostly
just an EINTR
NRK writes:
If I understand the manpage correctly, then this patch looks mostly
okay. Only issue I can think of is that both `sigfillset` and
`sigprocmask` manpage states that they may return -1 on errors. So
perhaps they should be error checked just in case:
if (sigfillset() < 0 ||
signal() semantics are pretty unclearly specified. For example,
depending on OS kernel and libc, the handler may be returned to SIG_DFL
(hence the inner call to readd the signal handler). Moving to
sigaction() means the behaviour is consistently defined.
Using SA_NOCLDWAIT also allows us to avoid
NRK writes:
It sets up the sighandler and then immediately calls `sigchld`. So it
seems like the intention was to *actaully* reap some zombies and not
just setup the sighandler.
Ah, I see. This[0] is the thread that it comes from, and it mentions zombies
from .Xsession or similar on exec. I
signal() semantics are pretty unclearly specified. For example,
depending on OS kernel and libc, the handler may be returned to SIG_DFL
(hence the inner call to readd the signal handler). Moving to
sigaction() means the behaviour is consistently defined.
Using SA_NOCLDWAIT also allows us to avoid
NRK writes:
On Tue, Jul 26, 2022 at 09:45:08PM +0100, Chris Down wrote:
Can there really be zombies before setup()? At that point we haven't even
started in earnest yet, I don't see how a child would even get going.
I'm not sure myself. But that's what the old comment was suggesting
NRK writes:
On Tue, Jul 26, 2022 at 09:15:30PM +0100, Chris Down wrote:
- /* clean up any zombies immediately */
- sigchld(0);
+ if (sigaction(SIGCHLD, , NULL)) {
+ perror("sigaction");
+ exit(EXIT_FAILURE);
+ }
Not too w
Thanks! Sorry for the trouble :-)
Commit 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size
hints") mistakenly removed an early size hints update that's needed to
populate c->isfixed for floating checks at manage() time. This resulted
in fixed (size hint min dimensions == max dimensions) subset of windows
not
Pruitt
© 2016-2017 Markus Teich
+© 2020-2022 Chris Down
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
--
2.35.2
Hey Hiltjo,
Any thoughts on this one? I figure it understandably might have fallen off your
radar with all the new patches and patch discussion coming your way recently
:-)
From my side, I've been using dwm on an embedded device for the last few weeks
and this patch has increased
Hi Miles,
Miles Alan writes:
Interesting - thanks for reporting. I'd be curious what WM_TRANSIENT_FOR
is set to in pinentry's case. The case I'm trying to address is resizable
SDL applications which, as mentioned earlier, wholesale set WM_TRANSIENT_FOR
to the root window. I'm not sure on the
Hey folks,
This patch causes a regression for GPG's default pinentry. Previously the
window floats as it is supposed to, but now it doesn't float at all.
To reproduce, you can clear your agent credentials with `gpg-connect-agent <<<
RELOADAGENT`, and then request decryption. Attached are
This patch defers all size hint calculations until they are actually
needed, drastically reducing the number of calls to updatesizehints(),
which can be expensive when called repeatedly (as it currently is during
resizes).
In my unscientific testing this reduces calls to updatesizehints() by
over
I noticed that a non-trivial amount of dwm's work on my machine was from
drw_text, which seemed weird, because I have the bar disabled and we
only use drw_text as part of bar drawing.
Looking more closely, I realised that while we use m->showbar when
updating the monitor bar margins, but don't
Hey folks,
Laslo Hunhold writes:
count me in in that regard. If an application (most likely a game) wants
exclusive fullscreen, it can capture the mouse in the window. I always
set it like this in wine and have had no problems with that, and it
still allows workspace-switching.
For what it's
Hiltjo Posthuma writes:
Thanks for the patch! I think it makes sense and pushed the patch to master.
Thanks! :-)
Hey Hiltjo,
Any opinion on this one? Just going over my patches and remembered I was
waiting on a reply to this from upstream.
Thanks :-)
Chris
Hi Vinícius,
The error message from patch is quite clear that it failed to apply, so
compilation is premature. You need to either massage it in, or find a patch
which roughly matches your version.
Hiltjo Posthuma writes:
Hiltjo, any objections?
I have no objections (your Honour) and released dmenu 5.0.
Wonderful, thank you! Have a great rest of your week. :-)
Chris
Hey folks,
Unlike a lot of the rest of our software, generally dmenu works pretty well
even as a distribution-provided binary package, since usually users only want
to change colours, fonts, and other stuff that can be set on the command line.
For that reason, it seems maybe sensible to
It generally doesn't make much sense to allow focusstack() to navigate
away from the selected fullscreen client, as you can't even see which
client you're selecting behind it.
I have had this up for a while on the wiki as a separate patch[0], but
it seems reasonable to avoid this behaviour in dwm
Chris Down writes:
and maybe fgets can simply be rewritten using getline() at:
http://git.suckless.org/sent/file/sent.c.html#l417
Hmm, unless I'm missing something, getline() actually would hinder
here since we need to use separate heap storage for each line, but
getline() optimises
If we read in a line with \0 at the beginning, blen will be 0. However,
we then try to index our copy of the buffer with
s->lines[s->linecount][blen-1], we'll read (and potentially write if the
data happens to be 0x0A) outside of strdup's allocated memory, and may
crash.
Fix this by just
Hiltjo Posthuma writes:
Looks good to me, minor nitpick, maybe the style can be:
if (buf[0] == '\0')
Sure, either style is fine with me. I'll send v2 now. :-)
and maybe fgets can simply be rewritten using getline() at:
http://git.suckless.org/sent/file/sent.c.html#l417
If we read in a line with \0 at the beginning, blen will be 0. However,
we then try to index our copy of the buffer with
s->lines[s->linecount][blen-1], we'll read (and potentially write if the
data happens to be 0x0A) outside of strdup's allocated memory, and may
crash.
Fix this by just
We retrieve these from their respective functions arguments as const,
and can trivially respect that.
---
drw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drw.c b/drw.c
index 8fd1ca4..08f7a4a 100644
--- a/drw.c
+++ b/drw.c
@@ -118,7 +118,7 @@ xfont_create(Drw *drw,
This jarred me a bit while reading the code, since "sw" usually refers
to the global screen geometry, but in drawbar() only it refers to
text-related geometry. Renaming it makes it more obvious that these are
not related.
---
dwm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
No functional changes, but for every other function we have a forward
declaration here. getatomprop should be no exception.
---
dwm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/dwm.c b/dwm.c
index 41c6767..972f261 100644
--- a/dwm.c
+++ b/dwm.c
@@ -169,6 +169,7 @@ static void
The Arg union is generally passed to functions called from a Key or
Button. One of its members, "v", allows passing a `const void *` with
the receiving function determining the intent and casting as
appropriate.
There are a few places in the dwm code where we cast away the constness
of this
There are two places that mfact can be set:
- In the mfact global, which is defined at compile time and passed
into m->mfact during monitor setup. No bounds checks are performed,
but the comment alongside it says that valid values are [0.05..0.95]:
static const float mfact = 0.55; /*
Hey Stephen,
Stephen Gregoratto writes:
This expresses the same information in much simpler syntax, along with a
hefty line reduction. Tested using groff 1.22.3 & OpenBSD mandoc 1.14.4.
Also replaced the sed command with cp in the Makefile, as mdoc pages
are versioned by date.
Could you go
Since now both would be stored in the git history, this would actually increase
the size of the repo, so I'm not sure I see the benefit of this.
XkbKeycodeToKeysym is fundamentally broken, I'm afraid. We've been through this
before, take a look at https://lists.suckless.org/dev/1205/11661.html.
Unless XkbKeycodeToKeysym actually works comparably now, deprecated is better
than broken.
signature.asc
Description: PGP signature
49 matches
Mail list logo
