Hi Paul, I kind of like your PluginMenuItem getPlugin method idea.
While the MenuNames class is imperfect, I do think some kind of centralized control of core menus is a good thing. I don't think we need to support changing languages while OJ is running. regards, Larry On 9/13/07, Paul Austin <[EMAIL PROTECTED]> wrote: > Hi Guys, > > I haven't had time to follow the thread but I have a couple of comments > on I18N and menus. > > The plugi-ins that I have just released replace existing menu items and > tool bars with new ones with extended functionality. To do this I have > to find the I18N name of the menu item and then loop through the menu to > find it. Also I need to do this if I want to say insert a new menu item > after another menu item. What would be nice is if we has a > PluginMenuItem subclass of MenuItem that you would pass in an Plugin > instance. You could then find the menu item by using the getPlugin > method on these menu items. > > Another point is the current use of the MenuNames constants as I18N > values. I would as someone else suggested prefer a MenuKeys class where > the constants are keys into the I18N property file. Then when you create > a menu you would use an I18NMenuItem with this key, the menu item would > then call the I18N code each time it needs to display the name and if > the language was changed it would automatically pick up this new value. > > The other option is to have an I18NString class which when toString() > was called would return a String in the current language. I actually > quite like this option as you can use these anywhere that an Object > parameter is expected and toString() was used to get a string value. > > Paul > _______________________________________________ > jump-users mailing list > [email protected] > http://lists.refractions.net/mailman/listinfo/jump-users > -- http://amusingprogrammer.blogspot.com/ _______________________________________________ jump-users mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jump-users
