Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Nov 04, 2003 10:50 pm Post subject:
FYI, the setup executable will launch on 10.2/Jag according to the standard 1.1 setup procedure (see the setup thread for details). On 10.2 it exhibits the standard problems with the Neo VCL, such as virtual device flipping on scroll lists. It should be possible to complete it if you can wade through it with only the mouse.
It's only on 10.3 where windowing isn't functioning successfully.
Note this doesn't mean that the end product is anywhere near functional, but it's a phenomenal large first hurdle
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Nov 05, 2003 11:41 pm Post subject:
I just committed changes to config_office and to stlport. This should allow the source to compile on either 10.2.8 or 10.3 with gcc3. After searching through the default defines of the compiler and not seeing anything different except __VERSION__ (which can't be compared in preprocessor macros since it's a string) I propogated through the revision of the build operating system into environment variables. Note that this whole approach will probably fail if we ever get oru build system to the point where we can use the targeted header version feature of Xcode.
config_office now exports the major, minor, and revision numbers of the operating system into BUILD_OS_* environment variables in addition to the ENVCDEFS variable.
The changes to the stlport patch use these environment variables to determine whether to use the 10.2 custom wint_t definition or get it from 10.3 headers accordingly.
I've tested compilation on 10.3 and 10.2 with July gcc 3.3.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Nov 06, 2003 7:34 pm Post subject:
Ah, very true, I should do a clean checkout and build before declaring victory. My neo.src and resource tools were still compiled on 10.2.8, not on 10.3.
I committed a bit more of the Layout implementation, at least the parts that deal with string widths. These are now calculated and cached in the LayoutText method of SimpleATSLayout class, so that they don't have to be calculated at each call to text width functions.
I still don't like the text always being 8 pixels high, I didn't have time to find out where that's coming from, but I will.
After this, we need to fill out more of the layout implementation, deal with text runs (a Layout can have more than 1 text run and we need to lay all of them out I guess) and also with context. Currently the implementation grabs and caches only the part of the string to draw, we need to cache the whole string and then use offsets into that string instead of 0 to do our drawing.
All times are GMT - 7 Hours Goto page Previous1, 2, 3, 4, 5, 6
Page 6 of 6
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
