Hey, no problem. I was just trying to make sure I understood what you were saying. My german sucks, and as always I never know which case to apply in a situation and which article to use in that case. At least German isn't as bad as Latin, with like 36 different forms of each verb.
In any case, I think I may end up installing XCode on my Panther partition to check out your problem, because I'm fairly sure the newest XCode comes wtih the August dev tools. Not sure when I'll get to that though (have to download it first).
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Oct 11, 2003 8:18 pm Post subject:
Committed two more changes to vcl to get the compile going along further. In inc the salwtype.hxx file used a C++ type bool in one of its structures, which causes breakages in C annd ObjC files. Also comitted a fix to source/control/button.cxx Quartz code to add in a parameter for CheckBox::ImplDraw() that was added in 1.1.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Oct 12, 2003 12:55 pm Post subject:
Update: the entire contents of vcl/source should now compile. The build should now fail in the aqua implementation of OutputGraphics due to new 1.1 interfaces (vcl/aqua/source/gdi/salgdi.cxx).
Errors were fixed in outdev3.cxx and floatwin.cxx. Additionally, I moved the Cocoa menubar code back into menu.cxx since it's now an ObjC++ file. This gets rid of the separate menu_macosx.mm file and should improve maintainability (it made more sense to put Cocoa code into the 1.1 menu code rather then apply 1.1 changes to the .mm file)
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Oct 12, 2003 6:36 pm Post subject: vcl now compiles, doesn't link...
I just committed changes to salgdi.cxx, salmathutils.cxx, source/app/settings.cxx, and util/makefile.mk so now the entire module compiles. It does not link yet. Some of the link errors are due to build system problems that I don't comprehend. It seems to be producing two copies of object files:
Code:
ld: multiple definitions of symbol _VCLEvent_StartPeriodicEvents
../unxmacxp.pro/slo/vclevent.o definition of _VCLEvent_StartPeriodicEvents in section (__TEXT,__text)
../unxmacxp.pro/slo/VCLEvent.o definition of _VCLEvent_StartPeriodicEvents in section (__TEXT,__text)
ld: multiple definitions of symbol _VCLEvent_StopPeriodicEvents
../unxmacxp.pro/slo/vclevent.o definition of _VCLEvent_StopPeriodicEvents in section (__TEXT,__text)
../unxmacxp.pro/slo/VCLEvent.o definition of _VCLEvent_StopPeriodicEvents in section (__TEXT,__text)
ld: multiple definitions of symbol _gVCLEventMSTime
../unxmacxp.pro/slo/vclevent.o definition of _gVCLEventMSTime in section (__DATA,__common)
../unxmacxp.pro/slo/VCLEvent.o definition of _gVCLEventMSTime in section (__DATA,__common)
ld: multiple definitions of symbol _gVCLTimerEnabled
../unxmacxp.pro/slo/vclevent.o definition of _gVCLTimerEnabled in section (__DATA,__data)
../unxmacxp.pro/slo/VCLEvent.o definition of _gVCLTimerEnabled in section (__DATA,__data)
dmake: Error code 1, while making '../unxmacxp.pro/lib/libvcl645mxp.dylib'
Worse off were the changes in salgdi.cxx...
In the process of getting rid of compilation errors, I got to examine headers and find that Hamburg changed the entire VCL text system for 1.1!!!! All of the old text drawing calls are gone. We need to do some serious research into how their wonk-ass SalLayout system works so we can complete the text system.
This VCL change breaks both Neo and will make porting NeoJ to 1.1 difficult as well. We won't be able to link future modules in the compile until we can at least get a full implementation of OutputDevice (and probably this strange SalLayout object). I'm going to research more into this and try to at least provide empty stubs.
Fucking Sun. Why in the hell is their code not subject to engineering reviews or documentation requirements or at least the consideration that their work breaks the work of other volunteers?
I don't know if this helps, but about a month ago I built OOo 1.1 using my NeoJ build system. Of course, the build crapped out as soon as it finished OOo 1.1 and started on my custom code. Nevertheless, at the time I glanced at the salgdi*.cxx files to see if there was any massive changes.
I saw the new SalLayout changes. However, when I looked at the header that defines SalLayout, it looked damn similar to the java.awt.font.TextLayout class. The TextLayout class in Java is merely a fancy class that contains the string that drawn plus a whole bunch of formatting information (e.g. LTR or RTL, vertical or horizontal, etc.).
My gut instinct when I saw this was that the code in the SalGraphics text methods basically moves to a matching SalLayout method. The only changes (at least initially) would be to use the draw the SalLayout's string. Initially, you should, hopefully, be able to ignore all of the new formatting data until you have time to handle it.
Of course, this is still a pain in the ass and I will have to do the same damn thing for NeoJ.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon Oct 13, 2003 11:22 pm Post subject:
OK, Dan committed the fixes to add stubs for some of the new classes and I just committed the stubs for SalGraphics (sorry for the delay Dan!) so now VCL will compile and link. To get something useful, of course, we need to fill in the new text system and the other parts of the interface I've been ranting about, but in the meantime mad compilation bug fixing can commence
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Oct 14, 2003 12:08 am Post subject:
I committed a change for the toolkit module. A file in there, vclxwindows.hxx, had an incorrect type for the throw() clause of its acquire() function (a type was specified in the throw clause when it should be empty). This caused a compile error, now fixed.
The compile shall continue as I go to sleep, just in time to fail five minutes after I lie down. Trying to leave it alone breaks it every time
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Oct 14, 2003 12:38 am Post subject:
Hehe. Can I call it or what. Got up from bed to go to the john and, lo and behold, build stopped.
Committed four bitmaps to the res module that were somehow missing from the list of new 1.1 files I created. Apparently they may have been added between RC3 and RC4. This fixes a build error in svtools of bmpmaker aborting due to missing bitmaps.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Oct 14, 2003 10:36 am Post subject:
Latest update: I just committed a change in setup2 to remove a duplicate definition of UnixOS::GetDateTime. One of the libraries, libmig, isn't linking in the module, though. It's failing to find common functions, which could either be a sign they're missing from the libraries themselves.
Must go to work no, but will look more when I get home since baseball is in the afternoon today (!@@$@!@!).
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Oct 14, 2003 8:14 pm Post subject:
I just committed another patch to the setup2 module to fix some incorrect syntax in the makefile for source/custom/moffice that was either a misapplied patch or a change in syntax from 1.0.x. The setup2 module now should build successfully.
The build continues while chinese food is en route...
I filled in an implementation for SalGraphics::GetGraphicsWidth(), and did some research on the other functions. Turns out the only ones we really have to implement are:
1) the bezier curve functions
2) GetDevFontSubstList
3) GetTextLayout
The rest of the functions are either not needed, or are used only by the builtin PDF writer implementation, which we can supplant with OS X's print to PDF functionality (or Save As PDF when printing).
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
