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