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 - Help with NeoOffice/J build system?
Help with NeoOffice/J build system?
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
fa
The Architect
The Architect


Joined: May 27, 2003
Posts: 88

PostPosted: 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>

(same thing when sourcing MacosxEnv.Set too)
Back to top
OPENSTEP
The One
The One


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

PostPosted: 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 Smile ).

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.

ed
Back to top
fa
The Architect
The Architect


Joined: May 27, 2003
Posts: 88

PostPosted: Thu Jan 13, 2005 9:35 am    Post subject:

Ed,

Specifically, adding a member to the Window class to override the OutputDevice::Erase() functions, which are virtual.

Dan
Back to top
OPENSTEP
The One
The One


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

PostPosted: 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 Smile I'm pretty certain the changed vtable will require an actual OOo patch else link or runtime errors could occur.

ed
Back to top
fa
The Architect
The Architect


Joined: May 27, 2003
Posts: 88

PostPosted: Fri Jan 14, 2005 7:41 pm    Post subject:

The thought is this:

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.

On OS X, that happens to be, AFAICT, DrawThemeModelessDialogFrame() (see http://lists.apple.com/archives/hit-developers/2000/Nov/msg00015.html). This should draw a consistent background pattern in the window.

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:

http://gsl.openoffice.org/files/documents/16/974/VCLClassHierarchyWindows.sxd
http://gsl.openoffice.org/files/documents/16/975/VCLClassHierarchyControls.sxd

that resulted from a really frustrating night trying to figure this sort of shit out Smile
)
Back to top
OPENSTEP
The One
The One


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

PostPosted: 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.

Thoughts?

ed
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Page 1 of 1

 
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.