The FileBrowser (class Smalltalk.Tools.FileBrowser, not
Tools.FileTools.FileBrowser which is the more Explorer like) doesn't pop
up any menu (cut/copy/paste, etc) on the text editor pane at the bottom.
The editMenu would react to the selectionState updates, but no one
replaces the menu in the TextEditorController, so it always keeps [Menu
new] as its menu.
One more thing: The whole menu definition in the FileBrowser was
replaced from menu specs or ParagraphEditor groups to single methods
that define each menu action via pragmas. All submenus are defined in
pragmas and are resolved via blocks. At a first glance this seems
elegant, but leads to a huge performance impact, the more menus you add,
the worse.
With our menu structures added, the FileBrowser becomes very sluggish,
because after file selection it takes several seconds to recompute the
menus. The cause is that even for the test method #hasSubmenu in
MenuItem in the rebuildMenu process, the submenu is calculated, and for
the submenu access it is calculated again. So the submenus are
recalculated hundreds of times after each file selection, as an example,
#currentEncodingMenu is calculated 646 times with our menus added. If
you are interested in the effect; I can send you our menu additions that
were no problem before (with vw 7.6) when menus were defined with variables.
Are there any hints on how to deal with this effect?
Thomas
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Locked
