On Mon, 12 Sep 2016 13:13:39 +0200
Quentin Rameau <quinq_AT_fifth.space> wrote:
Hey Quentin,
> That was just one example of the rest of the complexity it brings in
> here.
it just stops hiding the fact that readpw() does many things at once.
It would make sense to split this function apart a bit, maybe separating
the hash-checking from the actual X stuff. Having global state skews
your vision and the biggest sin is having functions which do too many
things at once.
> > because it would be inconsistent with the xrandr-struct.
> It would be inconsistent with… An inconsistency you're bringing in? ^^
what other choice do I have? I could of course typedef the xrandr-struct
typedef struct _xrandr {
...
} Xrandr;
but this would be confusing as hell, given people could almost start
believing this struct was part of X.
> As I said, personal taste.
We had the discussion already. Markus decides in the end.
> Not *that* reasoning, as I already said, I already told you I was for
> getting rid of it.
> I mean the reasoning of why it was introduced in the first place, to
> be sure something is not missed here.
It was added in commit 0f1157d[0] and carried through history since
then. I bet back then it was laziness not wanting to run getpwuid to
get the pw_name entry. There is no reasoning and we should definitely
move away from the $USER environment variable, especially because it
makes slock's behaviour inconsistent across operating systems (in some
cases it is sensitive to $USER, in others it is not).
> Get rid of it.
I'll send in a small patch when I have the time.
Cheers
FRIGN
[0]:
http://git.suckless.org/slock/commit/slock.c?id=0f1157d7e6cabe0394ffc35a0a58a30507af8ebd
--
FRIGN <dev_AT_frign.de>
Received on Mon Sep 12 2016 - 13:52:38 CEST