After letting BottomFeeder 3.6 go, I had someone in Germany send me a message about menu performance. One of the recent changes is that the application uses UserMessages instead of strings (I'm still looking for volunteers to translate the catalog, by the way). This makes it possible to have the application translated - but I hadn't actually set up catalogs in the runtime. Well, that can cause speed issues related to the lookup (which defaults to a string) for the messages. Well. Into the doc I went. After learning about half of what I needed, I decided to do the simplest thing in Smalltalk - I executed this and ran through the debugger to see how lookup worked:
(UserMessage defaultString: 'Add Comment to Selected Item' key: #bfAddCommentOnItem) asString
What I discovered was that VW expects a root level directory for catalog searches, and then proceeds to look for subdirectories and catalogs based on locale settings. Ok, I indexed the catalog I had (fixing a bunch of missing quote issues) this way:
IndexedFileMessageCatalog compileAllCatalogsFor: 'catalog'.
and then made sure that the catalog directory was in the search path for catalogs:
"add directory to message catalogs list for lookup purposes" mine := IndexedFileMessageCatalog directoriesModel value detect: [:each | 'catalog' = each asString] ifNone: [nil]. mine ifNil: [| file | file := PortableFilename named: 'catalog'. IndexedFileMessageCatalog directoriesModel value add: file].
Now, I don't know that this is the best way to do this - there's a whole system for registering catalog ids and such, but I'm not using any of that. I'm doing a new build of the BottomFeeder files, and I'll have them uploaded shortly. If you have Bf and have noticed an odd slowdown in menu or UI performance, then grab the appropriate base file:
And grab the new exe or image, as well as the 'catalog' directory. Restart, and that should solve the problem. As usual, inform me of any problems. Hat tip to Thomas Brodt for letting me know about this problem!