Compile errors on HEAD...and fixing them...

[fa]

Changes to scptools, scp, and instsetoo to fix up OpenOffice.org->NeoOffice and some instsetoo issues.

[Ed, scpzip.cxx had sizeof() in a couple places where MAX_PARAM should have been used...]

Everything should now compile and get built. Wheee!!!

Dan

[fa]

Hmm, our setup loader doesn't work at all and fails to unpack libsal.dylib.* and libjvmaccess. I moved the X11 loader over, stripped out the X11 stuff, and we'll try that. A bunch of stuff got improved over the old 1.0.3 loader.

[fa]

Committed a couple fixes to the loader, STLport was getting linked in even though it wasn't unzipped yet at runtime. It seems we link STLport to everything by default. I didn't turn that off because I didn't want to recompile, and it was easier to turn it off for just unzip and the loader.

I also stubbed out an implementation of ATSLayout, shamelessly ripped from the Win32 source code, so at least we've got a SalLayout child that we can play with at the moment. We need to get it to the point of drawing just a simple string so we can even install stuff (unless we use ./setup -net or something).

Dan

[fa]

Ok, I added enough code to the SimpleATSLayout class that it now draws stuff but doesn't actually do any layout. That simply means that it now acts much like the Toolbox routine DrawText and just draws text with no layout. Plus text size stuff isn't working very well so everything is teeny little 7 point or something. But Neo launches if you copy an install into NeoOffice/Contents/Resources and you can see stuff. You can even type, though fonts are screwed up. Layouts should help this since we will store the font in the layout(?) and fonts shouldn't cross layouts.

There's also some optimization we can do in the ATSUI stuff. Reading through ATS documentation, the combination of lower-level ATS functions and higher-level ATSU functions should enable us to reduce the number of font caches in-use and interface more directly with the VCL.

One more thing, for some reason Neo is actually responsive. Now there's a first.

Dan[/i]

[OPENSTEP]

Dude, back from vacation, and rock! am updating to compile now I don't think it's an issue if we link stlport to everything...IMHO STL is a powerful solution and I tend to use it in random places, so having it prelinked in will probably be necessary to begin with.

The performance improvement is most likely due to the fact a lot of the incredibly unoptimized ATSUI code was ripped out. I'm hoping that for round two I can do better, now that I know how to use it incorrectly The trick is to really aggressively cache the generated layouts, something that I'm hoping will fit very well into the SalLayout concept as I understand it. There wasn't too much room for persistence in text calls before, making caching layouts a bit of a pain.

The biggest performance hit was in writer. We essentially need to find a way to pass in whole paragraphs at a time to ATSUI and essentially let it draw a whole paragraph at a time and use its calculated line breaks for positioning, selection regions, etc. This will keep that same efficiency for us (generating a full ATSUI text layout object is an expensive operation, better in Panther, but still expensive) as well as ensure we can perfectly match metrics, context rendering, etc. of native apps using the Cocoa text engine or the Carbon methods. I haven't done enough research yet into the sw/edit engine code's interaction with the layout objects yet to see if the two models will be easy to mate, but of course will be starting

ed

[schlesi]

Hello,

did already someone have the time to take a look at the compiling-problems with STLPort and the gcc-3.3-build 1493?

I suppose, we'll have the problem with Panther's gcc-version, too.

Thomas

[OPENSTEP]

Unfortunately I haven't had time yet to look into the August gcc version, and my main machine is stuck on July tools. I'm going to probably get the ability to do so before the end of the week once I can update my test partition.

The bad thing is that if it's affecting stlport for Neo, it'll also break OOo's stlport as well. I'll get back to you when I have some details to report.

ed

[Guest]

Hi,

I got panther installed with the 7B85 dev tools, which include 1493. I did have issues with STLport that I had to patch, but those were all related to "wchar_t" support and "wint_t" support. I thought that only Panther had wchar support and so this would only be an issue on Panther. I didn't see any of the "toupper" errors that you posted here on page 1...

Can you try to compile again, and then email me the build log from the start of compilation of dll_main.c until the end? fa [at at] openoffice [dot dot] org

I'll try to look into it further. Worst comes to worst I can whack my June dev tools and install the August ones. I've got them somewhere.

Dan

[schlesi]

Hi,

thanks to Dan's STLport-patch I get rid of my posted issues on 10.3. After spending several hours in fixing my corrupt cvs-bases source code I decided to download it completely new. Now the building stops here:

[OPENSTEP]

I'm the dude I think that last touched neo.src. I'll see if I messed it up when I get back, but haven't tried a clean checkout build yet on 10.3. I may not have checked in my changes, but I did get past it on 10.2, never tried hitting it yet on 10.3.

ed

[OPENSTEP]

No, Dan's the one that got the neo.src fixed. My local checkout has revision 1.2 of offmgr/source/offapp/intro/neo.src, and that ABOUT_FTXT_COPYRIGHT doesn't appear to have any problems.

Can you try copying the "ooo.src" file from the same directory on top of the "neo.src" file and see if it compiles successfully? The neo.src file is what decides the splashscreen, the product name, about text, etc.

ed

[schlesi]

Ed,

your workaround did it. But here's the next stop:

[Guest]

That means the build finished Seriously. Its done.

[schlesi]

Ok, then we can say: NeoOffice does compile on "Jaguar" and on "Panther" successfully

Thomas

[jakeOSX]

ok, so how much longer do i have to hold my breath to find out what that means?

-j