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

2022-02-17 Thread 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

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

2022-02-17 Thread 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,

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

2022-02-17 Thread Страхиња Радић
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

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

2022-02-16 Thread 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

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

2022-02-16 Thread 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) >