Yes - I was using haxie as a generic term for anything that might in some way influence the menubar (I've had menubar apps before mow that have really futzed with other apps), as well as the more specific usage - in fact, NOMu makes no difference to this, I was just trying to be factually accurate and muddied things instead.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Feb 20, 2008 12:01 am Post subject:
OK I'll take a look at this and see if I can figure anything out. I normally am using 10.4. The Help menu in 10.5 is "special"...the OS now looks for menus with that name and adds in the extra search and navigation field. That may be what's causing the side-effect for the Help menu.
In the meantime, a workaround may be to create a new menu with a different name (Tools > Customize) and put the standard help items in that new menu. That should remove the special 10.5 behaviour triggered by the menu title.
Joined: Apr 25, 2006 Posts: 2315 Location: Montpellier, France
Posted: Sun Mar 02, 2008 3:38 pm Post subject:
pluby wrote:
pluby wrote:
rays wrote:
On the other hand, when I open the Preferences window, I do still have active menu items viewable in the drop down menus available in the Mac top menu bar. Amongst those is the Window>Close Window cmnd-w which is not greyed out. This is what led me to expect selecting that menu item or using cmnd-w at that stage would close the preferences window. (Which, of course, it doesn't.)
The behavior you describe has been in NeoOffice for quite a while now. The menus that you see when opening a non-native dialog (like Tools :: Options) are really the menus of the dialog's parent window, not the dialog window as OOo has no menus in any of its dialog windows.
I have uploaded a new test patch that fixes the long-standing problem that rays described. In the new test patch NeoOffice will disable all of the menus if a modal dialog (such as Tools :: Option) is displayed.
I have been wondering whether "will disable all of the menus" meant that no menus would appear in the menu bar, or that all menu items would be grayed-out.
I first though that the menus should disappear and almost posted something about it, but since all items were grayed-out for me under Tiger, I assumed this was the intended behavior.
However, I just booted under Panther to check whether bug 2945 was specific to that OS, and realized that the behavior of NeoOffice was different. Here's what I get with NeoOffice 2.2.2 Patch 11 Test 2:
1) under Mac OS X 10.3.9, when I open a modal dialog (NeoOffice > About NeoOffice, NeoOffice > Preferences… or Tools > Options…, Format > Page…), all menus other than the NeoOffice menu disappear from the menu bar;
2) under Mac OS X 10.4.11 PowerPC (and possibly under 10.5.2 Intel as well), when I open a modal dialog, all menus remain in the menu bar, but all menu items not in the NeoOffice menu are grayed-out;
Is this normal, and is the behavior I see under Tiger expected?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Mar 02, 2008 4:29 pm Post subject:
Offhand, given the 10.3.9 results I think this might be a Java VM issue. My weird AWT delegate code, IIRC, recreates the menus on a per window basis so if they don't show up for a window it might be a VM difference based on window class.
I do have one testing machine left with 10.3 on it and can try to dive in further. My Quad can't boot 10.3
1) under Mac OS X 10.3.9, when I open a modal dialog (NeoOffice > About NeoOffice, NeoOffice > Preferences… or Tools > Options…, Format > Page…), all menus other than the NeoOffice menu disappear from the menu bar;
2) under Mac OS X 10.4.11 PowerPC (and possibly under 10.5.2 Intel as well), when I open a modal dialog, all menus remain in the menu bar, but all menu items not in the NeoOffice menu are grayed-out;
Is this normal, and is the behavior I see under Tiger expected?
Yes, this is normal. Java on Panther completely hides all of the menus in the menubar when a dialog window is displayed whereas Java on Tiger and later will do any hiding. In both cases, a disable the menus when a dialog is displayed, but due to the differences in Apple's Java behavior, the menu items will always disappear on Panther.
FYI. I have posted the following new test patch. As a result of bug 2922, I changed the menu behavior so that when a dialog or palette window has focus, the menubar is hidden instead of disabled. This approach, which is the approach that Java does by default on 10.3.x, is a lot simpler to implement and, hopefully, will be more robust on different versions of Mac OS X:
FYI. I have posted the following new test patch. As a result of bug 2922, I changed the menu behavior so that when a dialog or palette window has focus, the menubar is hidden instead of disabled. This approach, which is the approach that Java does by default on 10.3.x, is a lot simpler to implement and, hopefully, will be more robust on different versions of Mac OS X
Yes, nicer would be if Apple would fix their java implementation so that the standard OS X behavior would work here.
The standard is for the menues to remain active, with any commands that make sense to work for the last active document window, as can easily be seen in TextEdit with the font palette open.
For example, command-W closes the palette window, but pretty much all the other commands act on the document window.
Yes, nicer would be if Apple would fix their java implementation so that the standard OS X behavior would work here.
The standard is for the menues to remain active, with any commands that make sense to work for the last active document window, as can easily be seen in TextEdit with the font palette open.
For example, command-W closes the palette window, but pretty much all the other commands act on the document window.
Fix Java is only one of the issues here. The bigger issue is the fundamental design of NeoOffice's underlying OpenOffice.org code. OpenOffice.org was designed as a Windows application and the Windows model of each window has its own menu is firmly embedded into the OpenOffice.org code.
We are very familiar with Apple's Human Interface Guidelines so the issue is not ignorance of Apple's HIG, the issue is that it takes a great deal of developer time and funding to bend and twist the OpenOffice.org code into those guidelines. This is the primary reason that after 6 years, NeoOffice still has many significant deviations from Apple's HIG.
I had to refactor the fix for the menu bugs that rays and yoxi reported earlier in this thread in order to fix a deadlocking bug reported in bug 3425.
Since there is a risk that my fix for bug 3425 will cause rays' or yoxi's bugs to reoccur, can you install the following test patch and tell us if rays' and yoxi's bugs are still fixed for you? Note that there are test patches for both NeoOffice 2.2.5 and 3.0 Early Access 2 so download the patch that matches the NeoOffice version that you are currently running:
Another deadlock was found that is related to bug 3425. Ithink that I fixed this latest deadlocking bug, but I had to make some less than trivial changes to NeoOffice's native menu code.
Since there is a risk that my fix for bug 3425 will cause rays' or yoxi's bugs to reoccur, can you install the latest test patch and tell us if rays' and yoxi's bugs are still fixed for you? I have posted links to both NeoOffice 2.2.5 and NeoOffice 3.0 test patches in my last post in bug 3425.
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
