View previous topic :: View next topic |
Author |
Message |
jakeOSX Ninja
Joined: Aug 12, 2003 Posts: 1373
|
Posted: Tue Sep 14, 2004 8:25 am Post subject: |
|
do i need to email steve and remind him who you are? |
|
Back to top |
|
|
OPENSTEP The One
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
|
Posted: Tue Sep 14, 2004 8:37 am Post subject: |
|
I don't recall ever meeting The Steve. I've seen The Steve on stage right before he multiplied the loaves and fishes and fed the audience free iSights but I was one of the dammed and left to rot in the cold.
Perhaps The Steve or the minions of The Steve would donate licenses the moment I start putting Core Image to work doing slideshow transitions in Impress....
ed <--- has a todo list that's way too long |
|
Back to top |
|
|
jakeOSX Ninja
Joined: Aug 12, 2003 Posts: 1373
|
Posted: Tue Sep 14, 2004 9:06 am Post subject: |
|
well, i'll educate him then on the ed and the patrick.
OPENSTEP wrote: | Ied <--- has a todo list that's way too long |
i have these two foot by four foot post it notes that work great for things like that. |
|
Back to top |
|
|
OPENSTEP The One
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
|
Posted: Wed Sep 15, 2004 12:28 am Post subject: |
|
jakeOSX wrote: | i have these two foot by four foot post it notes that work great for things like that. |
ROFL
ed |
|
Back to top |
|
|
OPENSTEP The One
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
|
Posted: Wed Sep 15, 2004 12:37 am Post subject: Commits for Tuesday/WedAM |
|
OK, so I did another round of commits and changes based on Patrick's suggestions:
- VCLEventQueue to which a menubar's events are posted is passed in the VCLMenuBar constructor instead of the setFrame() method
- VCLMenu and VCLMenuItem now have dispose() methods and all dispse() methods for the NMF set their members to null and remove installed action notifiers. This should help the garbage collector clean these efficiently, which is important as they do have heavyweight peers.
ed |
|
Back to top |
|
|
OPENSTEP The One
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
|
Posted: Thu Sep 16, 2004 12:27 am Post subject: Keyboard shortcut fixes |
|
I just committed a few more revisions that should help clean up some of the issues with keyboard modifiers in the NMF.
1) Java 1.3.1 AWT has a bug where function keys cannot be used as keyboard shortcuts. Specifying a function key key code to the MenuShortcut for a menu item will result in the incorrect key being used (e.g. F7 in Hangul menu items was interpreted as "V"). The code now restricts any key codes used as shortcuts to be letters or numbers. We may need to expand this in the fiture as we find other keycodes that work properly.
2) Shift can now be used as a modifier for the shortcuts.
3) Shortcuts that require VCL's second modifier are discarded as AWT only allows the use of Shift as a modifier.
4) Shortcuts that do not use VCL's first modifier (control) are discarded as AWT always implicitly adds on "Command" modifier to menu shortcuts.
ed |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Thu Sep 16, 2004 5:26 am Post subject: Re: Keyboard shortcut fixes |
|
Ed,
OPENSTEP wrote: | 1) Java 1.3.1 AWT has a bug where function keys cannot be used as keyboard shortcuts. Specifying a function key key code to the MenuShortcut for a menu item will result in the incorrect key being used (e.g. F7 in Hangul menu items was interpreted as "V"). The code now restricts any key codes used as shortcuts to be letters or numbers. We may need to expand this in the fiture as we find other keycodes that work properly.
2) Shift can now be used as a modifier for the shortcuts.
3) Shortcuts that require VCL's second modifier are discarded as AWT only allows the use of Shift as a modifier.
4) Shortcuts that do not use VCL's first modifier (control) are discarded as AWT always implicitly adds on "Command" modifier to menu shortcuts.
ed |
I tried using Interface Builder to create a menu with a function key shortcut or a shortcut without the Command key. I could not create either so I think this is a Mac OS X limitation.
The good news is that even when you can't create such shortcuts, Neo/J still handles them properly via the window's key events. For example, F7 will still cause spellcheck to work. So maybe the simplest approach is to tack on the shortcut text to menu item name when the shortcut cannot be registered. For example, we would set Tools -> Spellcheck -> Check menu item to read "Check (F7)".
Also, with your latest changes, Command-Quit will properly shutdown Neo/J and the notoriously flaky Shift-Command-<Key> shortcut now works! Although, I think my existing hacks are causing such keys to be dispatched twice. I'll disable my old hack and see what happens.
Patrick |
|
Back to top |
|
|
OPENSTEP The One
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
|
Posted: Thu Sep 16, 2004 8:27 am Post subject: Re: Keyboard shortcut fixes |
|
pluby wrote: | I tried using Interface Builder to create a menu with a function key shortcut or a shortcut without the Command key. I could not create either so I think this is a Mac OS X limitation. |
Were you using Carbon or Cocoa? The command-key limitation is I believe in both, but I have memories of being able to do fkey shortcuts with Cocoa programmatically in the past. I haven't tried in IB myself.
pluby wrote: | For example, F7 will still cause spellcheck to work. |
Does it still function properly when the menubar itself is hidden (VisibleMenuBar() returns TRUE), and does it still function for the keystrokes involving the command key? I would expect the non-command-key ones to work while the menubar is hidden, but I'm not sure about the command key ones.
ed |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Thu Sep 16, 2004 9:00 am Post subject: Re: Keyboard shortcut fixes |
|
OPENSTEP wrote: | Does it still function properly when the menubar itself is hidden (VisibleMenuBar() returns TRUE), and does it still function for the keystrokes involving the command key? I would expect the non-command-key ones to work while the menubar is hidden, but I'm not sure about the command key ones. |
I changed menu.cxx so that mbDisplayable = FALSE (which hides the OOo menu) and I tested Command-F12, F7, and F11. All 3 still work.
Patrick |
|
Back to top |
|
|
OPENSTEP The One
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
|
Posted: Thu Sep 16, 2004 9:53 am Post subject: Re: Keyboard shortcut fixes |
|
pluby wrote: |
I changed menu.cxx so that mbDisplayable = FALSE (which hides the OOo menu) and I tested Command-F12, F7, and F11. All 3 still work. |
That's pretty cool. OOo users who are used to all of those Fkey shortcuts will still be able to use them. I don't think it's a problem not displaying them in the menus since FKey shortcuts are actually discouraged on the Mac...the FKeys may be sucked away by other system extensions. Expose comes to mind.
ed |
|
Back to top |
|
|
OPENSTEP The One
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
|
Posted: Thu Sep 16, 2004 9:55 am Post subject: Checkbox menu items functional |
|
I found my boneheaded logic error that prevented checkmarks for menu items from working. I was throwing the exception to invalidate the Java peer classes before I set the internal flag indicating the state has changed...so the state wasn't actually changing.
CVS update VCLMenuItemData.java and the checkmark states will be displayed and will now toggle properly.
ed |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Thu Sep 16, 2004 10:23 am Post subject: |
|
Looks good. I must say it looks pretty cool when I suppress the old menus and only show the native menus!
Granted, we still have some work to do, but I its nice to see that the general approach of Aquafying Neo/J is working.
Patrick |
|
Back to top |
|
|
sardisson Town Crier
Joined: Feb 01, 2004 Posts: 4588
|
Posted: Thu Sep 16, 2004 6:57 pm Post subject: Re: Keyboard shortcut fixes |
|
OPENSTEP wrote: | pluby wrote: |
I changed menu.cxx so that mbDisplayable = FALSE (which hides the OOo menu) and I tested Command-F12, F7, and F11. All 3 still work. |
That's pretty cool. OOo users who are used to all of those Fkey shortcuts will still be able to use them. I don't think it's a problem not displaying them in the menus since FKey shortcuts are actually discouraged on the Mac...the FKeys may be sucked away by other system extensions. Expose comes to mind. |
And PowerBooks. I have only two FKeys out of 12 free from *hardware* assignments, F11 and F12, and those I've dispatched to Exposé (plus a cmd-F11 for the third Eposeé function). Older PBs, and current ones without the backlit kybds have a few more available.
Between these sorts of things and Apple's system-wide reserved shortcuts and those many services grab, there aren't a lot of free shortcuts left for programs
Looking forward to seeing the fruits of these labors of Hercules of yours sometime in the future |
|
Back to top |
|
|
OPENSTEP The One
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
|
Posted: Fri Sep 17, 2004 12:48 am Post subject: Dimming problem located |
|
OK, I found the problem with the dimming not functioning properly. The problem seems to be related to how I'm doing the update in UpdateMenusForFrame(). Presently, I'm sending an Activate event to all of the VCL menus to invoke their activate links to populate and dim the menu. When the in-window VCL menus are used, though, each activate is implicitly paired with a deactivate. Once the deactivate is added in UpdateMenusForFrame() the dimming/enabling of cut/paste works again.
Unfortunately there are other errors that cause adding the deactivate to get the code to fail...these are the same that occur if you're going through the VCL menus with a mouse and result in the menus just getting truncated and null pointer exceptions getting thrown. I'm trying to track them down now, but have to get to sleep. I fixed one: apparently the String(String copyFrom) constructor can't take null as an argument (returns null by definitioon?) and needs to use String() to create an empty string. I addrsesed this in the constructor and in the setTitle() method. I now need to track down null exceptions coming from unregisterAllAWTPeers(). Once those are tracked down, hopefully the menu population code will function properly and not interfere with other actions or dimming functions.
ed |
|
Back to top |
|
|
pinolo Red Pill
Joined: Apr 05, 2004 Posts: 9
|
Posted: Sun Sep 19, 2004 3:11 am Post subject: Re: 1.3 Java |
|
wade1234 wrote: | The reason I ask the question is simply because eventually 1.5 will show up and at that point I really wonder if 1.3 will continue to be a available. |
I also understood in the past that 1.4 was necessary for scrollwheel support.
Which is my main concern, at he moment, about NO/J usability, also on a iBook where I use SideTrack for emulating scroll. I know, this could fall under "minor" problems, bur for anyone using a scr.wheel, it's annoying to use it in nearly every other app and automatically try to use it in NO/J, without luck. |
|
Back to top |
|
|
|