Hard-coded 2 pixel border in GTK gVim

[ovk]

The current GTK gVim has hard-coded 2 pixel border around main window content:

The border value is hard-coded here.

Settings gui.border_width to 0

gui.border_width = 0;

and rebuilding gVim completely eliminates the unnecessary border.

Ideally the border width value should be configurable, but at very least it should be set to 0 (like in Windows version of gVim, for example).

[nuko8]

Ideally the border width value should be configurable, but at very least it should be set to 0 (like in Windows version of gVim, for example).

(With the understanding that I don't know about Windows at all) Adding a small number of pixels to borders has been done customarily in GUI for UNIX-like systems for a long time to make the border visible or noticeable even if the given physical display is incapable in color. I don't think setting gui.border_width to 0 is a decent UI design, considering such an important role border widths have long played..

[ovk]

@nuko8, I'm not sure I fully understand your argument.
Window border is something window manager should be dealing with, not the application itself.
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.
Otherwise it will be a mess: Vim decides to have border of 2px, some other application decides to make its border 3px etc.

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?

Just for comparison, below is a screenshot from Windows gVim:

As you can see, the content fully occupies window and fits nicely without any unexpected padding and without wasting any pixels.

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.
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.

[tonymec]

In my maximized gvim (on a 1280x1024px 16777216-color display, minus the window manager's toolbars at top, right and bottom edges) I hardly notice the 2px margin, I have to look very closely to see it. Could be because 2px on this monitor seems to be something like 0.5 mm (by eyeball estimate, no ruler). YMMV of course.

But the fact that it is there when I look for it tells me that gvim is not overshooting the monitor edges. 😛

Best regards,
Tony.

[vim-ml]

On Mon, Oct 29, 2018 at 11:10 PM ovk ***@***.***> 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 <#3575 (comment)> -- -- 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 ***@***.*** For more options, visit https://groups.google.com/d/optout.

[ovk]

No. It's an attribute of windows (as X resource). See XCreateWindow(1) and XCreateSimpleWindow(1).

Seems like you are confusing the border width of each window with the one added to application's largest window by the window manager.

What I mean is that if user wants to have border/gaps - he can do so by relying on WM.
However, in the current situation if the user doesn't want any padding, he can only get rid of it by patching and recompiling gVim.

What's wrong with 2px which has been widely used by terminal emulators?

It's a magic number that adds non-removable visually distracting padding that is inconsistent across different gVim versions.
Why 2px, why not 5 or maybe 42? I feel like this "one size fits all" approach contradicts Vim's incredible customizability.

Sounds like you are saying your proposal will cause a mess.

No. I am saying that if every application developer will decide to go with with arbitrary chosen hard-coded paddings - then it will be a mess.
You can still have 2px as a default (to avoid disruptive upgrade), but having it configurable will give users freedom in having consistent look and feel.

Talking about "common" case is just making an assumption, isn't that?

Well I mentioned that this is my guess, but it is based on the current Linux distro usage statistics.
Besides, hard-coding padding is actually making a very opinionated assumption.

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

Fair enough. I just hope that other Vim developers (assuming you one of them) are more interested in gVim providing consistent UX between platforms.

Now, users' productivity is more emphasized than configurability.

You are generalizing users. The padding actually decreases my productivity because it is visually distracting (especially when switching between platforms).
It also makes gVim window to stand out of other apps (that I use) as none of them have similar paddings.

[k-takata]

Windows version had also 2px borders. However they were removed by 7.4.930, because it didn't fit the recent Windows design.

[tonymec]

AFAICT the similar 'guiheadroom' option does nothing, even if set on the command-line by gvim --cmd 'set ghr=0' or similar. What about a new 'guisideroom' option defaulting to 2 on Linux and to 0 on Windows for backward compatibility?

[nuko8]

To be sure, @tonymec s proposal resolves this particular issue concerning the claimed "inconsistency," but is there anyone who can address another possible inconsistency due to that? : Vim on xterm has the 2px-width border, which can be seen even with that on terminals for macOS, Terminal.app and iTerm2, while that hypothetical Gvim with the proposed guisideroom option can have the 0px-width border.

Personally, I think any UI should follow a UI guideline written specifically for a specific platform or environment, if any, or, well-established, local conventions when such a guideline is unavailable or tells nothing about UI design issues at hand, so that the resulting UI design will give no surprise to people.

Therefore, it's okay for me that Windows Gvim has no border around the text area if that fits recent Windows design. Why should we, however, import that design into UNIX-like systems at the cost of inconsistency the consistency between Vim and Gvim on a single platform?

UPDATED: Corrected a word.

[brammool]

The 2 pixels space is needed to avoid that the text runs into the window border. I don't think that adding yet-another-option for this is really useful, considering that most users are happy with how it is now.

[ovk]

Why should we, however, import that design into UNIX-like systems at the cost of the consistency between Vim and Gvim on a single platform?

Well, as per @tonymec suggestion there won't be any inconsistency unless user explicitly configures 'guisideroom' in a way that is inconsistent with user's terminal of choice.

Besides, while xterm does have 2px padding by default (which, by the way, is configurable with -b argument; running xterm -b 0 effectively disables padding) - the default Ubuntu terminal (gnome terminal), for example, doesn't have any padding.

P.S. Neovim doesn't suffer from this issue

[jlittlenz]

Yet-another-option for this doesn't seem right IMO, but it should not be hard-coded in gvim. This should be controlled by the style or theme, like the shape of the scrollbar buttons. Can we not allow the windowing toolkit to make these decisions? I may be showing my ignorance of GUI development here.

[ivandev-81]

Hi @ovk, Is this still an open problem ?? In that case I suggest you that check your window's config in your distro if you keep using Linux, I just installed and look GVim and I don't have this problem.

[ovk]

@ivantux1, I don't think the issue have been addressed. I don't use Vim any more (switched to Neovim), but looking at the commit history for the gui_gtk_x11.c file I don't see anything that would've removed that arbitrary hardcoded border. I also just compiled Vim from the source and I indeed can see the 2px margin/border. In fact, you have it on your screenshot, it just doesn't look immediately apparent because all of your background is white.
Besides, the general hostility of the comments in this thread made me believe the border is here to stay.

[ivandev-81]

Oooh, I understand the issue better, infact You did wanted to reduce to a absolute zero this margin, but If you really don't care anymore you may close this issue (for example, if I use Vim, I prefer use it in terminal absolutely) I don't feel uncomfortable graphically talking, and I hope don't be a rude person, I think is better collaborate cordially for experts and no-experts as me.