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

Re: Vertical-Split GUI-window resize not intuitive...could _almost_ call it a bug.

Expand Messages
  • Matthew Winn
    ... It is intuitive, if by intuitive you mean working in the same way as pretty much every other application . The contents of a window are anchored to the
    Message 1 of 9 , May 2, 2008
      On Fri, 02 May 2008 01:41:06 -0700, Linda W <vim@...> wrote:

      > Um...does this seem "natural"? Maybe from a computer "rule" of
      > "always resize the right-most window" when moving an outer, vertical window
      > border, but, that's a 'computer' rule perspective, not an intuitive,
      > human-interface perspective. It doesn't behave by consistent rules with
      > respect to the individual sub-windows. If I move to a non-shared, outer edge
      > of a sub-window, I'd feel it was more 'natural' to have the window whose
      > outer side I was moving be the window that resizes -- not, always, the
      > right-most window which seems more. Always do the 'right' seems like an
      > arbitrary behavior based on how the underlying window system happened to
      > work works and the happenstance of how vim's sub-windows are built on top
      > of the native windowing system widgets.

      It is intuitive, if by "intuitive" you mean "working in the same way
      as pretty much every other application". The contents of a window are
      anchored to the top and left borders, so when you move the bottom or
      right edges of a window it reveals or hides the window's content at
      those edges, but moving the left or top edges moves the content with
      the edges.

      It might be counter-intuitive if you read from right to left, but most
      modern application behaviour was designed by Americans.

      --
      Matthew Winn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_use" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Linda W
      ... First, let me be clear that I do know how to work around the problem and know how to manually move the interior edges of the windows to adjust the screen.
      Message 2 of 9 , May 2, 2008
        Tony Mechelynck wrote:
        > For fine control over the respective size of the different windows
        > inside the Vim screen, grab the separation between them (the vertical
        > separation or the horizontal statusline) and move that.
        ---
        First, let me be clear that I do know how to work around the
        problem and know how to manually move the interior edges of the windows to
        adjust the screen. It's not a "I don't know how to do this", but more of
        a "I don't know how to configure the GUI to work symmetrically".


        > IIUC, Vim knows the "global size" of its screen and doesn't care much
        > about its "position": when you grab the titlebar and move it, the
        > contents don't change;
        ---
        Not pertinent, as I'm not moving the window with the title bar,
        but yes...I understand that.

        > when you grab one of the sides and move it, what
        > Vim sees is that its whole screen becomes bigger or smaller (in the
        > absolute). Dragging the left border leftwards or the right border
        > rightwards both make the screen bigger. In addition, moving the left
        > side changes the _position_ of the screen but Vim doesn't care about
        > that
        ------------
        And herein lies the solution. If vim sees that the "X"
        position is changing *and* the "X" size is changing, then it can
        logically deduce that the left edge of the screen is moving.

        If only the "X" size is changing, then it knows the "right"
        edge is moving.

        Vim could "choose" to do the "right thing" based on human
        interface design principles rather than using the default, underlying
        window management mechanism. The underlying window management
        behavior is just a default that works pretty well when 1 window
        is displayed. What happens when multiple windows are displayed,
        however is up to the application.

        In other GUI programs I've seen three behaviors. At the lowest
        level, are utility programs like MS's "Depends", where if it is an
        interior window frame OR a column, only the window's adjacent to
        the frame or column are resize (like vim's internal window divider).

        A slightly more advanced, but somewhat in between behavior is
        seen in T-bird -- it uses its own GUI-widget library so it's evolution
        is in between (and somewhat internally inconsistent). If you move
        an interior window-frame, any sub-columns within the windows are
        resized *proportionate* to their starting size. This keeps them
        "proportionately" the same after the movement as before -- though
        increased space in the window is redistributed evenly throughout the
        horizontal space. However --- if you move a column internal to a an
        internal window, only the size of the two columns immediately adjacent
        to the moved column are resized (much like vim's internal windows are
        now).

        A slightly more advanced algorithm in the more mature GUI in
        MS's Outlook program, works consistently, (not identically),
        for both interior window borders *and* interior window columns. If you
        resize interior window borders, the space of all columns in both
        affected windows changes proportionately to their starting size. If
        you change a column position inside of a sub-window, all columns
        in that one sub-window are resized proportionately to their original
        size.

        I'm sure other examples can be found, but the one that is
        closest to 'vim's behavior is also the one that isn't aimed at "end-users", but
        at "developers" where "beauty" or GUI-friendliness
        isn't a priority.

        Admittedly, some might regard a line-oriented text editor as
        falling into the utilitarian category .. and certainly, with the
        original 'vi', this is mostly true.

        But vim...especially GUI vim, ... well, I think of it in a level
        above that and believe that the Human-Interface, GUI design factors
        could be given more thought -- not to act like "computer windows", but
        like real windows -- where the windows tend to stay in the same place
        unless you pick up the "frame" of the window and move it. But if you
        have horizontal sliding windows, moving the right-outward frame only moves (and
        resizes) the right opening, where moving the left-outward frame only moves (and
        resizes) the left opening. In *both* cases, the window doesn't move, but the
        window next to the outer frame changes size.

        If the physical windows *are* *not* designed flexibly, then
        moving one window will change the size on the other side, but it's not
        always so -- if the windows were designed with a gap in between, then
        moving one window only changes that window's area, with the other edge
        moving over the gap, (or), the windows can have a 'hiding' or folding
        feature like 'shutters', so moving the outer edge of one window only changes the
        window on the side you are moving -- but the center stays anchored. Those are
        the usually considered the *best* designed windows -- that are also usually the
        most expensive.

        It's the cheaper, lower quality and lower workmanship windows that move in
        respect to underlying hardware limitations. In software,
        that can be like programs that expose the underlying limitations of
        the graphical library, rather than compensating for library deficiencies
        to provide a superior interface or functionality.


        As an example in software -- relating to Font placement on
        the screen. You can see a difference in how a document looks with the
        same font in MS-Word vs. Adobe Acrobat. Acrobat tries to give you the
        impression of how it would look on paper -- independent of the display
        hardware (Apple computers also use the hardware independent placement,
        which is why Apples are more often used in word-processing and visual
        media layout industries). Microsoft (and MS-Word), *approximate*
        font placement based on the underlying hardware. They move vertical
        font lines to the right or left so they line up on the vertical pixel
        rows. So your text will almost never be exactly 'even' or proportional
        using the hardware-limited rendering, though the hardware rendering may
        give sharper looking text -- especially at small fonts sizes. But
        only by developing a layer of "independence" over the limitations of
        the underlying hardware (or GUI libraries), do programs achieve
        intuitive behavior as one is familiar with in the physical world.

        Anyway, such font placement would be pointless in a fixed-sized
        text editor primarily designed for programming, but how the windows
        behave can be entirely "arbitrary" and up to program design. Thus,
        my suggestion, that vim's windows could behave more intuitively from
        a real-world perspective. It is a very *TRIVIAL* point. Like
        discussing the differences between brownish-shades of red and burgundy
        or maroon. In one example, you fix the user's "experience" to the
        limitations of the hardware or software, vs. choosing "desired" behavior
        and making the program behave that way despite limitations of hardware
        and software (obviously there are trade offs in cost vs. feature). I
        was just suggesting a light 'upgrade' of vim's windowing model, *as*
        a settable or configurable option. As I mentioned above, the algorithm
        *seems* fairly straight-forward....

        But....it may not be worth the effort... :-)

        Linda

        p.s. -- thanks for the settings to play with:
        > Note that the settings of 'equalalways', 'eadirection', 'winwidth',
        > 'winminwidth', 'winheight' and 'winminheight' are relevant -- changing
        > them will change what happens in given circumstances.
        >


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_use" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Tony Mechelynck
        ... Oh, I see: when moving the left edge leftwards, and the leftmost window is showing the beginning of the lines (not scrolled laterally, that is), you would
        Message 3 of 9 , May 2, 2008
          On 02/05/08 21:27, Linda W wrote:
          > Tony Mechelynck wrote:
          >> For fine control over the respective size of the different windows
          >> inside the Vim screen, grab the separation between them (the vertical
          >> separation or the horizontal statusline) and move that.
          > ---
          > First, let me be clear that I do know how to work around the
          > problem and know how to manually move the interior edges of the windows to
          > adjust the screen. It's not a "I don't know how to do this", but more of
          > a "I don't know how to configure the GUI to work symmetrically".
          >
          >
          >> IIUC, Vim knows the "global size" of its screen and doesn't care much
          >> about its "position": when you grab the titlebar and move it, the
          >> contents don't change;
          > ---
          > Not pertinent, as I'm not moving the window with the title bar,
          > but yes...I understand that.
          >
          >> when you grab one of the sides and move it, what
          >> Vim sees is that its whole screen becomes bigger or smaller (in the
          >> absolute). Dragging the left border leftwards or the right border
          >> rightwards both make the screen bigger. In addition, moving the left
          >> side changes the _position_ of the screen but Vim doesn't care about
          >> that
          > ------------
          > And herein lies the solution. If vim sees that the "X"
          > position is changing *and* the "X" size is changing, then it can
          > logically deduce that the left edge of the screen is moving.
          >
          > If only the "X" size is changing, then it knows the "right"
          > edge is moving.
          >
          > Vim could "choose" to do the "right thing" based on human
          > interface design principles rather than using the default, underlying
          > window management mechanism. The underlying window management
          > behavior is just a default that works pretty well when 1 window
          > is displayed. What happens when multiple windows are displayed,
          > however is up to the application.
          >
          > In other GUI programs I've seen three behaviors. At the lowest
          > level, are utility programs like MS's "Depends", where if it is an
          > interior window frame OR a column, only the window's adjacent to
          > the frame or column are resize (like vim's internal window divider).
          >
          > A slightly more advanced, but somewhat in between behavior is
          > seen in T-bird -- it uses its own GUI-widget library so it's evolution
          > is in between (and somewhat internally inconsistent). If you move
          > an interior window-frame, any sub-columns within the windows are
          > resized *proportionate* to their starting size. This keeps them
          > "proportionately" the same after the movement as before -- though
          > increased space in the window is redistributed evenly throughout the
          > horizontal space. However --- if you move a column internal to a an
          > internal window, only the size of the two columns immediately adjacent
          > to the moved column are resized (much like vim's internal windows are
          > now).
          >
          > A slightly more advanced algorithm in the more mature GUI in
          > MS's Outlook program, works consistently, (not identically),
          > for both interior window borders *and* interior window columns. If you
          > resize interior window borders, the space of all columns in both
          > affected windows changes proportionately to their starting size. If
          > you change a column position inside of a sub-window, all columns
          > in that one sub-window are resized proportionately to their original
          > size.
          >
          > I'm sure other examples can be found, but the one that is
          > closest to 'vim's behavior is also the one that isn't aimed at "end-users", but
          > at "developers" where "beauty" or GUI-friendliness
          > isn't a priority.
          >
          > Admittedly, some might regard a line-oriented text editor as
          > falling into the utilitarian category .. and certainly, with the
          > original 'vi', this is mostly true.
          >
          > But vim...especially GUI vim, ... well, I think of it in a level
          > above that and believe that the Human-Interface, GUI design factors
          > could be given more thought -- not to act like "computer windows", but
          > like real windows -- where the windows tend to stay in the same place
          > unless you pick up the "frame" of the window and move it. But if you
          > have horizontal sliding windows, moving the right-outward frame only moves (and
          > resizes) the right opening, where moving the left-outward frame only moves (and
          > resizes) the left opening. In *both* cases, the window doesn't move, but the
          > window next to the outer frame changes size.
          >
          > If the physical windows *are* *not* designed flexibly, then
          > moving one window will change the size on the other side, but it's not
          > always so -- if the windows were designed with a gap in between, then
          > moving one window only changes that window's area, with the other edge
          > moving over the gap, (or), the windows can have a 'hiding' or folding
          > feature like 'shutters', so moving the outer edge of one window only changes the
          > window on the side you are moving -- but the center stays anchored. Those are
          > the usually considered the *best* designed windows -- that are also usually the
          > most expensive.
          >
          > It's the cheaper, lower quality and lower workmanship windows that move in
          > respect to underlying hardware limitations. In software,
          > that can be like programs that expose the underlying limitations of
          > the graphical library, rather than compensating for library deficiencies
          > to provide a superior interface or functionality.
          >
          >
          > As an example in software -- relating to Font placement on
          > the screen. You can see a difference in how a document looks with the
          > same font in MS-Word vs. Adobe Acrobat. Acrobat tries to give you the
          > impression of how it would look on paper -- independent of the display
          > hardware (Apple computers also use the hardware independent placement,
          > which is why Apples are more often used in word-processing and visual
          > media layout industries). Microsoft (and MS-Word), *approximate*
          > font placement based on the underlying hardware. They move vertical
          > font lines to the right or left so they line up on the vertical pixel
          > rows. So your text will almost never be exactly 'even' or proportional
          > using the hardware-limited rendering, though the hardware rendering may
          > give sharper looking text -- especially at small fonts sizes. But
          > only by developing a layer of "independence" over the limitations of
          > the underlying hardware (or GUI libraries), do programs achieve
          > intuitive behavior as one is familiar with in the physical world.
          >
          > Anyway, such font placement would be pointless in a fixed-sized
          > text editor primarily designed for programming, but how the windows
          > behave can be entirely "arbitrary" and up to program design. Thus,
          > my suggestion, that vim's windows could behave more intuitively from
          > a real-world perspective. It is a very *TRIVIAL* point. Like
          > discussing the differences between brownish-shades of red and burgundy
          > or maroon. In one example, you fix the user's "experience" to the
          > limitations of the hardware or software, vs. choosing "desired" behavior
          > and making the program behave that way despite limitations of hardware
          > and software (obviously there are trade offs in cost vs. feature). I
          > was just suggesting a light 'upgrade' of vim's windowing model, *as*
          > a settable or configurable option. As I mentioned above, the algorithm
          > *seems* fairly straight-forward....
          >
          > But....it may not be worth the effort... :-)
          >
          > Linda
          >
          > p.s. -- thanks for the settings to play with:
          >> Note that the settings of 'equalalways', 'eadirection', 'winwidth',
          >> 'winminwidth', 'winheight' and 'winminheight' are relevant -- changing
          >> them will change what happens in given circumstances.
          >>
          >
          >
          > >
          >

          Oh, I see: when moving the left edge leftwards, and the leftmost window
          is showing the beginning of the lines (not scrolled laterally, that is),
          you would want the editor to indent every line by adding extra spaces at
          the left. :-P

          Regards,
          Tony.
          --
          Florida:
          A special law prohibits unmarried women from parachuting on Sunday or she
          shall risk arrest, fine, and/or jailing.
          [real standing law in Florida, United States of America]

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_use" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Linda W
          ... *sigh* --~--~---------~--~----~------------~-------~--~----~ You received this message from the vim_use maillist. For more information, visit
          Message 4 of 9 , May 3, 2008
            Tony Mechelynck wrote:
            > Oh, I see: when moving the left edge leftwards, and the leftmost window
            > is showing the beginning of the lines (not scrolled laterally, that is),
            > you would want the editor to indent every line by adding extra spaces at
            > the left. :-P
            ---

            :-|
            *sigh*


            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_use" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Ben Schmidt
            ... I don t know that really supports your argument! Real windows actually have less functionality and consistency, and I would think of them as *below*
            Message 5 of 9 , May 4, 2008
              > But vim...especially GUI vim, ... well, I think of it in a level
              > above that and believe that the Human-Interface, GUI design factors
              > could be given more thought -- not to act like "computer windows", but
              > like real windows

              I don't know that really supports your argument! Real windows actually have less
              functionality and consistency, and I would think of them as *below* computer
              windows. They can't be moved except by moving the house or vehicle in which they
              are situated. They can't truly be resized--only panes can overlap. Some open by
              sliding, some by a hinge, some electronically, some by a winder mechanism. Others
              can't be opened at all. Some are made of clear glass, some frosted glass, some
              stained glass, some tinted glass, others perspex or such. Sometimes they break,
              though probably less often than computer windows, though for the average user when
              a real window crashes it's probably more dangerous. And that's only the tip of the
              iceberg.

              On the serious side, though, I can see what you mean, but I'm not sure I agree
              that it's more intuitive to always resize the window at the edge you drag; if I
              enlarge a window from the top or left it's often because I want to see more at the
              bottom or right. But then, the window is often a different kind of layout to a Vim
              window with multiple subwindows. I think the proportional resizing of all windows
              would probably make the most sense, being consistent and making the least
              assumptions about what the user is wanting to do. It is probably also the hardest
              as with continually rounding to integer numbers of lines and columns things get
              messy. A compromise could be to disribute a change of size equally among windows,
              which might work by rotating registers of windows, adding new columns/rows to each
              in turn.

              As you say, it isn't high priority. Bram may think it's worthy of the to do list,
              I don't know. But my suspicion is that it's most likely to happen if some
              developer shares your passion for the issue and submits a patch for consideration!

              Smiles,

              Ben.




              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_use" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Andy Wokula
              ... -- Andy --~--~---------~--~----~------------~-------~--~----~ You received this message from the vim_use maillist. For more information, visit
              Message 6 of 9 , May 4, 2008
                Ben Schmidt schrieb:
                > [...] I think the proportional resizing of all windows
                > would probably make the most sense, being consistent and making the least
                > assumptions about what the user is wanting to do. It is probably also the hardest
                > as with continually rounding to integer numbers of lines and columns things get
                > messy. A compromise could be to disribute a change of size equally among windows,
                > which might work by rotating registers of windows, adding new columns/rows to each
                > in turn.

                IIUC this one is very easy:

                :au VimResized * wincmd =

                > As you say, it isn't high priority. Bram may think it's worthy of the to do list,
                > I don't know. But my suspicion is that it's most likely to happen if some
                > developer shares your passion for the issue and submits a patch for consideration!
                >
                > Smiles,
                >
                > Ben.

                --
                Andy


                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_use" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Andy Wokula
                ... The VimResized autocmd allows Vim scripts to handle the situation. ... As a start, here is an attempt to keep the position of vertical window bars on
                Message 7 of 9 , May 4, 2008
                  Linda W schrieb:
                  > Let me preface this by saying that I this is a minor "nit", and one
                  > could probably argue its correctness based on artifactual behavior
                  > based on how the windows are split and handled by the windowing
                  > system, BUT, but on an intuitive, human level, it doesn't seem like
                  > natural behavior. (though it may be the case that I have my head
                  > buried especially deep in my paradigm and can't see a different forest
                  > view for the trees :-) (it's always the darn trees! :-))).
                  >
                  > I split the screen vertically, and wanted to adjust each window to 80
                  > columns. I started on the ->right-> and went to the _right_-frame on
                  > the _right_ exterior of the _right_ window. I grabbed the frame and
                  > moved it to the ->right->. The center-split (where the window was
                  > vertically split) stayed stationery, while the _right_ edge of the
                  > _right window_ moved away from the center-line (toward the right),
                  > widening the right sub-window (screen split).
                  >
                  > When done with the right side I went to repeat the actions on the
                  > <-left<- window, with left substituted, 'above' for all the 'right'
                  > words.
                  >
                  > Except that it doesn't work that way.
                  >
                  > When I move the left-outer edge of the left window, 'left', instead of
                  > moving the left edge away from the center line, the entire left window
                  > shifts to the left -- not widening the left window as I desired and
                  > would have reciprocally expected, but instead, having the effect of
                  > widening the right window again!
                  > ACK!
                  >
                  > Um...does this seem "natural"? Maybe from a computer "rule" of
                  > "always resize the right-most window" when moving an outer, vertical
                  > window border, but, that's a 'computer' rule perspective, not an
                  > intuitive, human-interface perspective. It doesn't behave by
                  > consistent rules with respect to the individual sub-windows. If I
                  > move to a non-shared, outer edge of a sub-window, I'd feel it was more
                  > 'natural' to have the window whose outer side I was moving be the
                  > window that resizes -- not, always, the right-most window which seems
                  > more. Always do the 'right' seems like an arbitrary behavior based on
                  > how the underlying window system happened to work works and the
                  > happenstance of how vim's sub-windows are built on top of the native
                  > windowing system widgets.
                  >
                  > Am I being reasonably lucid and clear? :-) It's an "asymmetry" in how
                  > the GUI works.
                  >
                  > Anyway, it's obviously not that big of a deal, but more a
                  > design-'preference', like one might have a preference for some
                  > symmetry in art or engineering design.
                  >
                  > Perhaps this behavior is controllable with some configuration setting,
                  > or is this one of those hard-coded limitations like forgotten support
                  > for setting 'very magic' in your vimrc for the default, interactive
                  > search/replace mode?
                  >
                  > Thanks,
                  > Linda

                  The VimResized autocmd allows Vim scripts to handle the situation.
                  :h VimResized

                  As a start, here is an attempt to keep the position of vertical window
                  bars on screen:


                  if getwinposx() == -1
                  finish
                  endif

                  let s:columns = &columns
                  let s:winposx = getwinposx()

                  " find windows adjacent to the Vim window's left border AND that have
                  " other windows to the right
                  func! s:LeftWindowNums()
                  let wnrlist = []
                  for wnr in range(1, winnr("$"))
                  exec wnr."wincmd w"
                  wincmd h
                  if winnr() == wnr
                  wincmd l
                  if winnr() != wnr
                  call add(wnrlist, wnr)
                  endif
                  endif
                  endfor
                  return wnrlist
                  endfunc

                  " find windows with other windows to the left AND right
                  func! s:MidWindowNums()
                  let wnrlist = []
                  for wnr in range(1, winnr("$"))
                  exec wnr."wincmd w"
                  wincmd h
                  if winnr() == wnr
                  continue
                  endif
                  exec wnr."wincmd w"
                  wincmd l
                  if winnr() == wnr
                  continue
                  endif
                  call add(wnrlist, wnr)
                  endfor
                  return wnrlist
                  endfunc

                  func! s:UpdateWinWidths()
                  let dcolumns = &columns - s:columns

                  " Linda W schrieb:
                  " And herein lies the solution. If vim sees that the "X" position
                  " is changing *and* the "X" size is changing, then it can logically
                  " deduce that the left edge of the screen is moving.
                  if s:winposx == getwinposx() || dcolumns == 0
                  return
                  endif

                  let savwnr = winnr()
                  let sav_ei = &ei
                  set eventignore=all

                  let g:midwinsresizecmd = ""
                  for wnr in s:MidWindowNums()
                  let g:midwinsresizecmd .= "|". wnr. "wincmd w"
                  \. "|vert resize ". winwidth(wnr)
                  endfor

                  let g:leftwinsresizecmd = ""
                  for wnr in s:LeftWindowNums()
                  let g:leftwinsresizecmd .= "|". wnr. "wincmd w"
                  \. "|vert resize ". (winwidth(wnr) + dcolumns)
                  endfor

                  exec g:leftwinsresizecmd[1:] . g:midwinsresizecmd

                  exec savwnr."wincmd w"
                  let &ei = sav_ei

                  let s:columns = &columns
                  let s:winposx = getwinposx()
                  endfunc

                  augroup appwinresize
                  au!
                  au VimResized * call s:UpdateWinWidths()
                  augroup end


                  Ok, just found a bug: move the right edge, then move the left edge --
                  this somehow restores the size of rightmost windows.

                  Also to be tested with combinations of relevant options.

                  No matter, it's just meant as a little demo.

                  --
                  Andy


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