12 April 2014: The OpenOffice Wiki is not, and never was, affected by the heartbleed bug. Users' passwords are safe and wiki users do not need take any actions.

Summer of Code 2006

From Apache OpenOffice Wiki
(Redirected from SummerOfCode2006)
Jump to: navigation, search

Please note that Summer of Code 2007 started!


OpenOffice.org Summer of Code Projects

OpenOffice.org is proud to participate again in the Summer of Code initiative sponsored by Google. In 2006 five projects from the suggestions and one additional interesting subject have been selected. We are glad that we are able to support some additional efforts indepent from SoC. The list of projects worked on in 2005 is still available.

For further general questions about the Summer of Code initiative Google prepared FAQs for students and mentors.

SoC 2006 Logo


Programmability: Dynamic UNOIDL Reference Browser

The OpenOffice.org API is specified in IDL (Interface Definition Language). IDL allows a language independent description of the API and language bindings/bridges allows the use of the same API from various languages where exactly such a language binding/bridge exists. But often it is difficult for users of the API to map the language independent IDL reference documentation to their preferred and used programming language, e.g. Java or StarBasic. But exactly this would speed up their daily work, a Java programmer would like to have a Javadoc like reference of the API. The idea of a “Dynamic IDL Reference Browser” is to develop a new concept for documenting IDL types in XML and a concept to provide a dynamically created representation for different languages. That means in detail that the reference browser would dynamically create a piece of XML code from the IDL definition and the provided XML documentation string for the IDL type. An appropriate XSL transformation would convert the XML representation into the required language representation. For example a Java developer gets the correct Java mapping for an IDL interface type. The dynamically approach has the advantage that we can (in a second step) analyze the navigation path to a type and can show context specific documentation. That can be very useful for generic types which have different meanings in different contexts. For example a return type of a generic type XEnumeration from function F of interface X. The generated documentation for XEnumeration would show exactly the info which is necessary to understand and use XEnumeration in the context of function F from interface X. It shows for example that the enumeration in this context always contains objects of type Y and even more information for more complex context dependent information.

  • required skills/knowledge: Java, XML, XSLT
Contact
dev@api.openoffice.org
Juergen.Schmidt at sun.com

Basic IDE: BASIC/UNO Object Browser

Target of this project is to create an UI component that allows to browse through the structure of UNO objects. Unlike the Basic IDE watch window that recently has been improved to display object properties and their values in an reasonable way the object browser should show the objects' API structure (properties, methods, interfaces, services). It has to be specified if this should refer to the Basic API view (Basic types, no explicit distinction of different interfaces) or the UNO view (UNO types, interface oriented) or if the browser should support two modes allowing to switch between Basic and UNO view. A Basic view is more challenging because it requires Basic related knowledge and probably new functionality in the Basic project. Actually the component is more like a type browser as the objects' static class/interface structure should be displayed, but unfortunately most information are only available for a "living" object using the XtypeProvider interface and the Reflection and Introspection API. Nevertheless it would also make sense to support types directly, e.g. to show the new style UNO service / multi inheritance interfaces.

  • required skills/knowledge: Java, C++, StarBASIC, UNO
Contact
dev@api.openoffice.org
Andreas.Bregas at sun.com

Native SQLite driver

SQLite (http://www.sqlite.org/) is a SQL database used as lean back end in a number of applications. The task is to write a native SDBC database driver (resp. finalize the existing skeleton: http://dba.openoffice.org/drivers/sqlite/index.html) for OpenOffice.org, accessing SQLite files efficiently.

  • required skills/knowledge: C++, relational database concepts
  • recommended skills/knowledge: SQLite API
  • useful skills/knowledge: OOo's component technology (UNO)
Contact
dev@dba.openoffice.org
Ocke.Janssen at Sun.COM
Info & Student
The new SQLite-Driver will be maintained from me after Summer of Code!
aklitzing at openoffice.org
http://www.incubo.de
Source
http://dba.openoffice.org/source/browse/dba/connectivity/source/drivers/sqlite3/
cws_src680_sqlite: http://dba.openoffice.org/source/browse/dba/connectivity/source/drivers/sqlite3/?only_with_tag=cws_src680_sqlite

Writer: Import Filter for Word Perfect Graphics files

Latest progress and screenshots
  1. http://ariya.blogspot.com/search/label/wpg
Summary

The writerperfect import filter for WordPerfect™ documents, based on libwpd (http://libwpd.sourceforge.net), was integrated into the OOo2.0. The libwpd is a standalone library also used by other projects like KOffice or AbiWord. Another standalone library that reads WordPerfect graphics files would improve the interoperability with the WordPerfect Office Suite. An import filter for this file format based on this new standalone library can become embedded into OOo in the same way as libwpd. Please find more information at http://fridrich.blogspot.com/2006/04/wordperfect-graphics-conversion-wants.html." The base for this work will be the, already existing, even though unreleased, code of libwpg library (http://sourceforge.net/projects/libwpg)

Skills
  • Being highly comfortable developing using C++ and Standard Template Library. Have in mind that the code has to be strictly portable.
  • Not need of knowing the OpenOffice.org API
Some hints about possible tasks
  1. Convert all vector graphics records of WPG2 format. It is already done for WPG1 and it works quite correctly (some problems with colors due to an undocumented record, but fixable since we have a kind of documentation now).
  2. The parameters of the API callbacks should be as close as possible following the SVG properties for a given object (ellipse, circle, path, ...). So that one can use the wpg2svg to visualize instantly the conversion result. And like that, it will be easier to use the libwpg library with another libraries that render SVG, i.e. librsvg. And, last but not least, the converter code could be than used with anything that generates SVG.
  3. Still maintain wpg2raw in order to be able to create a regression test suite.
  4. Create a wpg2odg converter which outputs SAX messages in odg format (handler independent) + write two handlers (very trivial), one for dumping the content.xml into stdout and other for writing a zipped odg file. Because of the OOo document handler, everything should be preferably contained in one single flat content.xml including styles and metadata if converted. One can use styles.xml in the handler that writes the zipped file if we need to set some default styles for third party applications as we do it in the wannabe KWord import filter and in the CVS version of wpd2sxw.
  5. Abstract the stream implementation inside libwpg and make the odg filter core not depend on any specific stream abstraction layer. Only the handlers. Write a sample input stream implementation class using C++ STL input stream classes (get rid of dependency on libgsf).

If this is done in short time, the following things could be done, but optional:

  1. Rewrite the libwpg API so that it is breakage proof like libwpd is currently, possibly using libwpd's public API (WPXProperty, WPXPropertyList, WPXPropertyListVector and WPXString). Or extend the libwpd's API if the original one is not corresponding to our needs (i.e. the SVG property points="X1,Y1 X2,Y2 ... Xn,Yn" could be a problem).
  2. Convert text strings.
  3. Find a way to extract the bitmap part of WPG2, decode it (run-length encoding) convert it to some simple raster format (*.bmp ???) and add it [maybe base64 encoded] into the resulting xml.
Practical guidelines
  1. For a nice integration with OO.o, no STL types should appear in the API. Many distributions use OO.o built against system libraries and OO.o uses internally stlport. STL and stlport types do not have the same signatures, so bad bad if one links a library compiled using STL from inside OO.o build environment.
  2. Put the libwpg API in a separate namespace in order to avoid possible conflicts with whatever other library OO.o could use.
  3. Avoid completely "using namespace std" statement, since it is possible that it will have problems with one or other of the compilers on one of OO.o platforms.
Contact
dev@wp.openoffice.org
Fridrich Štrba (fridrich_strba at openoffice.org)

Porting: Mac OS X's Aqua Porting of OpenOffice.org

Does concern : OpenOffice.org 2.0.3 or superior, for Mac OS X port (both Aqua and X11 versions)

Subject proposed by : Éric Bachard

Tasks :

(1) analyze current implementation : design, concerned modules, isolate classes and parameters

(2) propose a design for the new one, using Apple API

(3) write and test a proof of concept

If enough time: (4) implement the solution, with possible backport to X11 version.

  • Skills : knowledge of languages C / C++ , using Carbon/Cocoa API, knowledge of font systems and font technology
Contact
dev@porting.openoffice.org
Éric Bachard (ericb at openoffice.org)

UNO service for grammar checkers in OOo Writer

Target of this project is to create an API (Application Programming Interface) and a UNO service to plug in grammar checkers in OpenOffice. Similar to SpellChecker service, the GrammarChecker service will provide text data as Strings to a grammar checker and receive objects as results. It should be able focus wrong sentences with a wavy line and be able to replace them as well.

  • required skills/knowledge: Java, C++, UNO
Further information
Project Blog
Lingucomponent Mail List
Contact
<dev@lingucomponent.openoffice.org>,
bruno-linux@uol.com.br
Personal tools