#404 Windows menu truncated when lots of files are open

release
open-accepted
nobody
Program (402)
7
2008-01-13
2004-08-20
Nathan Gray
No

(Reported by Offer Kaye on discuss@)

Opening a large number of files in one NEdit session can cause
trouble with the Windows menu. The menu can grow taller than
the screen, leaving some items inaccessible. Furthermore, when
such a menu is detached, the height of the resulting window is
limited to the height of the screen. The window can't be resized
and there are no scrollbars, so it's not clear if the truncated menu
items are missing or just inaccessible.

Discussion

  • Thorsten Haude

    Thorsten Haude - 2006-09-17

    Logged In: YES
    user_id=119143

    - Add a new setting nedit.windowMenuCutoff
    - Add a new submenu every time this value is reached. At the
    same time, remove one of the non-submenu entries.
    - If you reach the setting^2 (around 3600 on my system),
    stop adding any more entries.

    Volunteers?

     
  • Tony Balinski

    Tony Balinski - 2006-09-18

    Logged In: YES
    user_id=618141

    Maybe just turn the window list into a separate dialog (like
    that of the Replace dialog's "Replace all in [Multiple
    Files]") beyond a certain limit. Alternatively, provide a
    scrollable menu... that would be cool.

     
  • Thorsten Haude

    Thorsten Haude - 2006-09-18

    Logged In: YES
    user_id=119143

    I would rather like a menu with two extra entries on
    top/bottom of the list which would scroll up/down. Is that
    what you meant by "scrollable menu"?

     
  • Thorsten Haude

    Thorsten Haude - 2006-09-30
    • priority: 5 --> 9
     
  • Thorsten Haude

    Thorsten Haude - 2008-01-04

    Logged In: YES
    user_id=119143
    Originator: NO

    It can be a huge nuisance, but there's a workaround, so let's postpone it.

     
  • Thorsten Haude

    Thorsten Haude - 2008-01-04
    • priority: 9 --> 7
     
  • Bert Wesarg

    Bert Wesarg - 2008-01-09

    Logged In: YES
    user_id=122956
    Originator: NO

    I have hacked a possible starting point with the idea from thorsten.

    I have uploaded it to this page:

    http://bert.wesarg.googlepages.com/neditpatches

     
  • Thorsten Haude

    Thorsten Haude - 2008-01-13
    • labels: --> Program
    • milestone: --> release
    • status: open --> open-accepted
     
  • Thorsten Haude

    Thorsten Haude - 2008-01-13

    Logged In: YES
    user_id=119143
    Originator: NO

    Passing through a patch created by Bert Wesarg (http://bert.wesarg.googlepages.com/neditpatches).
    File Added: scrolled_window_list.patch

     
  • Thorsten Haude

    Thorsten Haude - 2008-01-13

    Logged In: YES
    user_id=119143
    Originator: NO

    The patch doesn't work for me: If I leave the menu attached it's much too awkward to use; if I detach it, one click starts a scroll that doesn't stop.

    NEdit release of Aug 20, 2004

    Built on: Linux, 486, GNU C
    Built at: Jan 13 2008, 13:42:45
    With Motif: 2.2.3 [@(#)Motif Version 2.2.3]
    Running Motif: 2.2 [@(#)Motif Version 2.2.3]
    Server: The XFree86 Project, Inc 40300001
    Visual: 24-bit TrueColor (ID 0x23, Default)
    Locale: de_DE@euro

     
  • Bert Wesarg

    Bert Wesarg - 2008-01-13

    Logged In: YES
    user_id=122956
    Originator: NO

    The patch works, at least it doesn't kill nedit ;-)

    ok some comments how this currently works and what not works (or how it should work):

    1. the two buttons are always in the menu, but only managed if more than 10 entries are there

    2. all file entries are in the menu but at most 10 are managed

    3. if you press but not release one of these two buttons, a timer is started that manage/unmanage one entry at the top and unmanage/manage at the bottom, depends on scroll direction (to speak in motif, "arm" the button)

    4. if you unpress (or "disarm" the buttom) the timer is killed, but you can't just release the mouse button, you must move the cursor away from this entry, else the button is activated and the menu will be unposted

    5. if the menu is attached the menu resizes but leaves ugly 'old' menus in the background

    6. in detached mode the timer is not killable

    7. in attached mode, the down button is always "arm"ed if the menu is refreshed, so the scrolling is not driven by the timer but by the "arm"ing

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks