Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - Initial commit of NMF AWT implementation
Initial commit of NMF AWT implementation
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
Max_Barel
Oracle


Joined: May 31, 2003
Posts: 219
Location: French Alps

PostPosted: 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?
Back to top
pinolo
Red Pill


Joined: Apr 05, 2004
Posts: 9

PostPosted: Sun Sep 19, 2004 3:27 pm    Post subject:

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.
Back to top
Max_Barel
Oracle


Joined: May 31, 2003
Posts: 219
Location: French Alps

PostPosted: Mon Sep 20, 2004 3:08 am    Post subject:

pinolo wrote:
However, even if it did the trick, I would think twice before having all of my apps behaving like that.
Wacom allows to set keystrole mapping on application basis...

pinolo wrote:
Anyway, thanks for the answer and for your work on the wiki.
It's not mine. The Wiki was set up by jakeOSX. However, anyone can edit it, it's the core feature.

Max
Back to top
fa
The Architect
The Architect


Joined: May 27, 2003
Posts: 88

PostPosted: Thu Sep 23, 2004 9:52 am    Post subject:

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?

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSMenu.html#//apple_ref/doc/uid/20000267/BBCFFBHD

menuNeedsUpdate:

- (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.
Back to top
fa
The Architect
The Architect


Joined: May 27, 2003
Posts: 88

PostPosted: Thu Sep 23, 2004 9:53 am    Post subject:

And, of course, the Java implementation of that method:

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Java/Classes/NSMenu.html#//apple_ref/doc/uid/20000646/BBCFFBHD
Back to top
fa
The Architect
The Architect


Joined: May 27, 2003
Posts: 88

PostPosted: Thu Sep 23, 2004 9:54 am    Post subject:

Unfortunately, these methods are 10.3 and higher though.
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: 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 Smile 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.

ed
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: 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.

Edward Peterlin
OPENSTEP@neooffice.org

Checking in java/com/sun/star/vcl/VCLMenu.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenu.java,v  <--  VCLMenu.java
new revision: 1.3; previous revision: 1.2
done
Checking in java/com/sun/star/vcl/VCLMenuBar.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenuBar.java,v  <--  VCLMenuBar.java
new revision: 1.6; previous revision: 1.5
done
Checking in java/com/sun/star/vcl/VCLMenuItemData.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenuItemData.java,v  <--  VCLMenuItemData.java
new revision: 1.7; previous revision: 1.6
done
Checking in java/source/window/salmenu.cxx;
/cvs/neojava/vcl/java/source/window/salmenu.cxx,v  <--  salmenu.cxx
new revision: 1.7; previous revision: 1.6
done


ed
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Sat Sep 25, 2004 2:38 pm    Post subject:

Dan,

fa wrote:
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?

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSMenu.html#//apple_ref/doc/uid/20000267/BBCFFBHD

menuNeedsUpdate:


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.

Patrick
Back to top
fa
The Architect
The Architect


Joined: May 27, 2003
Posts: 88

PostPosted: Tue Sep 28, 2004 8:17 am    Post subject:

Ed,

Forgot to mention the Notifications to use when tracking _ends_.

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Java/Classes/NSMenu.html#//apple_ref/doc/uid/20000646/BBCFFBHD

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.

Dan
Back to top
jakeOSX
Ninja
Ninja


Joined: Aug 12, 2003
Posts: 1373

PostPosted: Fri Oct 01, 2004 12:11 pm    Post subject:

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)
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Goto page Previous  1, 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

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.