#98 user menu cache

TK Soh
Program (79)
Uwe Lehnert

The patch realizes a "manage / unmanage in stead of
destroy / create" user menu items idea. This patch
improves performance of updating user menus
(i.e. shell, macro, background menu) when
switching between tabbed documents of different
language modes.

Main idea is not to destroy any user menu item
widget as long as they are *not* changed via
"Preference->Default Settings->Customize Menu..".

Reason: destroy / create of widgets consumes
a lot of time.

In stead of destroying / creating of that menu item
widgets they are simply unmanaged / managed
(that's much faster).

For more details have a look into "FEATURE.txt"
file (available in attached tarball). Some
hints to apply this patch can be found in
"README.txt" (available in tarball, too).

This patch was made against
source tar ball of 04-Feb-2004
(available at http://nedit.sourceforge.net/snapshot/\).

This patch runs since some days within following

Built on: Solaris, Sparc, GNU C
With Motif: 1.2.6 [@(#)OSF/Motif Version 1.2.6]
Running Motif: 1.2 [@(#)OSF/Motif Version 1.2.6]
Server: Sun Microsystems, Inc. 6410


Built on: Linux, 386, GNU C (Red Hat 9)
With Motif: 2.1.30 [@(#)Motif Version 2.1.30]
Running Motif: 2.1 [unknown]
Server: The XFree86 Project, Inc 40300000


1 2 3 > >> (Page 1 of 3)
  • Uwe Lehnert

    Uwe Lehnert - 2004-02-05

    user menu cache V 1.0

  • TK Soh

    TK Soh - 2004-02-13

    Logged In: YES

    I have a concern on the memory usage. Using Uwe's rc file, I
    opened one window, then tore off its macro menu. As I was
    switching the language mode down the list (started with
    Plain), the memory size reported began to increased on an
    average of 300k per language mode, after about 10 language

    The second thing I noticed is that when you swtich to a
    langauge mode for the first time, there's still a noticable
    delay, since the user menus are needed to be rebuilt for
    each language mode.

    I believe these issues can be resolve if we only build the
    user menus once per window for all M langugage modes, even
    though not all will be used. This should limit the memory
    usage to N widgets (plus the required submenus) for N menu
    items, instead of the possible worst case of N*M. Switching
    the language mode should be fast since we simply need to
    indentify (by some algorithm) the menu/submenu widgets
    needed by the language mode and manage/unmanage them.

    The last thing I noticed is that the submenu tearoffs were
    not dismissed after we switched to the other language mode.

  • TK Soh

    TK Soh - 2004-02-13

    Logged In: YES

    BTW, what Uwe has done is very nice and will certainly move
    us one step close to 5.5. Just that perhaps some further
    polishing may be required.

  • Uwe Lehnert

    Uwe Lehnert - 2004-02-16

    Logged In: YES

    About TK's comment from 2004-02-13 10:07:
    - memory usage: what tools have you used to measure the
    memory usage ? I'm just curios.

    - "The last thing I noticed is that the submenu tearoffs
    were not dismissed after we switched to the other
    language mode."

    How to tear off submenus ? (e.g. I know how to tear off
    "Macro" Menu. Never managed to tear off a submenu of
    "macro" menu).

    How to reproduce the fault ?

    - Concerning the "build all user menu items once per window
    for all language modes" proposal: i'll think about an
    implementation (in parallel i try to realize the "manage
    user menu widgets after creation of unmanaged menu item
    widgets" idea of Scott J. Tringali. This approach should
    speed up the creation of the user menu items, too).

  • TK Soh

    TK Soh - 2004-02-16

    Logged In: YES

    1. memory usage:
    - Redhat 9.0 comes with gnome-system-monitor, but I think
    the 'top' command should work too. Not exactly accurate, but
    enough to give us some idea on the memory usage.

    2. Enable Submemu Tearoffs:
    - to allow submenu tearoffs, set resource
    'nedit*tearOffModel: TEAR_OFF_ENABLED'

    3. Reproduce bug:
    - start nedit with the standard macros bundled with nedit
    binary, open two files (tabs) with language mode of Perl & C
    - tearoff the Comment submenus for C, switch to Perl, do the
    same; you will see two tearoffs for Comments submenus, which
    should have been one;
    - now select some text in the Perl file, click on '/*
    comment */' of the C submenu tearoff. You should see the
    problem now.

  • Uwe Lehnert

    Uwe Lehnert - 2004-02-24

    Logged In: YES

    Version 2.0 of this patch implements the "build all user
    menu items once per window for all language modes"
    proposal. Memory usage should be no issue anymore.
    User menu widgets are now created unmanaged
    (Scotts idea). The "tear off sub menu bug" is solved too.

    Details can be found inside the tar ball
    (file FEATURE.txt).

    The patch was made against
    source tar ball of 21-Feb-2004
    (available at http://nedit.sourceforge.net/snapshot/\).

  • TK Soh

    TK Soh - 2004-02-25

    Logged In: YES

    I had a look at it. Memory usage is no longer a problem.
    Language mode switching is reasonably fast, at least on my
    machine. Good job!

    One minor issue though, is that the submenu tearoffs are
    always dismissed when the lang mode is switched, even
    though the submenus were completely/partially shared by the
    language modes. While this doesn't seem such a big deal to
    me, though of you who use tearoffs a lot might gather some
    frustration. So we should at least keep this on the list of

    I hope to see this patch committed as soon as possible. So,
    if those you heavy macro-and-tearoff users can give it a
    try, especial on those slowest platform available (Sparc 5,

  • Uwe Lehnert

    Uwe Lehnert - 2004-02-25

    Logged In: YES

    For the record: original behavior (means: CVS head
    without this patch) is to dismiss sub menu tear offs
    when language mode is switched (simply because
    the related widgets are destroyed).

  • TK Soh

    TK Soh - 2004-02-25

    Logged In: YES

    I am aware of the original behavior, But things are slightly
    different these day. Once again, it doesn't bother me that
    much whether we close the tearoffs, since I almost never use
    tearoffs. But for the 'love' of tearoffs, we should do
    something about it, in time.

1 2 3 > >> (Page 1 of 3)

Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks