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

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

Expand Messages
  • Scott Dillard
    Hi, 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
    Message 1 of 2 , Feb 2 10:45 AM
    • 0 Attachment
      Hi,

      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.

      Thanks,
      Scott

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • 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 2 of 2 , Feb 6 8:33 AM
      • 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.