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 - Future direction brainstorming...
Future direction brainstorming...
 
   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: Wed Jul 23, 2003 11:28 pm    Post subject: Future direction brainstorming...

Howdy there! While right now my computer is occupied compiling (not NeoJ, unfortunately! Man, I need more then one computer to timeslice) I figured I'd jot down a few ideas of where I'd be interested in pushing NeoJ. Patrick...any of these sound like a good idea? Any sound completely crackheaded?

Note: I'd not poke at any of this c*** until after I look at/help with/bang my head against printing & debugging first Smile This is like "NeoJ 2.0" style brainstorming...

1) Migrate NeoJ to build off of Neo source base, no major changes. This requires some work on the Neo source base to get a stable X11 build out of the Neo repository. Since Neo's ignored X11, this is somewhat of an issue.

2) Migrate NeoJ to OpenOffice.org 1.1. The difficulty here, like for Neo, will be vertical and right-to-left text. It'll probably be easier in NeoJ, however, since there's already awareness of foreign language input methods from the VM.

3) Investigate in-place "marked text" editing. This basically would be exploring whether it's possible to do marked text in the OOo framework. The way the OOo VCL is structured, similar changes to text display and access will need to be made for both Neo and NeoJ. I'm just basically thinking it might be easier to do in NeoJ first Smile

4) Use new Unicode and document context APIs from Panther in Neo and NeoJ. This will add support for advanced input methods.

5) Investigate Java VM support for context-sensitive text rendering. It appears to me right now that the "adaptive" font rendering of Quartz is not available to the Java VM in any OS X version...example, typing in Apple Chancery in TextEdit vs. NeoJ, Opera (or other Carbon apps such as NeoFY...NeoIG and TextEdit change the final/beginning letter as typing occurs). This is key for full Arabic support. I think other languages may also require it...thai?

6) Use Ximian icons in NeoJ. Requires adding alpha blending to NeoJ VCL.

7) Get NeoJ compiling and running on other platforms!

8 ) Adopt the control rendering abstractions of Neo into NeoJ. Map abstractions onto Swing or other toolkit. Use to provide a "GTK" look for other users, or whatever. Essentially...beginnings of Aqua in NeoJ as well.

9) See if we can adopt an AWT or a Swing peer for the menubar, the quintessential Mac OS X pet peeve Smile

10) Is it faster to use cocoajava to get Neo implemented, or pure Cocoa?

11) Side-by-side adoption of other Neo technologies that hopefully I'll get time to do like grammar checker and Jaguar/Panther address book integration.

Thoughts? Other ideas on where to take NeoJ?

While I think NeoJ is a necessary and incredibly useful step for the Mac platform, I can easily see it becoming a foundation for a better visual interface and feature set for other platforms as well, such as Linux, Solaris, and Win32.

ed
Back to top
schlesi
Oracle


Joined: Jun 07, 2003
Posts: 234
Location: near Cologne, Germany

PostPosted: Thu Jul 24, 2003 10:10 am    Post subject: Is NeoOffice (Aqua) died?

Hi Ed,

is the development of NeoOffice/OpenOffice (Aqua) paused and NeoOffice/J the "main product" now?

My personal priority wish for NeoOffice(/J) would be an "aquafied" user interface.

Thomas
Back to top
OPENSTEP
The One
The One


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

PostPosted: Thu Jul 24, 2003 10:58 am    Post subject:

No, the Aqua stuff isn't paused...I just haven't had time to work on it in a while (been doing more OOo stuff, like support).

The goal of NeoJ is to provide a non-X11 version that's stable. It'll probably be stable before an Aqua version, so offers a good intermediate step for OS X users without the hassle of X11.

Anything to do with Aqua and OpenOffice.org, though, is at least a year and a half away...we've been declined permission to do any Aqua work in 1.1 and would have to target 2.0, which hasn't even really started yet.

ed
Back to top
Guest






PostPosted: Thu Jul 24, 2003 6:13 pm    Post subject:

I also haven't had that much time to work on Neo + Aqua. However, its still very much what we are going to do. I've been occupied with getting OOo 1.1 building with gcc 3.3 on OS X 10.2, and when that is working, we'll begin moving NeoOffice over to OOo 1.1 (its at 1.0.1 now), and some real work with Aqua controls can start. Not that we haven't done it already, but the framework Ed's talking about in (Cool above can happen only with 1.1 really.

Dan
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Jul 24, 2003 7:53 pm    Post subject:

I agree with Ed and Dan: NeoOffice/J won't replace NeoOffice. It might appear that NeoOffice/J is sucking effort away from NeoOffice's Aqua port, but I can assure you that this is not the case.

I originally created NeoOffice/J because I knew that Ed and Dan had a lot of work to do to make OOo fully Aquafied and I couldn't stand using X11 on a Mac. However, I am an old Unix hack and the whole set of MacOS Carbon and Cocoa APIs is fairly new to me. So, I thought that I'd apply my experience in Java as a way to work around my lack of knowledge in this area.

The benefit of having NeoOffice/J is that we can all apply our different skill sets and then borrow code from each other. For example, I borrowed the default font code from NeoOffice and I am sure that NeoOffice will borrow much of the installer code from NeoOffice/J.

I think NeoOffice/J will be supplanted by the Aquafied NeoOffice soon enough and that is to be expected. So why keep NeoOffice/J around if it is really only an intermediate product? My hope is that NeoOffice/J can, eventually, provide the same intermediate transition from OOo to a fully native look and feel for other Unix platforms. My bet is that after people see the Aquafied version of NeoOffice in the next year or so, many will want to do the same. However, many Unix developers (like myself) find writing X11 code about as fun as pulling your teeth out with a set of pliers and no pain killers.

Hope that clears things up,

Patrick
Back to top
OPENSTEP
The One
The One


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

PostPosted: Thu Jul 24, 2003 9:09 pm    Post subject:

I agree with Patrick's assessment, Dan's statements, etc. I didn't intend to freak folks out posting a brainstorming list in the slightest Smile Basically, here's the rub...

While NeoJ may be an intermediate step for OS X, there are a number of reasons for it to stay around. Some users (a minority of Mac users, but a majority of IT departments) will want to keep around a version of OOo that runs on OS X and looks identical to OOo on other platforms. Usually they are trying to try and pass off some kind of total cost of ownership figure onto management and want to reduce support and training costs.

The other one is because it rocks right now on OS X, and there's no reason why it couldn't rock on solaris, linux, Win32, your massively overclocked Yopy, what have you. NeoJ has applications way far beyond OS X.

Like Neo is a Mac OS X specific port, NeoJ is a Java specific port. Unlike Neo, which will only be able to target OS X in its "pure" form, NeoJ can target anywhere that Java can. This is why I think it has more of a future then its immediate addressable needs portend.

So...all that aside...anyone have thoughts on the brainstorming for NeoJ?

ed
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Jul 24, 2003 9:55 pm    Post subject:

Ed,

I was really interested in your comments about font ligature. I have been tinkering with Java text rendering all day and I found that not only do none of the Java2D text rendering classes (GlyphVector and TextLayout) add the necessary font ligature on Mac OS X, but I found that Sun's Solaris JVM does not do this either.

Apparently, we are responsible for converting all of the Unicode characters into their respective ligature or composite characters before we construct the GlyphVector or TextLayout instance.

I have heard that OOo 1.1 is using the ICU software (http://oss.software.ibm.com/icu/) to do this text layout process. I am familiar with ICU. However, I have not tried their text layout engine as it is only available in their C++ distribute (sorry, no Java version yet).

Could this be why OOo 1.1 has an ICU cvs module now? If so, I guess this is one thing that may motivate me to move NeoJ up to OOo 1.1. After all, ICU is fairly thorough and is platform independent.

Patrick
Back to top
OPENSTEP
The One
The One


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

PostPosted: Thu Jul 24, 2003 10:22 pm    Post subject:

From what I know, 1.1 is using ICU for conversions, and may be using it for ligatures and the like. The extent to which I am aware of this is that Panther may or may not include a version of ICU in its libraries, but this version of ICU may or may not be available to external developers.

I am famaliar with the issue more from an abstract perspective (in that, yes, OOo now includes ICU's source code...like python...like gtk2...) but the details still escape me. I've been busy with 1.0.x for so long that I've not been able to examine precisely how 1.1 uses ICU. This will change, of course....hopefully by the weekend when I can finally get rid of my last *essential* gcc2 based build Wink

ed
Back to top
Max_Barel
Oracle


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

PostPosted: Fri Jul 25, 2003 1:59 pm    Post subject:

OPENSTEP wrote:
Anything to do with Aqua and OpenOffice.org, though, is at least a year and a half away...we've been declined permission to do any Aqua work in 1.1 and would have to target 2.0, which hasn't even really started yet.

Sorry to barge in with a slightly off-topic question. I just want to know WHO refused the permission to work on the Aqua port with the current version of OOo and why?
I never understood the way such a big thing like the OOo is managed. I don't ask for a complete answer. Just want to know if you are really prevented to work (legal issue?) or if it's a cooperative choice to synchronize different ports.
Should we now (volunteer beta testers) begin to play with the OOo/J version?
Back to top
OPENSTEP
The One
The One


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

PostPosted: Fri Jul 25, 2003 10:18 pm    Post subject:

Well, OOo/J won't happen anytime soon due to licensing issues (we're GPL, OOo has that SISSL thing hanging around). As to who refused what on the Aqua stuff, well...

The second part to the story is that the "1.1 point release" unresolved listing was replied to by Hamburg as an emphatic "no, that's not an open talking point"



From: Edward Peterlin <ed@dashboardbuddha.com>
Date: Thu Jul 17, 2003 9:16:09 AM US/Pacific
To: Michael Meeks <michael@ximian.com>
Cc: Matthias Huetsch <matthias.huetsch@sun.com>, "Kevin.Hendricks" <kevin.hendricks@sympatico.ca>, Thorsten Behrens <thorsten.behrens@sun.com>, Stephan Schaefer <s.schaefer@sun.com>, Dan Williams <dan@bigw.org>
Subject: Minutes for 7/16/03 VCL meeting

I first wanted to start off by saying thank you for everyone on the call. I think it was a good starting point for lots of discussion topics and hope it continues! What follows are a typed copy of my "minutes", well, actually rough transcriptions of the dialogue. I unfortunately don't know shorthand, so these were as fast as I could transcribe. I may be missing important things, so please fill in as necessary. I also generally really abbreviated my statements since I wasn't writing while I was talking.

ed

** Ximian VCL Concall 7/16/03

On call: Michael (M), Dan (D), Ed (E), Hamburg (H...apologies, i was unable to pick out voices over the international line. Feel free to sub in your initial if you recall which is yours Smile.

* VCL 3 modifier patch:

H: Had been looked at and postponed for 2.0 -> evaluated as a change in the document format.
D: Does it change the basic document format?
M: The problem is not hte technical detail, but that it was declined in Feb. It is now July.
H: Matthias proposed that it be postponed until 2.0 and there was no objecection.
D: What is the timeline for 2.0?
H: 1 1/2 years from now.
D: From now? For a consumer ready release or for beta?
H: Consumer, hopefully.
E: At what point will VCL be done in this cycle?
D: At what point is the 2.0 VCL useful enough that 1.1 is no longer maintainable?
H: 2.0 would piggyback on top of existing VCL code until the applications are migrated.
...
M: We got sidetracked into deadlines. The issue is what happens with patches we develop today.
H: A patch developed today will not be valid one year later.
M: ....
E: Right now it's more efficient as a developer to work outside of the tree rather than bringing patches into the tree.
H: We can't bring in patches just before feature freeze.
M: We need to stick with a stable base for users and apply these external patches right now in a separate tree.
H: Is it guarded by ifdefs? (e.g. "safe" code?)
M: It would be better to have patches in OOo CVS, even if guarded by ifdefs? ...
H: Confused.
D: What part of the file format is modified?
H: The XML file format changes for modifiers as what gets output by VCL. This is included in svx, svw, etc.
M: Can we put in anything that doesn't change the file format?
E: Not quite that simple...without changing the file format there's no way to retain any new keybindings that are made.
H: These are new ideas coming up that we should look at. I (?) don't want to have incompatible patches that go into 1.1 It still needs to read the old file format.
M: To get resolved quickly - is it OK to have 3-key compiled for Mac only?
H: It is acceptable as long as it is compatible.

** RESOLVED: 3-key can go into 1.1, only for Mac platform, only if it is compatible. Punt for other Unicies.


* VCL Design/Refactoring

M: VCL 2.0 is a long term thing and probably won't materialize in a year and a half. Are you interested in doing the refactoring yourself our would you like us to help you?
H: Refactoring should fit into a larger picture.
M: What is the picture in question? Some things completely need refactoring. Example: everything inheriting from OutputDevice.
H: Underway is a separation of GUI and application, so refactoring any fundamental outputdevice stuff is useful.
M: Can you communicate where you want to go clearly so we can helP?
H: I think that hte next year the guys here will develop like crazy. We should do this as a joint effort. The main question we have is whether to put effort into cleaning up the existing VCL or into getting the application into a better state. It may be more useful to focus on abstracting the main application and APIs between it and VCL.
E: Would the design of the API be done in Hamburg only, or would it be a joint effort?
H: The API is up for discussion. We already decided that we want to include your Aqua stuff into the main product.
E: Can we be sure that the discussion on APIs won't stop there?
H: The intraapplication API is something we need soon. What we (H) should not do is develop a long proposal and just drop the API out there. We tried to start design, but the problem is that we stopped the discussion. It stopped because we were bugfixing...no secret discussions. It will take management to get the discussion started and keep it going.
M: No worries

** RESOLVED: It would be useful for external community members to begin refactoring VCL on a low level, as it is not in conflict with 2.0 design goals at this time.


* Layout System

M: Very important in native platform widget rendering, internationalization. Native platform widgets need a specific amount of size.
H: We plan to do something in this area an dchanging the VCL in some way. The biggest problem is that there are many dialogs.
E: Needed outside of dialogs (buttons & tabs within main windows)
M: It's really useful everywhere.
H: Think of controls during dialog resizing and relayout. Can we many any progress on helping solve these issues?
M: Getting four weeks to spend on layout issues. Any possibility of coordinating with Hamburg UI designers?
H: We'd need a proof of concept.
M: Each dialog will need to be changed and checked to make sure they don't do their own internal relayout of widgets when they're resized or moved. Any idea how many may do that?
H: Not many.
D: Would layout introduction be incremental?
M: Yes.
D: Will you use the existing VCL?
M: Yes.
D: What would be the resource file format?
M: Would like to use existing XML file format of GTK, but could also use a new file format.
H: From a technical point of view, the resource stuff should be refactored as well. Resources are heavily coupled to translation, so strings need to be stored in a way that continues to work with the translation tools.
M: Conceptually the layout is separate.
H: There are two types of resources: binary resource and the text resource. The toolchain depends on teh text file -> if we could keep that it would be useful; keep and extend the files.
M: Planning on extending the resource files, perhaps with a new text section. Generally are you happy with the idea?

(general agreement)

D: I'm interested in learning of any problems that you find in the process. Could you document your progress?
M: Yes

** RESOLVED: Layout infrastructure is a good thing and all of Michael's work would be welcome!


* Native Widget Rendering

D: We would like to get native widget rendering into 1.1 and not wait until 2.0.
M: We'd also be shipping layout stuff based off of 1.1. It would be nice to have another point release.
E: This would be nice to test infrastructure and get it bug-free for 2.0.
H: How would you do native widget rendering in 1.1?
E: We would extend the 1.1 VCL with the Draw*Control style API.
H: We'd not want to integrate that into 1.1.
D: 1 1/2 years is simply not acceptable. The changes will be somewhat invasive.
H: It's OK to do it as a VCL patch for 1.1
D: It's more invasive then just the VCL module.
H: We don't want platform specific code in 1.1. It's not feasible/maintainable to scatter platform specific code throughout the source for Mac, GNOME, etc.
M: I don't see having Mac code for all controls side by side as necessary. What you're asking for is a refactoring.
D: Some controls are outside of the VCL and need to be addressed, however.
E: Example: Rulers are in toolkit/sv* but need custom work to adjust backgrounds, ruler thumbs to match Aqua, etc.
D: If we gave the control list to you guys, could you help in the refactoring?
H: VCL controls should be fine, but not other libraries. Sounds like a 2.0 change.
M: They're offering help, would you be happy getting our existing code into 1.1 and postpone a cleaner API until 2.0?
D: Can we commit a hack to 1.1 and then do it nicely in 2.0?
E: ... (I said something, didn't write it down...)
D: If the abstractions can be hacked into 1.1, there's no point.
H: It seems like doing it in 1.1 and 2.0 would be duplicating work.
E: We need to do this in order to hit our timeframes, hoping for 6 months to release.
H: No problem doing conditional code for Mac. We wouldn't like it, but it could be done. We're looking for a better solution from you guys.
D: We agree, but it looks like the better solutions are only happening in 2.0.
M: What are any ideas around having an extra point release?
H: We may continue to do patch releases to 1.1, but no more minor releases are planned until 2.0.
D: With native control changes pushed into 1.1, we could get an OS X native version out based on 1.1.
M: Can we potentially do the abstraction right and get it into 1.1?
D: I think that wouldn't be possible.
M: Woul dyou be happy to have a in-VCL control rendering abstraction within VCL only for a point release?
H: Yes

** TALKING POINTS: Point release for 1.1...is it acceptable? Native controls need to modify more then just VCL.


* Alpha Blending

M: I want to preface this with the fact that this is not my code. Since we can't be sure if the X server can do alpha blending, we composite 32 bit icons numerically in client and blend to the background color.
H: For toolbars isn't that a fill bg color?
D: Some of the 32 but support is also needed by the Mac version. Underneath, the Mac is using 32 bit alpha for its images.
M: Have you guys looked at the alpha blending code?
H: No. What's the scope? Is it invasive to other code?
M: It's not native alpha blending.
H: so the only problem is that icons are not alpha blended.
M: Yes, that's what we solved.
H: What's the other issues?
M: I want the patche to be moved upstream from its current state. Right now you need to second guess the background of the widget in the icon rendering code.
D: We can't even guarantee it'd be a color. OS X uses textured backgrounds.
H: Did you consider compositing on screen?
M: You can if you're using XRender. But if you're rendering OOo it's a lot of icons and can take a long time and network transfers.
H: Can you render the whole area at once?
M: That works well for toolbars, but not for buttons. There are some windows that have lots of icon buttons.
H: We're using XRender for the font rendering.
M: The concern is remote rendering with that solution.
H: On a LAN it should be acceptable.
M: Are you happy with that requirement? We weren't happy with imposing the bandwidth requirements for icons.
H: Well, there are two solutions. You could use XRender if it's there, or you could composite on a widget by widget basis and push it to the server. Render widgets into VirtualDevices on the client.
M: We'll look into that solution. So the proposed method is to render into a VD and blit?
H: Again needs an abstraction in the VCL to put controls into VD. It may be bad, but may be an appropriate solution. Other thoughts: Win32 cursor compositing, Chinese and Japanese versions do compositing on the server.
M: Would you be willing to provide a platform independent blending API?
H: Not for 1.1.
M: Is it OK to do the XRender enabled thing if possible for 1.1?
H: Have you looked into XFT2?
M: I haven't. Isn't XFT2 for text?
H: It now has an interface for general image compositing. It may be more efficient then XRender.
M: I'd like OOo to use the Ximian icons and want to do it in 1.1, but we need the alpha blending. I'd be satisifed if we can do the work in 2.0 and backport it into 1.1.


Ending questions:
* talked a bit about vendor branches --> side workspaces
* 1.1 point release? Is this possible?
** UNRESOLVED
* Do we need a follow-up phone meeting?
** RESOLVED: we've got enough to go on, let's stick with e-mail for now.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Sat Jul 26, 2003 5:59 pm    Post subject:

To get back on topic, I have been looking at how to implement complex text layout (ligatures, etc.) into NeoJ. The good news is that I found that Java 1.4 has the following new method: java.awt.Font.layoutGlyphVector().

This method is identical to the Font.createGlyphVector() method that NeoJ current uses to convert an array of characters into a drawable glyph vector. The only difference is that on Mac OS X, this new method does all of the complex text layout that Font.createGlyphVector fails to do.

I tested this method out with the infamous "fi" string in English, the "y" at the end of an Apple Chancery string, and a set of Arabic characters and in all three cases the appropriate liguratures (or embellishments in the case of Apple Chancery) were drawn.

I already have implemented the dynamic switching between the two methods based on Java version. However, I have not checked it in yet as I found an interesting thing when I tried to test the code: NeoJ runs with Java 1.3.1 even if you have Java 1.4.1 installed!

The reason for this is buried in Apple's Java 1.4.1 documentation. Basically, the OOo code loads the JVM with the "Java 1.2" parameter. In this case, Apple will load the 1.3.1 JVM. In order to load the 1.4.1 JVM, you need to use the "Java 1.4" parameter. I have implemented code in stoc/source/javavm that tries to load with 1.4 parameter and, if that fails, tries to load with the 1.2 parameter (no 1.3 parameter exists).

I have not checked this fix in because there are some problems with NeoJ when the 1.4.1 is used. Specifically, the JVM blocks when it tries to load any java.awt.* classes. After many runs of gdb, it appears that the problem is that there is no CFRunLoop running and it appears that the JVM now starts the java.awt.* event loop by posting events to the CFRunLoop.

Anyway, the fix appears to be that I have to invoke the com.apple.cocoa.application.NSApplication.run() method to start the CFRunLoop before I try to load any java.awt.* classes.

When I have this committed, I will post an update with the list of cvs modules that you will need to rebuild.

Patrick
Back to top
OPENSTEP
The One
The One


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

PostPosted: Sun Jul 27, 2003 9:50 am    Post subject:

Another alternative to picking which java version to launch is to point it directly at the desired java version (e.g. /System/Library/Frameworks/JavaVM.framework/Versions/1.4.1/Commands/java), or you could do a search in Versions to detect whether 1.4.1 was installed, use that, else fallback. I'm not sure of the specific 1.4 flag you're mentioning, but I do recall that the 1.4.* bundle property for Java apps would cause the app to not launch on machines that had 1.3.1.

As to the need for a run loop, that honks...the VM should really instantiate one if it needs it. I'd say file that as a bug for Apple Smile They moved from Carbon based implementatioons in 1.3.1 to Cocoa based implementations for 1.4.1. This introduced quite a bit of snafus.

Do you have access to the "DP102" Java update on ADC? I think it's up for general availability and Java testing. It's fixed a couple VM bugs in my project at work and might be good to test against.

ed
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Jul 28, 2003 7:33 pm    Post subject:

Ed,

The flag that I mentioned is the define in the jni.h header in JavaVM.framework/Headers. The stoc/source/javavm/javavm.cxx file uses the JNI interface (specifically, the JNI_CreateJavaVM() function) to load an instance of the JVM in the same process as NeoJ (and OOo as well). I have check in a neojava/stoc/source/javavm directory and the javavm.cxx now calls JNI_CreateJavaVM() with 0x00010004 as the version. If that fails (because you don't have a 1.4 JVM on your machine, I invoke JNI_CreateJavaVM() with 0x00010002 as the version. Previously, only 0x00010002 was used.

The good news is that I can now start NeoJ with Java 1.4.1 on my Mac OS X 10.2 machine. I was able to load the Cocoa framework and invoke its NSApplicationMain() function in salmain.cxx. I found that the reason Apple does not create the event loop in Java 1.4.1 is that the event loop absolutely must be in the main thread Sad. In Java 1.3.1, the event loop is created in a new thread when the first java.awt.* class is loaded. Anyway, in the main() function, I now load Cocoa, create a new thread, execute SVMain() in that thread, and then get the NSApplicationMain() function pointer and invoke it in the main thread.

I have not committed this code yet because I have some threading issues. With Java 1.4.1, NeoJ crashes immediately after the main window appears in a native Java method. My guess is that I am disposing something before Java 1.4.1 expects me to. It is a pain, but I will find it.

The only thing that I don't like is that I need to use NSApplicationMain() instead of invoking Cocoa code directly. This is because if you compile and link VCL to the Cocoa framework with Java 1.3.1, the Font.layoutGraphicsVector() method does not do the complex text layout. NSApplicationMain is a C function so I can load the symbol dynamically and avoid linking against the Cocoa framework. This is not a hassle, but NSApplicationMain requires that a nib file be in your application package. So, I will dump one in when I get all of the bugs ironed out.

Patrick
Back to top
OPENSTEP
The One
The One


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

PostPosted: Mon Jul 28, 2003 11:07 pm    Post subject:

If you're calling NSApplicationMain() directly, you may also need to set up your own autorelease pool on the main thread. Can you get away with calling [NSApp run] directly? I think that'd allow you to get by without a nib file, e.g.:

Code:
 
 // main.mm
 
 int main(int argc, char **argv);
 {
     // ... jvm setup wizadry ...
 
     [[NSAutoreleasePool alloc] init];
     [NSApp run];
 }


I'm not sure if you can do that style of invocation via dynamic symbol lookup, however...but it should avoid the need for a nib.

Cocoa apps hate having any event stuff done on other threads aside form the main thread...I found that the hard way. There are other internal non-thread-safe Cocoa calls, but I don't think you'll have to worry about them. You should also be wary of doing things with Cocoa in ways that don't call NSApp run or NSAppliactionMain...Neo doesn't use these properly, and voila, updates to Cocoa may break it. I'm sure the cocoa guys hate folks who desire to program with the framework but don't adhere to the Cocoa view of the world (or can't).

ed
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Jul 29, 2003 3:18 pm    Post subject:

Ed,

Thanks for the hint. I found that the Objective-C runtime uses a C interface. I created the following Objective-C source file and, if I dynamically load the Cocoa framework and link libvcl against -lobjc, the following code works and does not need to be linked against the Cocoa framework:
Code:

#import <salmain_cocoa.h>
#import <objc/objc.h>
 
void RunCocoaEventLoop()
{
    id nNSApplication;
    id nNSApp;
    SEL pSharedApplication;
    SEL pRun;
 
    // Invoke [NSApplication sharedApplication]
    nNSApplication = objc_getClass("NSApplication");
    pSharedApplication = sel_getUid("sharedApplication");
    nNSApp = objc_msgSend(nNSApplication, pSharedApplication);
 
    // Invoke [NSApp run]
    pRun = sel_getUid("run");
    objc_msgSend(nNSApp, pRun);
}

I also think I know why my code is crashing in Java 1.4. The pattern that I am seeing is that the crashes happen when Java code is invoked by SalInstance::Yield(). This method is now *not* in the main thread. Since the crash seems to happen at a different event in SalInstance::Yield(), I am guessing that an event dispatched by SalInstance::Yield() is doing some drawing or window manipulation just when the Cocoa event loop is touching the same object. This is consistent with your experience with Cocoa.

To fix this, I am probably going to need to rework my NeoJ event dispatching so that SalInstance::Yield() delegates all timer processing and event dispatching to the Cocoa event dispatcher since the Cocoa event dispatcher. This is not hard, just very tedious.

What a pain! Sad

Patrick
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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.