#1022 Larger buffers menu to show all buffers

Completed
closed
Neil Hodgson
scite (13)
5
2013-10-15
2013-09-26
Glenn Washburn
No

This patch allows for the menu items of all buffers to be displayed in the Buffers menu. Currently its arbitrarily set to a maximum of 40 displayed, less than the number of buffers I regularly use.

Also it raises the maximum number of buffers to 200. It makes bufferMax depended on the IDM_BUFFER and IDM_IMPORT, thus allowing for only one place needed to change to grow or shrink the maximum number of buffers.

If you'd prefer not to raise the bufferMax from 100 to 200, that's acceptable to em, however I'd appreciate if the other changes making it easier to change the bufferMax are applied.

Thanks! I've been using scite for over a decade now and really appreciate the hardwork.

1 Attachments

Discussion

  • Neil Hodgson
    Neil Hodgson
    2013-09-27

    Menus that are too high for the screen often behave poorly and confuse users. The cap is to limit the problem and lessen the support cost of dealing with complaints.

    A better UI would be needed to handle large numbers of open buffers. Perhaps a dialog similar to the "Windows" dialog in Visual Studio or a side bar.

     
    • Glenn Washburn
      Glenn Washburn
      2013-09-28

      I understand that arguement and am sympathetic. However, in my case, linux gtk build with 1366x768 screen, already both the Language and Buffers (at 40) menus are longer than the height of my screen. I wonder for how many others this is already true. My window manager adds a way to scroll the menu when it gets too large, but I do recall window have problems with that way back when.

      Also, would a long menu of which many menuitems could not be reached be any more confusing than the current situation where I can have 100 buffers open, but only see 40 of them in the menu. I can still access the ones with no menu item by cycling through buffer prev and next.

      It seems that adding this capability benefits users with systems capable of displaying all the menu items, while providing a different kind of confusion/annoyance for those that don't (ie not much change). I would suspect that too many menu items don't do anything really crazy, just go off the screen and maybe reposition the menu list.

      I am the most comfortable with the menu list interface because it does take up any permanent extra screen space nor do I have to mess around with other windows, that is its fairly efficient.

       
  • Glenn Washburn
    Glenn Washburn
    2013-09-28

    I understand that arguement and am sympathetic. However, in my case, linux gtk build with 1366x768 screen, already both the Language and Buffers (at 40) menus are longer than the height of my screen. I wonder for how many others this is already true. My window manager adds a way to scroll the menu when it gets too large, but I do recall window have problems with that way back when.

    Also, would a long menu of which many menuitems could not be reached be any more confusing than the current situation where I can have 100 buffers open, but only see 40 of them in the menu. I can still access the ones with no menu item by cycling through buffer prev and next.

    It seems that adding this capability benefits users with systems capable of displaying all the menu items, while providing a different kind of confusion/annoyance for those that don't (ie not much change). I would suspect that too many menu items don't do anything really crazy, just go off the screen and maybe reposition the menu list.

    I am the most comfortable with the menu list interface because it does take up any permanent extra screen space nor do I have to mess around with other windows, that is its fairly efficient.

     
  • Neil Hodgson
    Neil Hodgson
    2013-10-04

    • labels: --> scite
    • assigned_to: Neil Hodgson
     
  • Neil Hodgson
    Neil Hodgson
    2013-10-04

    Committed changes to SciTEBase.h and SciTEGTK.cxx as [d90865].

     

    Related

    Commit: [d90865]

  • Neil Hodgson
    Neil Hodgson
    2013-10-15

    • status: open --> closed