Loading ...
Sorry, an error occurred while loading the content.

Re: Gtk-X11, gui.num_rows, window height and font height

Expand Messages
  • Bram Moolenaar
    ... I managed to reproduce the problem now, using a GTK version under KDE. The resizing depends on a lot of things, also size of decorations that the window
    Message 1 of 2 , Feb 6, 2008
    • 0 Attachment
      Scott Dillard wrote:

      > This is in regards to an old bug report from 2004:
      > http://tech.groups.yahoo.com/group/vimdev/message/34562
      > At the time, the problem was dismissed as the window manager's
      > (metacity) fault, but I don't think this is the case. The code in
      > question is this part of src/gui.c, ~line 1296 (from vim-7.1.tar.bz,
      > downloaded from the website)
      > gui.num_rows = (pixel_height - gui_get_base_height()
      > #if !defined(FEAT_GUI_PHOTON) && !defined(FEAT_GUI_MSWIN)
      > + (gui.char_height / 2)
      > #endif
      > ) / gui.char_height;
      > I experience this behavior, where the bottom line of text is cut-off,
      > because gui.num_rows is over-estimated. But my window manager
      > (metacity, gnome 2.18.1) is correctly reporting the window height.
      > When I put gvim in fullscreen mode, pixel_height has the correct value
      > of 1024. The function gui_get_base_height() gives a value of 4,
      > because in src/gui_gtk_x11.c, line 3437, the field gui.border_width is
      > initialized to 2, and gui_get_base_height() doubles this. Why is that?
      > What is the "border width"? When I run gvim in full screen, I can't
      > see any border -- gvim has use of all 1280x1024 pixels. But setting
      > this initial value to 0 still does not solve the problem. The only
      > other value affecting this expression in gui.char_height, which
      > appears to be set using information from pango, not metacity. So I
      > don't think this is metacity's fault.
      > In between the #if..#endif you add half a character's worth of height.
      > Why is that? If I take this out, as Tony Houghton did originally, the
      > problem is fixed. It seems to me that you want the quotient (pixels /
      > char_height) to be consistently rounded down, to take the floor of it.
      > Rounding to the nearest integer is not the right thing to do.
      > I realize this is something of a heisenbug. It will or will not happen
      > depending on your screen resolution, and which font you use. But I'm
      > just wondering about these things: Why is gui.border_width initialized
      > to 2, why is a half-character of height added to the expression, and
      > what role does the window manager play in all this? Also I don't
      > really know the vim sources inside and out, so if I'm missing
      > something please let me know.

      I managed to reproduce the problem now, using a GTK version under KDE.
      The resizing depends on a lot of things, also size of decorations that
      the window manager adds.

      I'll make a patch.

      If someone questions your market projections, simply point out that your
      target market is "People who are nuts" and "People who will buy any damn
      thing". Nobody is going to tell you there aren't enough of those people
      to go around.
      (Scott Adams - The Dilbert principle)

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
    Your message has been successfully submitted and would be delivered to recipients shortly.