Joined: May 31, 2003 Posts: 219 Location: French Alps
Posted: Sun Sep 19, 2004 1:53 pm Post subject: Warkaround for mouse wheel
If you have a scroll wheel mouse which is delivered with an application or preference pane to adjust its setting, as is my own Wacom tablet/mouse, you can set the wheel to generate page-up/page-down keystrokes. This is an acceptable workaround in Neo/J.
As this mouse wheel subject is recuring, I added a note to the FAQ section of the Wiki, although I don't know if it is read. Is it?
My Logitech prefs Pane doesn't allow to assign pgUp/Down to the scrolling. I may only assign 1 keystroke to the wheel click. However, even if it did the trick, I would think twice before having all of my apps behaving like that. I'm used to scroll with wheel, not jump.
Anyway, thanks for the answer and for your work on the wiki.
Ed, there actually is a Cocoa notification you can trap to figure out when the menu is about to be displayed. I do it for the Cocoa NMF currently and it seems to work OK. Perhaps it could be used for a 1.4JVM implementation?
- (void)menuNeedsUpdate:(NSMenu *)menu
Called when a menu is about to be displayed at the start of a tracking session so the delegate can modify the menu. You can change the menu by adding, removing or modifying menu items. Be sure to set the proper enable state for any new menu items. If populating the menu will take a long time, implement numberOfItemsInMenu: and menu:updateItem:atIndex:shouldCancel: instead.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Sep 23, 2004 10:48 pm Post subject:
Interesting. Thanks for pointing that out...nice to know there may still be some solution when we move to 1.4 I'm still banging my head on the deactivate code for trying to populate menus without needing to appropriately trap the underlying display event. While I thought activates were sufficient, they aren't as a matching deactivate is needed to make everything happy in VCL menu land.
Unfortunately there's some really wonky callbacks attached to the *deactivate* methods of menus! That's one I wouldn't have expected. Deactivating a menu potentially has as a side-effect further modifications to the underlying menus themselves and remove/insert/re-associate popup menus and the like (this occurs in Writer at least). Java menus (and by extension Carbon menus) do not play nice when the menu structures are changed while menus are being displayed. It makes the menus go all batty. So there essentially needs to be a way to trigger refreshes of contents and dimming appropriate to all menus before the menus are displayed. That's the thing I'm trying to get down just right. It's a rather nasty problem as I never assumed that I had to worry about deactivate doing all those fun things and it makes the AWT menubar regeneration triggering when a menu item's class needs to change get stuck in a bizarre loop that ends up with a nice crash inside of corefoundation.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Sep 24, 2004 12:31 am Post subject: More commits and bugfixes
OK, so I figured out how to placate the menus to behave a bit better when they're updated with UpdateMenusForFrame(). Instead of blowing away the entire menubar each time classes need to change or new delegates are created, the VCLMenu/VCLMenuItemData instances now regenerate and re-insert peers just for their parent menus. This was an optimization I had hoped to be able to put off, but now it's done and seems to work. When combined with the new activate/deactivate pairing, the native menu state properly matches the dimming state of the VCL menus and all the problems with incorrect state updating (e.g. improper Copy/Cut state in Edit menu and Toolbars) are removed.
Flip side is that now the native menu stuff causes Neo/J to suck away 100% of the CPU when Neo/J is running. This is because the Menu::Deactivate() calls in VCL result in the frames updating their bindings. There's also severe overhead in the HIToolbox as creating/retitling menu items is an expensive operation when compared to things like addition. All of these are invoked as a result of calling UpdateMenusForFrame(), which is presently done in the main Yield() method and is being done continually even when it doesn't need to be!
The next step is to hook up this fixed code to only be invoked before menus are about to be displayed. Hopefully then the CPU drain will go away.
Remaining issues: CPU drain (see above). Header/Footer submenus in the Insert menu do not display titles properly. I suspect this is due to the fact these are the submenus that are continually affected by the deactivate handler for some of the menus in Writer.
Commit log:
Code:
-- Change how class changes for menu items are handled. Menu items now keep
track of their parent menus into which they've been inserted. When a
class throws an AWTPeersInvalidatedException, the code in VCLMenu now
uses a new member function, refreshAWTPeersInParentMenus(), to remove and
reinsert the item into only its parent menus, leaving other menus untouched.
This works around problems when the activation was fixed that caused
menubars to be continually recreated while the application ran resulting in
utterly unusable menus.
-- Fix UpdateMenusForFrame() to issue deactivate events for menus right after
activate events. This fixes up the problems in VCL event handling that were
introduced by not having appropriate activate/deactivate pairs. These
event handling problems resulted in menu item and toolbar dimming not
functioning correctly in previous versions, possibly other application
errors. As a result of having a correct deactivate, however, the bindings
get refreshed and other menu operations take place to reinsert header/footer
submenus in the deactivate handlers. This required the fix above to prevent
the entire menubar from being continually destroyed and being made unusable.
-- Fix SalMenu::SetItemText() to use the correct string that has the
accelerator placeholder removed.
Ed, there actually is a Cocoa notification you can trap to figure out when the menu is about to be displayed. I do it for the Cocoa NMF currently and it seems to work OK. Perhaps it could be used for a 1.4JVM implementation?
This is good info. It looks like the equivalent of the kEventMenuOpening Carbon event so, if I use kEventMenuOpening with Java 1.3, I should be able to implement the above Obj-C method when we move to Java 1.4. I already have inactive Obj-C code to start the native event loop so adding a little more Obj-C is not a big deal. Also, compiling on Jaguar will not be a problem since this method is merely a delegate method.
BTW, I don't think the fact that this method is limited to Panther is a big deal. Since Jaguar only has the first Java 1.4 release and has had no updates since then, Java 1.4 on Jaguar is just not worth the extra debugging and maintenance so most likely I will restrict loading of Java 1.4 to only Panther or higher.
MenuDidEndTrackingNotification (posted when no action sent)
MenuDidSendActionNotification (posted after action sent)
MenuWillSendActionNotification (posted before action sent)
These are essentially what I used in the Aqua NMF.
i wanted to post this here, just in case it is relevant.
i have 10.2.8 on the iBook. when Neo/J starts there is nothing in the menu bar at the top except the blue apple. when i click on the bar, the word "NeoOffice/J" appears, as it should.
I do not see this behavior in Panther. I have, however, seen this in every version since 0.8.2ish (prior to that i never really noticed)
All times are GMT - 7 Hours Goto page Previous1, 2, 3
Page 3 of 3
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
I'm still banging my head on the deactivate code for trying to populate menus without needing to appropriately trap the underlying display event. While I thought activates were sufficient, they aren't as a matching deactivate is needed to make everything happy in VCL menu land.
