On Mon, Oct 29, 2018 at 11:10 PM ovk <[email protected]> wrote:

> @nuko8 <https://github.com/nuko8>, I'm not sure I fully understand your
> argument.
> Window border is something window manager should be dealing with, not the
> application itself.
>
No.  It's an attribute of windows (as X resource).  See XCreateWindow(1)
and XCreateSimpleWindow(1).

> If user decides to have no borders on a display incapable of colors - it
> is his/her choice, and applications shouldn't make any assumptions there.
>
Seems like you are confusing the border width of each window with the one
added to application's largest window by the window manager.

> Otherwise it will be a mess: Vim decides to have border of 2px, some other
> application decides to make its border 3px etc.
>
Hmm, but it's you who is claiming that border widths should be configurable
so that they can have a value other than 2px.  What's wrong with 2px which
has been widely used by terminal emulators?  Sounds like you are saying
your proposal will cause a mess.

> Even if there's a legitimate use case where having inner border could
> improve user experience on certain combinations of displays and WM, how
> common is this case?
> I'd guess - not common at all. So why is the choice was made towards
> marginally improving UX in an uncommon case, while disrupting UI layout and
> breaking consistency for common cases?
>
Because "applications shouldn't make any assumptions there."  Talking about
"common" case is just making an assumption, isn't that?

> Just for comparison, below is a screenshot from Windows gVim:
>
> [image: vimw]
> <https://user-images.githubusercontent.com/693072/47655003-715d0680-db62-11e8-9587-95fc7b7e824c.png>
>
> As you can see, the content fully occupies window and fits nicely without
> any unexpected padding and without wasting any pixels.
>
I already said, "I don't know about Windows."  I should have said that more
clearly: I don't want to comment on what others are doing and want to
follow the well-tested 2px tradition in order to avoid time-consuming,
unproductive re-verification.

> Ultimately, having inner border or not (as well as what width it should
> be) is a user's choice, that may depend on personal preference, window
> manager, display DPI etc.
> Which is why I suggest that it should be configurable in gVim.
>
Once everything being configurable was considered a good thing.  Later,
that was found a factor which made users confused and the resulting bloat
code could be an obstacle to implement new features.  Now, users'
productivity is more emphasized than configurability.

> But if making it configurable is too difficult to implement, then I
> strongly believe that choice should be made towards consistency and most
> common use case, i.e. no forced padding that disrupts layout.
>
Actually, writing a patch for that is entry level. But let me emphasize
this again: Avoid making any assumption in the name of what is considered
common use cases.

> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/vim/vim/issues/3575#issuecomment-433923653>
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui