OpenOffice.org Summer of Code Projects...

[LemonAid]

Here is some interesting information.

OpenOffice.org Summer of Code Projects

Notice these items:

# 12 Porting

* 12.1 Porting: Integrate the native Mac OS X FilePicker into OpenOffice.org (Aqua/X11)
* 12.2 Porting: Integrate OpenOffice.org help into Mac OS X help center (Aqua/X11)
* 12.3 Porting : Mac OS X Address book integration (Aqua / X11)
* 12.4 Porting: Implement native font support, using native Apple API (Aqua / X11)
* 12.5 Porting : Mac OS X Spell checker integration (Aqua / X11)

Hmmmmmm

Philip ( Walks like a Duck, drinks Cocoa & Java )

[OPENSTEP]

I noticed those a while back and, ironically, some of them correspond to design specs I wrote years ago. It does smack me, though, as kind of an odd situation. OOo is inherently frustrating code with a high learning curve, isn't necessarily "cool", and I don't think that it provides a good educational environment for learning good engineering skills.

SoC really should be about creating a productive learning environment for a student. Projects should be really narrow in scope, fairly well defined and/or spec'd out, and should ideally be able to be accomplished in a few months. Nothing sucks more than leaving a project unfinished. You really also need to have people dedicated to metor folks who are willing to spend a very very large amount of time with students who may not be familiar with working on large codebases, may not yet be on the same productivity level as professional engineers, and are willing to help the student with technical problems and debugging (a skill often not learned in college, but rather thorugh experience). Mentors also need to be quite well versed in both engineering as well as management, not just one or the other.

Several of the ideas that are floating around for SoC, not just from OOo but from other projects as well, seem to be focused on what the project can get out of it with a writeup that shows about as much consideration as one would take when submitting blurbs to outsourcing agencies for bids. SoC shouldn't be about trying to find cheap labor, but rather about providing a student a postive learning experience to get accustomed to real-world engineering practices, remote communication skills, collaborative development processes, and having fun too.

I really think that any student who has the opportunity would do best to avoid SoC in general, go out and find an internship at a real company, spend the summer working in an office environment with other engineers, perhaps visit a new part of the country, and make new friends with other interns. It's a much more educational experience. After all, you're never going to get into a cubicle Nerf war sitting at home talking over e-mail with a faceless manager.

ed

[pluby]

I actually find some of these items a bit backwards. Sticking a native file picker on top of their existing Aqua code (which is the code that I and a couple other guys wrote at Sun 5 years ago) seems kind of silly when I know that that old code had (and still does have) serious issues with simple things like event handling and drawing that cause it to crash or use 100% of CPU.

When I first started working on NeoOffice, I felt that that old code had such serious problems, I ignored my old code and started over from scratch.

Maybe its just me, but building a big cool house on sand and no foundation seems like you'll only get an unstable house. But that's just my engineering perspective.

Patrick

[LemonAid]

<rant> grinning
Well Darn, If youse guys that helped write (much of) the underlying code think that this is not the best of plans/ideas/projects - then it must be good!?!
<rant>

Sorry, I just could NOT help myself. You might say "I could not resist taking a shot at a sitting ... Duck".


It is interesting to learn more about the history of many of these items and why certain decisions were, or were not, made. Thank you both for your comments.

I wish every one much luck and look forward to better options for the OOo Community.

Philip ( going to sit in the corner now, and read ISO 26300 specs? )

p.s. Yes, I did start this message "after" comments were made in the "Portuguese Dictionary problem" string. Who knew to look in that string?!?
p.s.s. Hmmm, would it be possible to copy the Dictionary history messages from that message to this one? Just to keep all the wonderful background information in on string?

psssssss MUST - Back - Away - From - KEYBOARD!!!!!

[OPENSTEP]

I think there's some history in the Wiki on it as well. The "Aqua" OOo code was really a mismosh of Cocoa and QuickDraw that Patrick worked on back in 2000 at Sun, but at that time the compiler difficulties and flat namespaces of the first 10.0 tools were much more of a problem. Neo/C was built on that same foundation and I fixed up some of the event handling issues (but not all) and hacked in native widgets. Eventually Dan moved off of QuickDraw onto CoreGraphics, we shifted to objective c++, but it always had threading issues, event handling fun, performance issues, and doing the RTL stuff in OOo 1.1 just was a nightmare. Not to mention undocumented changes in event handling with each subsequent release of OS X started breaking the nonstandard Cocoa code too.

The "new" OOo non-X11 code is just that same old QuickDraw code from 2000 that's had appropriate naming revisions and updates so it can compile with OOo 2.0 and run to the point where you can get some screenshots. Big deal. I did that back in 2001 (oddly on the same laptop I'm posting from now...man, I need a new laptop). The underlying structure is still bunk, doesn't set up properly initialized run loops, will suffer from ordering and threading issues, and the like. There's a reason why both Patrick and I dropped that approach like a ton of bricks.

ed