Re: [hackers] [dmenu] inputw: improve correctness and startup performance, by NRK || Hiltjo Posthuma
How about an arbitrary default size of something like MIN(TEXTW("W") * 30,
mw / 3)?
On Sat, 30 Apr 2022, 13:46 NRK, wrote:
> On Sat, Apr 30, 2022 at 01:28:49PM +0200, Hiltjo Posthuma wrote:
> > Whats your monitor resolution width?
>
> I'm currently using 1366x768. Don't think it's worth optimizing for that
> resolution as most people use 1080p nowadays.
>
> > Whats your suggestion to improve it in a general sense?
> >
> > The trade-off is now that for small input strings in horizontal mode it
> might
> > wastes some visual space now, but like you said it is now consistently
> in the
> > same place and also simpler.
>
> There's no right or wrong answer here, since it'll basically come down
> to personal preference.
>
> I'd say making it a config.h option (and maybe adjustable via cli as
> well) would be a good course of action. It lets people easily change it
> if they don't like the default.
>
> - NRK
>
>
Re: [hackers] [dmenu] inputw: improve correctness and startup performance, by NRK || Hiltjo Posthuma
On Sat, Apr 30, 2022 at 01:28:49PM +0200, Hiltjo Posthuma wrote: > Whats your monitor resolution width? I'm currently using 1366x768. Don't think it's worth optimizing for that resolution as most people use 1080p nowadays. > Whats your suggestion to improve it in a general sense? > > The trade-off is now that for small input strings in horizontal mode it might > wastes some visual space now, but like you said it is now consistently in the > same place and also simpler. There's no right or wrong answer here, since it'll basically come down to personal preference. I'd say making it a config.h option (and maybe adjustable via cli as well) would be a good course of action. It lets people easily change it if they don't like the default. - NRK
Re: [hackers] [dmenu] inputw: improve correctness and startup performance, by NRK || Hiltjo Posthuma
On Sat, Apr 30, 2022 at 11:15:38AM +0200, Hiltjo Posthuma wrote: > The previous maximum width also used about 30% of the monitor width. Should've clarified, I didn't quite like the previous max either. But that wouldn't get triggered before on small input strings. But since the width is static now, I didn't want it taking up 33% all the time. - NRK
Re: [hackers] [dmenu] inputw: improve correctness and startup performance, by NRK || Hiltjo Posthuma
On Sat, Apr 30, 2022 at 10:45:09AM +0600, NRK wrote:
> On Fri, Apr 29, 2022 at 08:19:20PM +0200, g...@suckless.org wrote:
> > commit e1e1de7b3b8399cba90ddca9613f837b2dbef7b9
> > Author: Hiltjo Posthuma
> > AuthorDate: Fri Apr 29 20:15:48 2022 +0200
> > Commit: Hiltjo Posthuma
> > CommitDate: Fri Apr 29 20:18:02 2022 +0200
> >
> > inputw: improve correctness and startup performance, by NRK
> >
> > Always use ~30% of the monitor width for the input in horizontal mode.
> >
> > Patch adapted from NRK patches.
> > This also does not calculate inputw when using vertical mode anymore
> > (because
> > the code is removed).
> >
> > diff --git a/dmenu.c b/dmenu.c
> > index 839f6cc..4e286cf 100644
> > --- a/dmenu.c
> > +++ b/dmenu.c
> > @@ -610,13 +610,12 @@ static void
> > setup(void)
> > {
> > int x, y, i, j;
> > - unsigned int du, tmp;
> > + unsigned int du;
> > XSetWindowAttributes swa;
> > XIM xim;
> > Window w, dw, *dws;
> > XWindowAttributes wa;
> > XClassHint ch = {"dmenu", "dmenu"};
> > - struct item *item;
> > #ifdef XINERAMA
> > XineramaScreenInfo *info;
> > Window pw;
> > @@ -674,12 +673,7 @@ setup(void)
> > mw = wa.width;
> > }
> > promptw = (prompt && *prompt) ? TEXTW(prompt) - lrpad / 4 : 0;
> > - for (item = items; item && item->text; ++item) {
> > - if ((tmp = textw_clamp(item->text, mw/3)) > inputw) {
> > - if ((inputw = tmp) == mw/3)
> > - break;
> > - }
> > - }
> > + inputw = mw / 3; /* input width: ~30% of monitor width */
> > match();
> >
> > /* create menu window */
> >
>
> Hi Hiltjo,
>
> Thanks for getting on this quickly.
>
> I prefered the static bar width as it gives a predictable UI, the first
> option will always appear in the same place rather than jumping around
> depending on the input strings. And the fact that there was no way to
> calculate the width correctly without taking unreasonable performance
> hit anyways.
>
> Though I must admit I'm having some second thoughts about it now. Given
> that not taking fallback fonts "worked fine" (haven't seen anyone
> complain) for about 6 years, maybe that wasn't too bad of an option.
>
> But in any case, I'm fine with the current patch too, though I've
> changed it to 1/4th of the monitor width rather than 1/3rd as I found
> that too wide for my liking.
>
> - NRK
>
Hi NRK,
What monitor resolution width do you have? I use 1920x1080 on this machine.
The previous maximum width also used about 30% of the monitor width.
--
Kind regards,
Hiltjo
Re: [hackers] [dmenu] inputw: improve correctness and startup performance, by NRK || Hiltjo Posthuma
On Fri, Apr 29, 2022 at 08:19:20PM +0200, g...@suckless.org wrote:
> commit e1e1de7b3b8399cba90ddca9613f837b2dbef7b9
> Author: Hiltjo Posthuma
> AuthorDate: Fri Apr 29 20:15:48 2022 +0200
> Commit: Hiltjo Posthuma
> CommitDate: Fri Apr 29 20:18:02 2022 +0200
>
> inputw: improve correctness and startup performance, by NRK
>
> Always use ~30% of the monitor width for the input in horizontal mode.
>
> Patch adapted from NRK patches.
> This also does not calculate inputw when using vertical mode anymore
> (because
> the code is removed).
>
> diff --git a/dmenu.c b/dmenu.c
> index 839f6cc..4e286cf 100644
> --- a/dmenu.c
> +++ b/dmenu.c
> @@ -610,13 +610,12 @@ static void
> setup(void)
> {
> int x, y, i, j;
> - unsigned int du, tmp;
> + unsigned int du;
> XSetWindowAttributes swa;
> XIM xim;
> Window w, dw, *dws;
> XWindowAttributes wa;
> XClassHint ch = {"dmenu", "dmenu"};
> - struct item *item;
> #ifdef XINERAMA
> XineramaScreenInfo *info;
> Window pw;
> @@ -674,12 +673,7 @@ setup(void)
> mw = wa.width;
> }
> promptw = (prompt && *prompt) ? TEXTW(prompt) - lrpad / 4 : 0;
> - for (item = items; item && item->text; ++item) {
> - if ((tmp = textw_clamp(item->text, mw/3)) > inputw) {
> - if ((inputw = tmp) == mw/3)
> - break;
> - }
> - }
> + inputw = mw / 3; /* input width: ~30% of monitor width */
> match();
>
> /* create menu window */
>
Hi Hiltjo,
Thanks for getting on this quickly.
I prefered the static bar width as it gives a predictable UI, the first
option will always appear in the same place rather than jumping around
depending on the input strings. And the fact that there was no way to
calculate the width correctly without taking unreasonable performance
hit anyways.
Though I must admit I'm having some second thoughts about it now. Given
that not taking fallback fonts "worked fine" (haven't seen anyone
complain) for about 6 years, maybe that wasn't too bad of an option.
But in any case, I'm fine with the current patch too, though I've
changed it to 1/4th of the monitor width rather than 1/3rd as I found
that too wide for my liking.
- NRK
