Re: [dev] [dwm] hardcoded dmenucmd && dmenumon
> 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
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