Posted: Wed Jan 12, 2005 6:05 pm Post subject: Help with NeoOffice/J build system?
Grrr. So I've made changes to vcl/inc/window.hxx and want to make sure that the OOo bits of the code pick up that change too. What do I have to do? How exactly do the NeoOffice/J-specific modules like vcl get merged into the actual OOo build process that's going on?
/Developer/ooo/neojava> source build/MacosxEnvJava.Set
/Developer/ooo/neojava> cd build/vcl
/Developer/ooo/neojava/build/vcl> build -P2
build -- version: 1.86.18.2
Checking dmake...
Running processes: 1
/Developer/ooo/neojava/build/vcl/source/unotypes
-------------
Running processes: 1
/Developer/ooo/neojava/build/vcl/source/window
/Developer/ooo/neojava/build/vcl/aqua/source/gdi
Running processes: 2
Nothing to build for GUIBASE java
Running processes: 2
/Developer/ooo/neojava/build/vcl/source/src
--- EXCEPTIONSFILES ---
-------------
dmake: Error -- `../../java/inc/svsys.h' not found, and can't be made
---* TG_SLO.MK *---
dmake: Error code 255, while making 'do_it_exceptions'
---* TG_SLO.MK *---
Killed
/Developer/ooo/neojava/build/vcl>
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Jan 12, 2005 8:05 pm Post subject:
What changes were made to window.hxx? Were there data layout changes or things that might affect the vtable? In general, with NeoJ we try to not change the memory layout or vtables of shared or base classes due to the propogation errors.
If things can be changed to be non-virtual and the data can be moved into the ImplWinData private structures (or over the placeholder mpDummy members...I don't think they're used) then we can keep all the changes in the corresponding neojava/vcl module and they should be automatically recognized by the other derived modules in neojava/. This helps with maintenance as it keeps the NeoJ modules binary compatible with ones that don't have any mods (and saves time since we don't have to rebuild OOo ).
If it really isn't possible to change things around and the memory layout or vtable really must be changed, then we'll have to start spinning patches against OOo to occur earlier in the build process.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Jan 13, 2005 8:12 pm Post subject:
Thx for the input. Adding Erase() will change the vtable for Window objects and derivatives. Correct me if I'm wrong, but I think that Window is also used as a base class for objects outside the VCL library and modules other then the ones we've overridden, so the place where we need to put it is in the pre-build patches. Is that correct?
I'd wait for Patrick to give a hideyho before committing any of this since I may not have a correct grasp as the best way to incorporate it into the build process. Here are my current thoughts...
1) Inject that header change for the new virtual function as one of the patches in:
neojava/patches/openoffice/vcl.patch
You should also give Erase() a default implementation in that patch to call the superclass. Essentially, this keeps the overall effect on the underlying patched OOo build "null" in the sense it has no functional difference but still allows all the OOo modules to link. The only reason for it there is to make sure all modules have the right vtables.
2) Create a derived "window.hxx" in the neojava/vcl/inc module. This is done by removing the symlink and replacing it with a physical file, then committing the new file into the repository.
3) In the derived "window.hxx", remove the default implementation.
4) "window.cxx" is already a derived file in neojava/vcl/source/window. I guess that's where you'd then implement the neojava-specific Erase() which will then call through to the corresponding native code in the vcl/java directory classes.
This type of system is more complicated then the regular OOo way of working, but it's wonderful in that it keeps patches against OOo itself to a minimum. That's one of the keys that's helped Patrick with maintainability and easy upgrading between versions, especially the bugfix point updates I'm pretty certain the changed vtable will require an actual OOo patch else link or runtime errors could occur.
We need a Window::Erase() since this is usually called for erasing window & control backgrounds and not other objects. Window::Erase() calls a SalFrame object's new PaintBackground() function, and passes the rectangle to be erased. The SalFrame::PaintBackground() function figures out the overall rectangle of the SalFrame, sets the clipping rectangle to be the rectangle to erase (but keeps the origin of drawing to be the origin of the frame, to get consistent background patterns), and calls the platform-specific PaintBackground function.
The reason we have to override OutputDevice::Erase() here is because that function simply calls DrawRectangle() with the current OOo background pattern, which is usually not what we want, and can't deal with Aqua bitmaps anyway really. In OutputDevice::Erase() we really don't know what type of Window we are, if we are a Window at all even.
Now if the AppearanceManager calls don't do what we need, we may have to try creating a BitmapEx with an actual Aqua BMP, which is what we did with NeoOffice I think? Anyway, I think this method should give us an OK background pattern too, as long as we can do clipping or something. In the end, if the clipping stuff doesn't work out like we want, we'll probably have to keep around a "shadow" bitmap that's the same size as the SalFrame, resize it when the frame size changes, and then copy from that to the window, basically faking our own clipping. It wouldn't really make sense to set a bitmap up and tear it down in each call of ::Erase(), so we'd probably have to keep it around.
If all else fails, perhaps we could really figure out if COL_TRANSPARENT will work as the OOo background pattern. I actually tried that, but the window turns up white anyway, which means we need to fill that with the Aqua pattern at some point no matter what.
That's the thought I had anyway.
Dan
(Window is actually the base-class for all controls and quite a few other things, like Dialogs, Toolbars, and whatnot. See:
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Jan 14, 2005 8:13 pm Post subject:
How about this:
The real bummer is the inline in outdev.hxx that makes Erase(Rectangle&) map straight to DrawWallpaper(). Instead of making Erase() virtual we could simply change the ImplDrawWallpaper (outdev6.cxx) and introduce a new virtual SalGraphics member for it. Since SalGraphics isn't used outside of VCL (is that still the case?) we wouldn't change any of the external binary interfaces for VCL for external modules but would be able to get access to the Erase() calls (inlined DrawWallpaper()). We could then do similar things for SetBackground() and trace when something actually is trying to install a custom wallpaper and keep track of that in the SalGraphics in the vcl/java implmentations. Then, if it's not custom, we could call through to the Carbon stuff instead, else punt to a normal implementation.
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
).