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
OPENSTEP
The One
The One


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

PostPosted: Sat Sep 11, 2004 11:33 pm    Post subject: Initial commit of NMF AWT implementation

OK, after a long time coming I finally felt "good enough" about it to commit the first version of the NMF AWT implementation to HEAD. (acronym decoding .... NMF = Native Menu Framework, AWT = Java AWT). Commit message follows:

Code:


Initial commit of the native menu framework AWT implementation.  The basic
structure is in place and menus are being created properly but a number of
issues still need to be addressed:

-- Similar to the Cocoa NMF implementation, the AWT menus are not updated in
real-time by the VCL code to propogate changes to menu item names, enabled/
disabled state, and dynamic menu contents in realtime.  VCL relies on receiving
"menu about to be displayed" events to trigger updates, but AWT menus cannot
generate these events.  A "heartbeat" thread still needs to be added to
continually trigger updates for the frontmost frame.

-- VCLAWTCheckboxMenuItems do not seem to be fully functioning as exceptions
are being thrown in checkItem().  Unsure if this is a result of the above or
not.

-- The LINK between the AWT menu item and the underlying VCL item is non-
functional unless the VCL menu (in-window menu) has been made visible prior to
selecting the item from the native menu.  The addition of the "hearbeat" thread
should remove this synchronization bug.

-- In-window menubars are still visible (e.g. VisibleMenuBar() still returns
FALSE).  This was consciously done to continue to allow for further debugging
and manually triggering menu synchronization between the two environments
until the "heartbeat" thread is in place.

-- The extent of object leakage due to the force regeneration of menubars on
realtime class morphing is unknown.

-- Has not been tested with the most up-to-date Alpha 2 sources and may result
in crashes.

Edward Peterlin
OPENSTEP@neooffice.org

Checking in java/com/sun/star/vcl/VCLEvent.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLEvent.java,v  <--  VCLEvent.java
new revision: 1.19; previous revision: 1.18
done
Checking in java/com/sun/star/vcl/VCLFrame.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLFrame.java,v  <--  VCLFrame.java
new revision: 1.88; previous revision: 1.87
done
RCS file: /cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenu.java,v
done
Checking in java/com/sun/star/vcl/VCLMenu.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenu.java,v  <--  VCLMenu.java
initial revision: 1.1
done
RCS file: /cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenuBar.java,v
done
Checking in java/com/sun/star/vcl/VCLMenuBar.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenuBar.java,v  <--  VCLMenuBar.java
initial revision: 1.1
done
RCS file: /cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenuItemData.java,v
done
Checking in java/com/sun/star/vcl/VCLMenuItemData.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenuItemData.java,v  <--  VCLMenuItemData.java
initial revision: 1.1
done
Checking in java/com/sun/star/vcl/makefile.mk;
/cvs/neojava/vcl/java/com/sun/star/vcl/makefile.mk,v  <--  makefile.mk
new revision: 1.8; previous revision: 1.7
done
Checking in java/inc/salframe.h;
/cvs/neojava/vcl/java/inc/salframe.h,v  <--  salframe.h
new revision: 1.9; previous revision: 1.8
done
Checking in java/inc/salmenu.h;
/cvs/neojava/vcl/java/inc/salmenu.h,v  <--  salmenu.h
new revision: 1.2; previous revision: 1.1
done
Checking in java/inc/com/sun/star/vcl/VCLEvent.hxx;
/cvs/neojava/vcl/java/inc/com/sun/star/vcl/VCLEvent.hxx,v  <--  VCLEvent.hxx
new revision: 1.7; previous revision: 1.6
done
RCS file: /cvs/neojava/vcl/java/inc/com/sun/star/vcl/VCLMenu.hxx,v
done
Checking in java/inc/com/sun/star/vcl/VCLMenu.hxx;
/cvs/neojava/vcl/java/inc/com/sun/star/vcl/VCLMenu.hxx,v  <--  VCLMenu.hxx
initial revision: 1.1
done
RCS file: /cvs/neojava/vcl/java/inc/com/sun/star/vcl/VCLMenuBar.hxx,v
done
Checking in java/inc/com/sun/star/vcl/VCLMenuBar.hxx;
/cvs/neojava/vcl/java/inc/com/sun/star/vcl/VCLMenuBar.hxx,v  <--  VCLMenuBar.hxx
initial revision: 1.1
done
RCS file: /cvs/neojava/vcl/java/inc/com/sun/star/vcl/VCLMenuItemData.hxx,v
done
Checking in java/inc/com/sun/star/vcl/VCLMenuItemData.hxx;
/cvs/neojava/vcl/java/inc/com/sun/star/vcl/VCLMenuItemData.hxx,v  <--  VCLMenuItemData.hxx
initial revision: 1.1
done
Checking in java/source/app/salinst.cxx;
/cvs/neojava/vcl/java/source/app/salinst.cxx,v  <--  salinst.cxx
new revision: 1.68; previous revision: 1.67
done
Checking in java/source/java/VCLEventQueueEvent.cxx;
/cvs/neojava/vcl/java/source/java/VCLEventQueueEvent.cxx,v  <--  VCLEventQueueEvent.cxx
new revision: 1.9; previous revision: 1.8
done
RCS file: /cvs/neojava/vcl/java/source/java/VCLMenu.cxx,v
done
Checking in java/source/java/VCLMenu.cxx;
/cvs/neojava/vcl/java/source/java/VCLMenu.cxx,v  <--  VCLMenu.cxx
initial revision: 1.1
done
RCS file: /cvs/neojava/vcl/java/source/java/VCLMenuBar.cxx,v
done
Checking in java/source/java/VCLMenuBar.cxx;
/cvs/neojava/vcl/java/source/java/VCLMenuBar.cxx,v  <--  VCLMenuBar.cxx
initial revision: 1.1
done
RCS file: /cvs/neojava/vcl/java/source/java/VCLMenuItemData.cxx,v
done
Checking in java/source/java/VCLMenuItemData.cxx;
/cvs/neojava/vcl/java/source/java/VCLMenuItemData.cxx,v  <--  VCLMenuItemData.cxx
initial revision: 1.1
done
Checking in java/source/java/makefile.mk;
/cvs/neojava/vcl/java/source/java/makefile.mk,v  <--  makefile.mk
new revision: 1.10; previous revision: 1.9
done
Checking in java/source/window/salmenu.cxx;
/cvs/neojava/vcl/java/source/window/salmenu.cxx,v  <--  salmenu.cxx
new revision: 1.2; previous revision: 1.1
done
Checking in source/window/menu.cxx;
/cvs/neojava/vcl/source/window/menu.cxx,v  <--  menu.cxx
new revision: 1.3; previous revision: 1.2
done


In terms of design, I hope that the javadoc comments can mostly explain it, but if not, here goes...

The NMF abstracts menus and menubars into two primary constructs: a menu item (with associated text, shortcut, image, etc.) and a menu (a list of menu items). Java AWT, unfortunately, has four different classes to which these correspond: MenuBar, Menu, MenuItem, and CheckboxMenuItem (a menu item with a check...probably implemented due to Motif).

The majority of the menu and menu item handling code is in a class named VCLMenuItemData. Instances of this class hold the information provided by the NMF for use in constructing menu items. Each individual instance may have one or more AWT "peers"...that is...AWT objects that are the realizations of the VCL objects. The "peer" naming was chosen since it's quite similar to how the individual AWT object has its own underlying heavyweight native object to implement it.

During the course of runtime usage of the VCLMenuItemData objects, it may be the case that the class needed to implement their peers changes. An example of this is when a menu item gets its first checkmark set. Its AWT peers need to be promoted from a MenuItem to CheckboxMenuItem objects. If an operation performed on an object results in a need for one of these morphings, the method will throw an AWTPeersInvalidatedException to signal that all of the peers and anything dependent on the peers for that object needs to be regenerated. Currently the regeneration is "pessimistic"...one of these exceptions will trigger a regeneration of every MenuBar taht has been instantiated for frames.

The other tricky case is when submenus are associated with menus. In the VCL world, submenus are actually two objects; a SalMenuItem conveys the title and enabled state of the submenu and a SalMenu conveys the contents of the submenu. In the world of Java AWT, the Menu object is itself a MenuItem; the menuitem and its associated submenu are one and the same. In the VCLMenuItemData object, this is achieved through use of delegate objects. Each VCLMenuItemData object may have a delegate that can respond to its methods (similar to ObjC delegate objects). When a submenu is attached to a menu item, the submenu's VCLMenuItemData is filled with the title and enabled state of the associated item and then the submenu object becomes the item's delegate. The implication of this is that submenus that are shared between multiple entries are presently required to have identical titles and enabled states. Submenu sharing is expected to be a rare case between top-level menus of an individual frame, so on Mac OS X this limitation shouldn't be a problem.

Other then that, the full implementation isn't done yet...some type of "heartbeat" thread still needs to be added in order to synchronize native menus with their VCL counterparts on a regular basis (see commit message). I'm just anxious to get this out there and to have a backup copy of the code and a reason to extract the tricky parts of the design to something other then the whiteboard sitting behind me Smile

ed
Back to top
wade1234
Guest





PostPosted: Sun Sep 12, 2004 11:21 am    Post subject: Awesom

That is awesome Ed...I just read in the NeoOffice posts that you were woirking on the menu items and now I read Neo/J and you have done serious work towards that goal...

Very impressive! I cant wait for this to be fully implemented...this is a huge step towards the true native look/feel of a Mac app.
Back to top
OPENSTEP
The One
The One


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

PostPosted: Sun Sep 12, 2004 6:12 pm    Post subject: Second round of commits

After consulting with Patrick, I ditched the heartbeat thread approach which could potentially bog down the application a bit too much. I implemented a new routine, UpdateMenusForFrame(), which will dispatch appropriate VCL events to synchronize the native menus with the correct contents and enabled state of VCL.

Since Java doesn't allow us to trap menu display before the actual menu is shown (just like Cocoa) keeping things in sync is an issue. Right now there is an UpdateMenusForFrame() invocation in the VCLEvent::dispatchEvent() method as per Patrick's suggestion. Unfortunately this doesn't synchronize in all cases, specifically cases where the state changes as a result of an operation that doesn't generate an event (e.g. right after a selection drag of text is finished). We need a better solution. Patrick suggested trying to trap the menu display through Carbon events which will work for at least Java 1.3.

In short, the native menus are now much more immediately functional then they were before and refresh correctly each time a window is brought to the front Smile

The second commit was to add a "synchronized" keyword to member functions of the Java menu classes that made AWT calls. Patrick pointed out that this will be safer when menus are used in a VCL world where thread safety is assumed and it's undetermined which thread will be handling what.

There are several problems that remain. The updating of items, of course, is crucial. The second problem is that the keyboard shortcut code is currently only working for raw keys and is not allowing modifiers to be used. As a result, the same shortcut is sometimes accidentally used for multiple items (see Command-V in Writer). CheckboxMenuItems also still seem to be smoking crack.

ed
Back to top
OPENSTEP
The One
The One


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

PostPosted: Sun Sep 12, 2004 6:18 pm    Post subject: Commit logs

For anyone doing concurrent work other then Patrick (is there anyone? if not then there should be...):

Code:

Checking in VCLMenuBar.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenuBar.java,v  <--  VCLMenuBar.java
new revision: 1.2; previous revision: 1.1
done
Checking in VCLMenuItemData.java;
/cvs/neojava/vcl/java/com/sun/star/vcl/VCLMenuItemData.java,v  <--  VCLMenuItemData.java
new revision: 1.2; previous revision: 1.1
done
Checking in inc/salmenu.hxx;
/cvs/neojava/vcl/inc/salmenu.hxx,v  <--  salmenu.hxx
new revision: 1.2; previous revision: 1.1
done
Checking in java/inc/salframe.h;
/cvs/neojava/vcl/java/inc/salframe.h,v  <--  salframe.h
new revision: 1.10; previous revision: 1.9
done
Checking in java/source/java/VCLEventQueueEvent.cxx;
/cvs/neojava/vcl/java/source/java/VCLEventQueueEvent.cxx,v  <--  VCLEventQueueEvent.cxx
new revision: 1.10; previous revision: 1.9
done
Checking in java/source/window/salframe.cxx;
/cvs/neojava/vcl/java/source/window/salframe.cxx,v  <--  salframe.cxx
new revision: 1.54; previous revision: 1.53
done
Checking in java/source/window/salmenu.cxx;
/cvs/neojava/vcl/java/source/window/salmenu.cxx,v  <--  salmenu.cxx
new revision: 1.3; previous revision: 1.2
done


I do not presently have CVSWeb available, but hopefully can install it in the next server upgrade.

ed
Back to top
OPENSTEP
The One
The One


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

PostPosted: Sun Sep 12, 2004 6:34 pm    Post subject: Re: Awesom

wade1234 wrote:
this is a huge step towards the true native look/feel of a Mac app.


Patrick also was of that opinion and so I chose to tackle this first. It's also the most complicated of any of the "N*F" porting since it's the only one that actually uses native widgets. Events from the Java AWT need to be mapped and translated into VCL and vice versa.

All of the other Native Widget Framework (NWF) stuff simply involves drawing...the event handling is done within the upper level and no mappings need to be written. Only things like "draw me something at this point on the screen that looks like a scrollbar should". There never really is an actual scrollbar.

For menus, though, we do actually have the native menus themselves to contend with. So hopefully it's the most complicated...if this can work, the steps to buttons, scrollbars, and whathaveyou should be a piece of cake (comparatively)

ed
Back to top
sardisson
Town Crier
Town Crier


Joined: Feb 01, 2004
Posts: 4588

PostPosted: Sun Sep 12, 2004 7:17 pm    Post subject:

Very cool! Very Happy I didn't understand most of the technical stuff (and can only AppleScript my way out of a paper bag on a good day; I'm in awe of Terry's Start OpenOffice.org), but it sounds like NeoJ is really rolling towards blue-button-land now! Smile

Thanks again for all the great work, guys!

Smokey
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Sep 13, 2004 8:13 am    Post subject: Re: Second round of commits

Ed,

OPENSTEP wrote:
Since Java doesn't allow us to trap menu display before the actual menu is shown (just like Cocoa) keeping things in sync is an issue. Right now there is an UpdateMenusForFrame() invocation in the VCLEvent::dispatchEvent() method as per Patrick's suggestion. Unfortunately this doesn't synchronize in all cases, specifically cases where the state changes as a result of an operation that doesn't generate an event (e.g. right after a selection drag of text is finished). We need a better solution. Patrick suggested trying to trap the menu display through Carbon events which will work for at least Java 1.3.


In case you see this forum first, you need to add a call to UpdateMenusForFrame() in SalInstance::Yield(). There is one place in that method where I invoke SalFrame::Flush() on each window just after the painting timer is executed. This is where you want to add UpdateMenusForFrame().

Patrick
Back to top
wade1234
Guest





PostPosted: Mon Sep 13, 2004 5:58 pm    Post subject: Java version...

Hey are you guys planning on using 1.4.2 Java? I have to say that the performance is great for the latest version....Especially the latest version on the apple developer site. It has fixed all issues that I have seen.

Wondering what version you are using? 1.3 or 1.4? Might help alot of you r performance problems.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Sep 13, 2004 7:26 pm    Post subject:

Java 1.4 will not be used anytime soon. Neo/J is not a simple Java application and, as a result, there are a lot of low-level interaction with the JVM. All of this low-level code would need to be reimplemented for Java 1.4 (a lot of work) since Apple switched to Cocoa in Java 1.4.

Patrick
Back to top
OPENSTEP
The One
The One


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

PostPosted: Mon Sep 13, 2004 9:10 pm    Post subject:

As an additional on-thread example of why it's 1.3 for the time being is the menu select stuff. The most promising solution to everything is to try and trap menu display requests through Carbon Events. Unfortunately Cocoa doesn't offer any equivalent potential solution for the menu synchronization problem.

While yes, there's the fair share of Java involved, there are definitely many non-Java aspects to it (ATSUI, Carbon, etc.) that also have their own code that needs to change when things move to 1.4.

ed
Back to top
OPENSTEP
The One
The One


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

PostPosted: Mon Sep 13, 2004 9:37 pm    Post subject: Re: Second round of commits

pluby wrote:
In case you see this forum first, you need to add a call to UpdateMenusForFrame() in SalInstance::Yield().


OK, I inserted the menu synchronization there as suggested. It turns out that the state is still incorrect. It's a more fundamental issue then synchronization, however: the state of the "Cut" toolbar button is also incorrect at the present time. When a selection is made, the button isn't activated immediately...rather the activation of the button is postponed until it's clicked. So after all that the menu update stuff may be barking up the wrong tree. I'll look more and try to figure out what's missing or if it's an actual OOo 1.1.x flaw.

ed
Back to top
wade1234
Guest





PostPosted: Mon Sep 13, 2004 11:06 pm    Post subject: 1.3 Java

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. Apple seems to have like to drop older versions than support them. When I say available I am mainly refering to Tiger. Looking forward I think that you guys would like to limit the amout of rewrites that you need to do so that is why I asked the question. Seems the answer is that Carbon in 1.3 is needed! I just hope that something does not change that leaves us with nothing eventually.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Sep 13, 2004 11:22 pm    Post subject: Re: 1.3 Java

wade1234 wrote:
I just hope that something does not change that leaves us with nothing eventually.


Don't worry, we'll hack together the necessary changes to upgrade JVMs when 1.3 becomes obsolete. But until then, it's a fairly low priority. After all, the amount of Java that we use decreases over time. For example, when I upgraded Neo/J to the OOo 1.1.2 codebase, I ditched using Java to render text and now use the Mac OS X native ATSUI APIs since they are much more suited for complex text layout than Java is.

Patrick
Back to top
wade1234
Guest





PostPosted: Tue Sep 14, 2004 1:56 am    Post subject: awesome!

Sometimes I really wonder why I get concerned....you guys do an excellent job and are always on top of things!!
Back to top
OPENSTEP
The One
The One


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

PostPosted: Tue Sep 14, 2004 8:04 am    Post subject:

FWIW I am actively continuing to do cursory checks and tests on Tiger to make sure Neo/J (and OOo) are still functional. As of now there are no issues. My seeding key runs out in October, though, so I unfortunately will no longer be able to check and will miss checking the final Tiger releases Sad

ed
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Goto page 1, 2, 3  Next
Page 1 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.