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 - Development plans for 2005 (and maybe 2006)
Development plans for 2005 (and maybe 2006)
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Jun 13, 2005 8:10 am    Post subject:

FYI. Getting a Mactel box is only one small part of the effort. The big limitation is developer time. The OOo code has some hairy assembler code and, based on my experience with Apple's version of gcc, there will be many new bugs so moving Neo/J to Mactel is not going to be a simple recompile.

Patrick
Back to top
Guest






PostPosted: Mon Jun 13, 2005 10:20 am    Post subject:

Would it make sense to set up a second donation link, just for the Developer kit?
Back to top
ovvldc
Captain Naiobi


Joined: Sep 13, 2004
Posts: 2352
Location: Zürich, CH

PostPosted: Mon Jun 13, 2005 10:57 am    Post subject:

As I am (I think) still supposed to liason with the OOo community: Shouldn't we put this roadmap on the dev@porting list?

I might please them that a switch to Java 1.4 and Cocoa is on the way. If properly worded, it should also let them know they have time to do a good version of 2.0 and we'll be looking forward to work with the fruits of their hard labour.

_________________
"What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Back to top
OPENSTEP
The One
The One


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

PostPosted: Mon Jun 13, 2005 10:13 pm    Post subject:

Well, if nothing else, someone should probably let them know that any Java based UNO components will be incompatible with the Rosetta emulator on Intel machines. This will kill JDBC, Base (if the implementation is still in Java), some of the Wizards, etc. for any PowerPC compiled OOo 2.0 X11.

It's exactly the same for both NeoJ and OOo X11...neither of them wil be able to run in the emulator Sad

ed
Back to top
ovvldc
Captain Naiobi


Joined: Sep 13, 2004
Posts: 2352
Location: Zürich, CH

PostPosted: Tue Jun 14, 2005 9:25 am    Post subject:

OPENSTEP wrote:
Well, if nothing else, someone should probably let them know that any Java based UNO components will be incompatible with the Rosetta emulator on Intel machines. This will kill JDBC, Base (if the implementation is still in Java), some of the Wizards, etc. for any PowerPC compiled OOo 2.0 X11.


So we're joined at the hip, as always..

But I assume the Intel version will have a JVM and libraries and be able to run at least some Java code, given recompiling or compiling to byte-code only?

Maybe you could make a post to the dev@porting list to announce what you think this all means to NeoOffice and OOo porting. I don't think I can formulate it precisely enough to be of use, but something should be sent out. Preferably in an encouraging tone, because they're having enough trouble as it is...

_________________
"What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Back to top
sardisson
Town Crier
Town Crier


Joined: Feb 01, 2004
Posts: 4588

PostPosted: Tue Jun 14, 2005 10:30 am    Post subject:

I saw something at one point on dev@porting about Florian having been at WWDC; I wonder how much talking with Apple folks he was able to do about these issues?

Smokey

_________________
"[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Back to top
H'ik
Guest





PostPosted: Wed Jun 15, 2005 4:57 pm    Post subject:

Doesn't GCC4 run on Darwin/X86?

If so, at least some X11 development can be done for x86 processors. I would not know whether Neo/J could be compiled that way.

Testing Neo/J would still be impossible though...
Back to top
Guest






PostPosted: Wed Jun 15, 2005 7:21 pm    Post subject: Delgation?

Patrick,

There are four major programming efforts listed in your parent post. That sounds like simply too much work for two part time developers. Which bits of this do you think can be sanely delegated?

My naive outsider viewpoint suggests to me that step 1: Java 1.4.x can only be done by you (and Ed?); it's too low-level for anyone who didn't do the original Java 1.3.x work. The second step, Aqua widgets and dialogs, looks doable by other people. On the other hand, it looks like the most fun job out of the four! The third step, OOo 2.0 should be delegated to anyone who offers (and it's nice to see some support from OOo for the platform finally, which should help getting an X11 version out sooner). The fourth step - MacIntel - sounds like it's so difficult that you can't even make a plan for it yet. I don't pretend to understand the details of how a UNO bridge works, but it does sound like Sun and OOo went out of their way to make things difficult (Assembler????? Are we living in the 1970s?).

Cheers, Phil

PS the more I think about an OOo virtual machine layer acting inside a Java VM, the more amazing I find it that Neo is fast and responsive on my 3 year old Powerbook.
Back to top
sardisson
Town Crier
Town Crier


Joined: Feb 01, 2004
Posts: 4588

PostPosted: Wed Jun 15, 2005 10:04 pm    Post subject: Re: Delgation?

Anonymous wrote:
There are four major programming efforts listed in your parent post. That sounds like simply too much work for two part time developers. Which bits of this do you think can be sanely delegated?


Part of the problem--Ed and Patrick can fill in the details--is that there just are not enough people with the skills and experience needed to do the jobs, if they could be delegated. In the history of Mac OOo, four people have done all the major lifting (not little "fix the build" patches, but "stop Writer from crashing" or "people really want to print" or "new compiler version, we need new UNO bridges"): Patrick, Ed, Dan, and Kevin Hendricks. By the time OOo 2.0.x for Mac OS X (X11) finally makes it into the hands of end-users, there might be another name to add to that list, but for now...

The Java suff is clearly at the core of Neo/J, so that's Patrick. "Back in the day" Patrick had his own little "Marklar" project going, where some of the Neo/J 0.x builds also built using Java 1.4.x (which is how Patrick learned how buggy Java 1.4.x was!). We're a world away from 0.x now, but possibly some of that work can be useful/reused (and who knows; Patrick never said he stopped doing builds with Java 1.4.x, he just stopped mentioning them)....

Ed and Dan are the only two Mac programmers who've done native widget stuff (and they invented/prototyped the N*F stuff). Some of the KDE-OOo folks have done N*F stuff since then, but they won't be interested in Neo/J. I don't know how complex this is, but it ultimately still requires someone who can at the very least get OOo to build....

As for OOo 2.0, first we have to wait for OOo 2.0 to get released and become stable on the Sun-supported platforms and then wait for a stable Mac OS X release (and in just my little bit of playing around with the 1.9.xxx builds, it'll be a while yet to match the functionality of 1.1.2).

At any rate, Patrick's roadmap is sort of like two steps each with two threads running in parallel (although there's a hidden third thread, OOo 2.0 Mac OS X X11, too): Patrick moves to Java 1.4.x and Ed adds widgets, roughly in parallel (or maybe not?) and potentiallu something similar in the 2006 year....

Or something like that. Maybe I should just let Ed and Patrick answer themselves and put my nose back to the Press Kit grindstone.... Smile

Smokey

_________________
"[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Back to top
fabrizio venerandi
Guest





PostPosted: Thu Jun 16, 2005 1:45 am    Post subject:

btw: waiting for Oo 2,0 x11, pluby said he work for a more aqua felling in gui. I'm asking: could be done a 'code-optimization' for more speed?
I don't know if neo could be compiled using g4 or g5 peculiarity (like altivec) but sure I prefer a faster neo with x11 icons, that aqua felling with a slow neo Wink

It is only a curiosity about the pluby possibility of work from this side of the code (java and carbon).


thanks.



f.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Jun 16, 2005 12:11 pm    Post subject:

fabrizio venerandi wrote:
btw: waiting for Oo 2,0 x11, pluby said he work for a more aqua felling in gui. I'm asking: could be done a 'code-optimization' for more speed?
I don't know if neo could be compiled using g4 or g5 peculiarity (like altivec) but sure I prefer a faster neo with x11 icons, that aqua felling with a slow neo Wink


What you suggest isn't going to happen. G4, G5, Altivec, etc. isn't going to make a difference because Java does all of the drawing. We don't compile Java, Apple does. Also, some of the slower drawing operations are slow because Java is buggy (e.g. XOR drawing), not because the Neo/J code is unoptimized.

Hopefully, Java 1.4.x will provide some improvements in speed, but then I won't be surprised if there is no difference.

Patrick
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Jun 16, 2005 1:04 pm    Post subject: Re: Delgation?

sardisson wrote:
Part of the problem--Ed and Patrick can fill in the details--is that there just are not enough people with the skills and experience needed to do the jobs, if they could be delegated. In the history of Mac OOo, four people have done all the major lifting (not little "fix the build" patches, but "stop Writer from crashing" or "people really want to print" or "new compiler version, we need new UNO bridges"): Patrick, Ed, Dan, and Kevin Hendricks. By the time OOo 2.0.x for Mac OS X (X11) finally makes it into the hands of end-users, there might be another name to add to that list, but for now...


For those that haven't contributed code to an open source project, there is a de facto process that most projects use when new developers show up. New developers are expected to show their ability to work in the code by submitting patches for build problems and existing bugs. Once the existing developers (in our case Ed and I) feel confortable that the new developer knows what they are doing, then commit access is usually granted.

This isn't a perfect process, but it generally proves to be an effective means for determining which potential developers will most likely be valuable, self-sufficient code contributors. This is especially true for OOo and Neo/J since, when developers first find out how much effort it takes to make a small change in the OOo code, most are no longer interested.

sardisson wrote:
The Java suff is clearly at the core of Neo/J, so that's Patrick. "Back in the day" Patrick had his own little "Marklar" project going, where some of the Neo/J 0.x builds also built using Java 1.4.x (which is how Patrick learned how buggy Java 1.4.x was!). We're a world away from 0.x now, but possibly some of that work can be useful/reused (and who knows; Patrick never said he stopped doing builds with Java 1.4.x, he just stopped mentioning them)....


Every once in a while I turn on loading of Java 1.4.x to see what happens. Unfortunately, Neo/J just crashes with Java 1.4.x because I haven't implemented any of the Java-to-native code for font handling. Back when fonts used to work, however, printing did not work. So I clearly have some work ahead of me.

sardisson wrote:
At any rate, Patrick's roadmap is sort of like two steps each with two threads running in parallel (although there's a hidden third thread, OOo 2.0 Mac OS X X11, too): Patrick moves to Java 1.4.x and Ed adds widgets, roughly in parallel (or maybe not?) and potentiallu something similar in the 2006 year....


This is pretty accurate. I was planning on getting the most obvious missing Java 1.4.x pieces coded and then putting out a test patch for testers. Then, while testers are finding lots of Java 1.4.x bugs and when I'm not fixing those bugs, Ed and I will be working on implementing the native widgets.

Patrick
Back to top
OPENSTEP
The One
The One


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

PostPosted: Thu Jun 16, 2005 10:59 pm    Post subject:

FWIW, most developers don't make it past the compile phase. Some that can are stuck there forevermore; the deluge of code from Hamburg makes maintaining compilability a full time job Smile

There is a definite lack of skills on the project, that's true. But Patrick is right. Open source is a fiefdom, and we've chosen a "trial by fire" approach. I agree with it because I spent many, many hours, vacation time, and money trying to recruit developers for OOo X11 for years. Most who even try to compile get it to compile and then drop off the face of the earth. It sucked up a *lot* of my time. But...

The "trial by fire" admission has many benefits. First, it shows that a developer is motivated enough to pursue something even in the face of adversity. Second, it proves a willingness to try and solve tough problems to which no one else may know the answer or have time to investigate. Third, fixing breakages, even in the build process, is a great way to get exposed to the internals of a project. Heavens know I didn't learn what I know of OOo's structure from any type of "developer's bible" posted along with Sun's source code...I had to learn it all myself, and the primary way I learned was through fixing build failures and bugs. The same approach is often taken in the real world where the first task a new developer has on the job is bug fixing, especially if they're green out of college. It's common practice in the real world, so it makes sense to apply it to OSS as well.

So anyway, if you're trying, keep it up and don't give up. We're spread so thin that we don't have time to be anyone's guide, so you may have to find your own way...but fame and fortune and women await you at the end of your quest.

Oh wait...

(goes back to cooking his hamburger helper and shooing away the homeless)

ed
Back to top
fabrizio venerandi
Guest





PostPosted: Fri Jun 17, 2005 6:10 am    Post subject:

Thank you for the answer. After the great pluby and ed work, I only have few bugs in neooffice that I hope before or late will fall in patrick butterfly net.
Now the main problem here (I'm talking about a normal office work) is definitely the speed and the memory, and I'll be curious to see if the moving from java 1.3.1 to 1.4 could help this issue.


have a nice day


f.
Back to top
Florian Heckl
Guest





PostPosted: Wed Jun 22, 2005 2:43 am    Post subject:

sardisson wrote:
I saw something at one point on dev@porting about Florian having been at WWDC; I wonder how much talking with Apple folks he was able to do about these issues?


Hi Smokey, all,

yes, I was at WWDC. But I used my chances to talk to Apple engineers to solve some of the other issues we are currently having, mainly with Java (which they helped me solve).
As I knew gcc4-compatibility is a requirement to run natively on Mactel boxes I tried to first compile the 2.0 codebase with gcc4 out of the new Xcode 2.1 (so far unsuccessful) before approaching one of the lab machines. Sorry, I know I should have at least tried to run it in the Rosetta environment. Sad
But I do hope too that somehow we will get access to one of the DevKits.
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
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.