Difference between revisions of "Summer of Code 2006"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (Basic Citation Enhancements: Add into sentence)
(Fix many spelling errors and add extended ASCII characters to names.)
 
(41 intermediate revisions by 17 users not shown)
Line 1: Line 1:
=='''OpenOffice.org Summer of Code Projects'''==
+
'''Please note that [[Summer of Code 2007]] started'''!
  
OpenOffice.org is proud to participate in the [http://code.google.com/soc/ Summer of Code] initiative sponsored by Google. Below you'll find some suggestions we find suitable for the program. If you have ideas for other tasks please send a note to the developer list of the related [http://projects.openoffice.org/accepted.html OpenOffice.org project] or contact the project lead.
 
  
We would be glad to support a few projects. Please understand that mentoring capacities are limited. So we depend on your dedication during the preparation of the detailed specification and description of the outcome.
+
=='''OpenOffice.org Summer of Code Projects'''==
  
The timeframe for applications is May 1 - May 8. But keep in mind that it may need some prearrangement before you are ready to apply.
+
OpenOffice.org is proud to participate again in the [http://code.google.com/soc/ Summer of Code] initiative sponsored by Google. In 2006 five projects from [http://wiki.services.openoffice.org/mwiki/index.php?title=SummerOfCode2006&oldid=11472 the suggestions] and one additional interesting subject have been selected.
 +
We are glad that we are able to support some [[OpenOffice.org Internship|additional efforts]] indepent from SoC. The list of projects worked on in 2005 is still available.
  
For further general questions about the initiative Google prepared FAQs for [http://code.google.com/soc/studentfaq.html students] and [http://code.google.com/soc/mentorfaq.html mentors].
+
For further general questions about the Summer of Code initiative Google prepared FAQs for [http://code.google.com/soc/studentfaq.html students] and [http://code.google.com/soc/mentorfaq.html mentors].
  
 +
[[Image:Bnr_soc_125x58.gif|right|SoC 2006 Logo]]
  
 
__TOC__
 
__TOC__
  
  
==API / Programmability==
+
===Programmability: [[Dynamic_UNOIDL_Reference_Browser|Dynamic UNOIDL Reference Browser]]===
 
+
===Programmability: Dynamic IDL-Referenz-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.  
 
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.  
Line 28: Line 27:
 
: Juergen.Schmidt at sun.com
 
: Juergen.Schmidt at sun.com
  
===Basic IDE: BASIC/UNO Object Browser===
+
===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.  
 
Target of this project is to create an UI component that allows to browse through the structure of UNO objects.  
Line 41: Line 39:
 
: dev@api.openoffice.org
 
: dev@api.openoffice.org
 
: Andreas.Bregas at sun.com
 
: Andreas.Bregas at sun.com
 
 
==[http://bibliographic.openoffice.org/ Bibliographic]==
 
 
===Basic Citation Enhancements===
 
'''Priority:''' Critical '''Difficulty:''' medium-high
 
 
The bibliographic facility on Openoffice needs considerable enhancement to make it competitive with other bibliographic applications. This is a vital task in the enhancement project. 
 
 
The task is to implement the most basic changes and additions to the Writer core code (the [http://api.openoffice.org/API API] basic code, and [http://udk.openoffice.org UNO] mappings) necessary to implement basic support for:
 
 
* code to read and write the new, and much improved, citation format (A developer - CPH has already made good progress with this). See [[New_Citation_XML_info_design_and_implementation | Citation XML info design and implementation ]] and [[Citeproc_Writer_Interaction | implementation discussion]].
 
* exposing the new code though UNO
 
* Write a simple program in OOo Basic or Python to demonstrate the new UNO functions by Inserting and displaying the enhanced citations in Writer using the new format.
 
 
See our [[Bibliographic_Project's_Developer_Page | Developer's Page]] and Florien's [http://blogs.sun.com/roller/page/flo?entry=the_community_and_me_the blog entry] on this topic.
 
 
* required skills/knowledge: good C++ programming skills.
 
* required skills/knowledge: experience with Object Oriented Technologies such as COM/COM+/DCOM and Corba.
 
* required skills/knowledge: some knowledge of, or ability to quickly utilise, the Openoffice API and UNO
 
* required skills/knowledge: able to write a small OOo basic program.
 
'''Contact'''
 
 
[[SOC_Draft_tasks#Applying.2C_suggestions | Application advice]]  dev@bibliographic.openoffice.org
 
 
David Wilson <dnw@openoffice.org>
 
Florian Reuter <Florian.Reuter@sun.com>
 
 
===Convert the Citeproc Bibliographic Formatting Engine to Python or C++===
 
'''Priority:''' Important '''Difficulty:''' medium
 
 
The new Bibliographic formatting engine, [http://bibliographic.openoffice.org/citeproc/index.html Citeproc], currently exists as a set of XSLT 2.0 stylesheets. In addition, a Ruby [[Bibliographic_Project's_Developer_Page#Formating_Engine | prototype]] has been started. In order to be integrated into OOo, the formatting engine ultimately needs to be C++, though given the UNO-Python bridge, creating a Python module that can be added to OpenOffice using the OOo add-on package manager is a reasonable prototying option.
 
 
The formatting engine should take a list of citation reference IDs from Writer and return the formatted citation text and insert it into Writer.
 
 
If possible, it would be great if the developer could also utilise the new internal citation structures being developed for Writer for the demonstration.
 
 
See our [[Bibliographic_Project's_Developer_Page | Developer's Page]] and this [[Current_Implementation_of_the_OpenOffice.org_Bibliographic_Component | article]]
 
 
* required skills/knowledge: good C++ or Python programming skills.
 
'''Contact'''
 
 
[[SOC_Draft_tasks#Applying.2C_suggestions | Application advice]]  dev@bibliographic.openoffice.org
 
 
David Wilson <dnw@openoffice.org>
 
 
===Develop a Bibliographic Database design and implement a Ruby On Rails prototype===
 
'''Priority:''' Important '''Difficulty:''' medium
 
 
Assist is the development of of a [[Bibliographic_Database | Bibliographic Database]] and build a [http://www.rubyonrails.org/ Ruby On Rails] database management system with Browse, Add, Delete and Edit functions.
 
 
OOo Bibliographic project Leader, Bruce D'Arcus, has started working on database designs and now needs a skilled database designer to take on this task. The person would preferably have some Ruby on Rails exposure.
 
 
See our [[Bibliographic_Project's_Developer_Page | developer's wiki page]]
 
 
* required skills/knowledge: strong Database design.
 
* required skills/knowledge: Ruby On Rails exposure.
 
'''Contact'''
 
 
[[SOC_Draft_tasks#Applying.2C_suggestions | Application advice]]  dev@bibliographic.openoffice.org
 
 
"Bruce D'Arcus" <bdarcus@gmail.com>
 
 
==Calc==
 
 
===Calc: Show formula syntax in tip help===
 
 
When a cell formula is being edited, in addition to the function selection above the cell, show some input hints (like the syntax of the function that is edited) in a tip help window below the cell.
 
 
* required skills/knowledge: good C++ expertise
 
* recommended skills/knowledge: -
 
 
; Contact
 
: dev@sc.openoffice.org
 
: Niklas.Nebel at sun.com
 
 
===Calc: Add resizeable margin on page preview===
 
 
In the page preview, add the possibility to interactively change page margins by dragging an indicator, instead of using the page style dialog (see http://www.openoffice.org/issues/show_bug.cgi?id=51656).
 
 
* required skills/knowledge: good C++ expertise
 
* recommended skills/knowledge: -
 
 
; Contact
 
: dev@sc.openoffice.org
 
: Niklas.Nebel at sun.com
 
 
==Database Access==
 
 
===Linking external text tables into OOo databases===
 
 
Native OOo Base databases (.odb) use the HSQLDB (http://hsqldb.org/)
 
database engine. HSQLDB features a mechanism to link external text
 
tables into the database, as if they were a native HSQL table
 
(http://hsqldb.org/doc/guide/ch06.html).
 
 
The task of this project is to bring this feature to OpenOffice.org. For
 
this, the respective database driver of OOo Base has to be extended with
 
an API to administrate such text table links. Additionally, an user
 
interface needs to be designed and implemented for using this API.
 
 
* required skills/knowledge: C++, relational database concepts
 
* recommended skills/knowledge: OOo's component technology (UNO)
 
* useful skills/knowledge: HSQLDB text table concepts
 
 
; Contact
 
: dev@dba.openoffice.org
 
: Frank.Schoenheit at Sun.COM
 
  
 
===Native SQLite driver===
 
===Native SQLite driver===
  
SQLite (http://www.sqlite.org/) is a SQL database used as lean backend
+
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
 
in a number of applications. The task is to write a native SDBC database
 
driver (resp. finalize the existing skeleton:
 
driver (resp. finalize the existing skeleton:
Line 166: Line 56:
 
: Ocke.Janssen at Sun.COM
 
: Ocke.Janssen at Sun.COM
  
===Embed Derby into OpenOffice.org databases===
+
; Info & Student
 +
: The new SQLite-Driver will be maintained from me after Summer of Code!
 +
: aklitzing at openoffice.org
 +
: http://www.incubo.de
  
OpenOffice.org Base features an abstract mechanism to embed database
+
; Source
backend files into OOo databases (.odb). Currently, this is implemented
+
: http://dba.openoffice.org/source/browse/dba/connectivity/source/drivers/sqlite3/
for HSQLDB (http:///hsqldb.org), which is used as OOo's default database
+
: cws_src680_sqlite: http://dba.openoffice.org/source/browse/dba/connectivity/source/drivers/sqlite3/?only_with_tag=cws_src680_sqlite
engine.
+
  
To allow this feature for other engines, one must:
+
===Writer: Import Filter for Word Perfect Graphics files===
* virtualize the engine's file access, so that it re-routes all its file operations through an abstract API.
+
* implement this API on the OOo Base side
+
  
The project is to do those implementations for Apache Derby database (http://db.apache.org/derby/).
+
;Latest progress and screenshots
 
+
#http://ariya.blogspot.com/search/label/wpg
* required skills/knowledge: C++
+
* recommended skills/knowledge: relational database concepts
+
* useful skills/knowledge: OOo's component technology (UNO)
+
 
+
 
+
; Contact
+
: dev@dba.openoffice.org
+
: Ocke.Janssen at Sun.COM
+
 
+
===Database driver UI modularization===
+
 
+
OpenOffice.org Base follows a component-oriented approach for enabling
+
database access. For this, database drivers are installed in
+
OpenOffice.org which provide access to a certain (class of) database(s).
+
 
+
While at the driver level, the implementation is pretty good
+
modularized, the UI implementation can be improved. Currently, there are
+
a lot of places in the code with hard-coded information, such as
+
"database X requires UI option Y".
+
 
+
The goal of this project is to design and implement a reasonable
+
architecture for bringing a driver to the UI. The existing
+
implementation needs to be migrated to this new architecture. As a proof
+
of concept, an existing currently-external driver (e.g.
+
http://dba.openoffice.org/drivers/postgresql/index.html) should be
+
modified so that it can be deployed into an OOo installation and makes
+
use of the features of the new architecture.
+
 
+
* required skills/knowledge: C++
+
* recommended skills/knowledge: OOo's component technology (UNO)
+
* useful skills/knowledge: OOo's configuration concepts
+
 
+
; Contact
+
: dev@dba.openoffice.org
+
: Frank.Schoenheit at Sun.COM
+
 
+
===HSQLDB: single-file backend===
+
 
+
HSQLDB (http:///hsqldb.org) is the database engine used by OpenOffice.org.
+
 
+
HSQL currently creates a number of adjacent files to store its data,
+
where all files together comprise the whole database. To allow the user
+
of OpenOffice.org Base to have a "all-in-one-file" database experience,
+
those HSQL files are currently embedded in some OOo-specific
+
container-file (the .odb file).
+
 
+
To overcome various disadvantages of this approach, it is desirable that
+
HSQL stores its data in a single, large file. Preliminary code and
+
concepts exist for this, but no final implementation.
+
 
+
This project needs to be worked on in close collaboration with the
+
HSQLDB project, whose owner, Fred Toussi, will act as co-mentor.
+
 
+
* required skills/knowledge: good Java expertise, relational databases
+
* recommended skills/knowledge: HSQLDB architecture
+
 
+
; Contact
+
: dev@dba.openoffice.org
+
: Frank.Schoenheit at Sun.COM
+
 
+
==Distribution==
+
 
+
===Download / Mirror Management Tool: Bouncer===
+
 
+
We made the first steps to use bouncer for OpenOffice.org download and mirror management. This tool developed at the [http://wiki.osuosl.org/display/LNX/Google+Summer+of+Code+2006+Ideas Oregon State University Open Source Lab] would significantly ease the handling of download pages.
+
There are some crucial features open for [http://wiki.osuosl.org/display/Bouncer/Bouncer+3 Bouncer v3] you could help to finalize.
+
 
+
; Contact
+
: mirrors@distribution.openoffice.org
+
: [http://morgamic.com/ Mike Morgan] and [http://osuosl.org/Members/lars/ Lars Lohn]
+
 
+
==Framework==
+
 
+
===Performance: Fast native implemented OOo Dispatch Loader===
+
 
+
Implementing a faster small Office Loader, independent from OOo libraries that uses native APIs to show the splashscreen. This will speed up UI response time after first Office start by 90 percent.
+
Implementing propagation of command line parameters with a native pipe implementation. This will speed up loading of documents after double clicking them in the OS desktop environment.
+
Remove any dependency to OOo libraries from the loader code, so that it is implemented with native APIs only. This allows the loader to be as small as possible and to run without any bootstrapping. This will reduce I/O overhead and unnecessary code execution at startup.
+
Adjust the pipe implementation in desktop module to fit the native pipe implementations
+
Prototypes of a Loader for Windows and Linux are available, implementing the required features at least on one platform.
+
 
+
; Contact
+
: dev@framework.openoffice.org
+
: Hennes.Rohling at sun.com
+
 
+
 
+
 
+
==Graphics==
+
 
+
===Filter: creating a Visio filter for OOo Draw===
+
 
+
OOo currently lacks support for a Visio import
+
filter, so that it would be good to have someone
+
starting to write such a filter from scratch
+
utilizing the OOo API for direct creation of the
+
document or the ODF format as input format to
+
be loaded by the OOo application. Although
+
a full blown filter seems to be unrealistic
+
to be written within the short timeframe, large
+
parts of Visio documents should be able to be
+
filtered correctly.
+
 
+
* required skills/knowledge: good C++ expertise, graphics programming
+
* recommended skills/knowledge: Visio file format / ODF or OOo API
+
 
+
; Contact
+
: dev@graphics.openoffice.org
+
: Sven.Jacobi at Sun.COM
+
 
+
===GSL: Port Cairo Canvas to Win32===
+
 
+
Cairo canvas is an OpenOffice.org canvas backend, which provides
+
beautiful anti-aliased rendering functionality using the 'cairo'
+
library. Today the cairo canvas backend works only on u*ix systems.
+
The objective is to allow OpenOffice.org to use cairo on win32. Cairo already
+
targets win32, and using it would give a faster, more beautiful
+
slide-show experience.
+
 
+
Building OOo on Win32 is moderately painful, requiring a VC++.Net 2003
+
compiler, although it's possible that (with some extra work) the (free)
+
VC++ Express Edition could be used.
+
 
+
Skills: C, C++, cygwin, Win32 compiling
+
 
+
; Contact
+
: dev@gsl.openoffice.org
+
: Radek Doulik (radekdoulik at openoffice.org)
+
 
+
==Stats==
+
 
+
===Source Code Repository Activity===
+
 
+
Provide statistics for CVS repository activity. The first step would be a quick analyse what type of statistics other projects are providing. Together with our requirement to better understand how the code base and groups of committers are evolving this should give input to start work on the preparation of some nice stats and graphs about repository activity. Results should be generated with open-source tools, automatically and on a regular basis for the http://stats.openoffice.org website. Additionally an interface to [http://cia.navi.cx cia] would be helpful.
+
 
+
; Contact
+
: dev@stats.openoffice.org
+
: Stefan Taxhet (stefan.taxhet at sun.com)
+
 
+
== Tools ==
+
 
+
===Integrating Autodoc generated IDL documentation into the Visual .NET IDE===
+
 
+
; Background
+
 
+
Autodoc (http://tools.openoffice.org), the OpenOffice.org (http://www.OpenOffice.org) documentation parser, creates a series of HTML documentation pages out of the SDK IDL files (see http://api.openoffice.org/docs/common/ref/com/sun/star/module-ix.html).
+
The generated documentation can be integrated for example into Netbeans. “Integrated” means that from that IDE (integrated development environment) the documentation is accessible via internal indexes and/or context sensitive help. It would be useful to be able to integrate it also into other much used development environments, for example the Visual .NET IDE.
+
Integration into the Visual .NET IDE can be done by providing some additional files that match the MS Help 2.0 format (see http://www.helpware.net/mshelp2/h20.htm for some information).
+
 
+
; Task
+
 
+
# Enable Autodoc to provide the additionally needed files to integrate the created documentation into the Visual .NET IDE.
+
# Document the mechanism to compile those files and make the Autodoc generated documentation visible within the IDE.
+
 
+
; Skills
+
 
+
* Needed: Good C++.
+
* Helpful: Knowledge about the OpenOffice.org SDK, experience with an IDE.
+
 
+
; Contact
+
: dev@tools.openoffice.org
+
: Nikolai.Pretzell at sun.com
+
 
+
==Writer==
+
 
+
===Writer: Improved Lotus WordPro Import Filter===
+
 
+
Currently there is a very basic import filter for WordPro that only
+
imports pure text. It would be desirable to import more content and
+
structure from WordPro documents.
+
 
+
; Contact
+
: dev@sw.openoffice.org
+
: Oliver.Specht at sun.com
+
 
+
===Writer: Component for guessing the language of a text===
+
 
+
Currently the OOo spell checker tries to guess the language of a text
+
with an unknown word by searching for it in a fixed number of
+
dictionaries or thesauri because checking all available languages would
+
be too much. This limited search is inconvenient if the used language is
+
not amongst the preselected ones. There are already known heuristic
+
approaches to guess the possible language of a text, some of them are
+
available as descriptions, some even as source code. Integrating such a
+
component into OOo would improve working in multi language documents.
+
 
+
(Possibly useful references: [http://chardet.feedparser.org/ #1], [http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html #2])
+
 
+
; Contact
+
: dev@sw.openoffice.org
+
: Thomas.Lange at sun.com
+
 
+
===Writer: Import Filter for Word Perfect Graphics files===
+
  
The writerperfect import filter for WordPerfect(tm) documents, based on libwpd (http://libwpd.sourceforge.net), was integrated into the OOo2.0.
+
;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
 
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
 
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
Line 378: Line 77:
  
 
;Skills
 
;Skills
* Being highly comfortable developping using C++ and Standard Template Library. Have in mind that the code has to be strictly portable.
+
* 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
 
* Not need of knowing the OpenOffice.org API
  
 
;Some hints about possible tasks
 
;Some hints about possible tasks
#Convert all vector graphics records of WPG2 format. It is already done for WPG1 and it works quite correctly (some problems with colours due to an undocumented record, but fixable since we have a kind of documentation now).
+
#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).
 
#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 <code>wpg2svg</code> 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.
 
#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 <code>wpg2svg</code> 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.
 
#Still maintain <code>wpg2raw</code> in order to be able to create a regression test suite.
 
#Still maintain <code>wpg2raw</code> in order to be able to create a regression test suite.
 
#Create a <code>wpg2odg</code> 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 <code>content.xml</code> including styles and metadata if converted. One can use <code>styles.xml</code> 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 <code>wpd2sxw</code>.
 
#Create a <code>wpg2odg</code> 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 <code>content.xml</code> including styles and metadata if converted. One can use <code>styles.xml</code> 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 <code>wpd2sxw</code>.
#Abstract the stream implementation inside libwpg and make the odg filter core not depend on any specific stream abstaction layer. Only the handlers. Write a sample input stream implementation class using C++ STL input stream classes (get rid of dependency on libgsf).
+
#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:
 
If this is done in short time, the following things could be done, but optional:
Line 400: Line 99:
 
; Contact
 
; Contact
 
: dev@wp.openoffice.org
 
: dev@wp.openoffice.org
: Fridrich Strba (fridrich_strba at openoffice.org)
+
: Fridrich Štrba (fridrich_strba at openoffice.org)
  
===Writer: iWork 'Pages' importer===
+
===Porting: [[Pdefilippis:_Project_Page|Mac OS X's Aqua Porting of OpenOffice.org]]===
 
+
The Apple iWork 'Pages' product stores its files in a .zip file,
+
using an XML format. It would be simple enough to parse this and
+
import at least some of the information: at a minimum raw text, simple
+
styles, tables and images.
+
 
+
There is some documentation for the Apple format at:
+
http://developer.apple.com/documentation/AppleApplications/Conceptual/iWork2-0_XML/index.html
+
and we can ask for more information where necessary. It would be
+
necessary for the applicant to have a copy of Pages to generate &
+
compare test files.
+
 
+
Skills: C++, XML
+
 
+
;Contact
+
: dev@sw.openoffice.org
+
: Michael Meeks (mmeeks at openoffice.org)
+
: Svante Schubert (Svante.Schubert at Sun.com)
+
 
+
==Porting==
+
 
+
===Porting: Integrate the native Mac OS X FilePicker into OpenOffice.org (Aqua/X11)===
+
 
+
Concerns : OpenOffice.org 2.0.3 or superior, for Mac OS X port (both Aqua and X11 versions)
+
 
+
Integrate the  native Mac OS X FilePicker into OpenOffice.org
+
The OOo FilePicker is already designed as a UNO component. What is needed is a new implementation of the FilePicker component based on the native Mac OS X FilePicker as it has been done on MS Windows for instance. On current Mac OS X port of OpenOffice.org, the current FilePicker is not native, less ergonomic.
+
 
+
Possible tasks :
+
 
+
Familiarize with the native Mac OS X FilePicker API and the OOo UNO interfaces for the FilePicker
+
Describe current implementation : design, concerned modules, isolate classes and parameters to manage
+
propose a new design using Apple API
+
write and test a proof of concept
+
 
+
Skills : knowledge of languages C / C++  , using Carbon/Cocoa API
+
 
+
Proposed by : Tino Rachui
+
 
+
; Contact
+
: dev@porting.openoffice.org
+
: Tino Rachui  ( Tino dot Rachui at Sun dot COM )
+
 
+
===Porting: Integrate OpenOffice.org help into Mac OS X help center (Aqua/X11)===
+
 
+
The OpenOffice.org help system is quite independent of the
+
underlying operating system and thus doesn't integrate well into
+
the help system on Mac OS X.
+
 
+
Possible tasks:
+
 
+
Learn how help system works in OpenOffice.org and how you can call it
+
 
+
Create sample help book for Apple Help
+
 
+
Prepare conversion framework for current XML/HTML based help pages to help book
+
 
+
Integrate provided solution into Openoffice.org CVS
+
 
+
Skills: C/C++, XML/XSLT, Carbon API
+
 
+
Proposed by: Pavel Janík
+
 
+
; Contact
+
: dev@porting.openoffice.org
+
: Pavel Janík ( Pavel at Janik dot cz )
+
: Frank Peters (Frank dot Thomas dot Peters at Sun dot COM)
+
 
+
===Porting : Mac OS X Address book integration (Aqua / X11) ===
+
 
+
Synopsis:
+
OOo currently is integrated with the Mozilla address book but not with the native Mac OS X address book. This is annoying for Mac OS X user. For better system integration it would be desirable to integrate with the Mac OS X address book.
+
 
+
Concerns: OpenOffice.org 2.x for Mac OS X (both Aqua and X11 versions)
+
 
+
Skills: Knowledge of languages C/C++, Mac OS X APIs and Application frameworks like Carbon or Cocoa for instance, knowledge of the Mac OS X address book APIs
+
 
+
Tasks:
+
Familiarize with the Mac OS X address book API's
+
Familiarize with the current OOo Mozilla address book integration
+
Make a prototype for OOo Mac OS X address book integration
+
 
+
; Contact
+
: dev@porting.openoffice.org
+
: Oliver Braun ( nerd at warpsite dot de )
+
: Frank Schoenheit ( Frank.Schoenheit at Sun.COM )
+
 
+
===Porting: Implement native font support, using native Apple API (Aqua / X11)===
+
  
 
Does concern : OpenOffice.org 2.0.3 or  superior, for Mac OS X port (both Aqua and X11 versions)
 
Does concern : OpenOffice.org 2.0.3 or  superior, for Mac OS X port (both Aqua and X11 versions)
  
Subject proposed by : none yet
+
Subject proposed by : Éric Bachard
  
 
Tasks :
 
Tasks :
Line 506: Line 117:
 
If enough time: (4) implement the solution, with possible backport to X11 version.
 
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
+
* Skills : knowledge of languages C / C++ , using Carbon/Cocoa API, knowledge of font systems and font technology
  
 
; Contact
 
; Contact
 
: dev@porting.openoffice.org
 
: dev@porting.openoffice.org
: Eric Bachard (ericb at openoffice dot org)
+
: Éric Bachard (ericb at openoffice.org)
 
+
 
+
===Porting : Mac OS X Spell checker integration (Aqua / X11)===
+
 
+
Synopsis:
+
OOo currently uses aspell or hunspell as spell checking components. Mac OS X comes with a build-in spell checker, which should be used by OOo for consitancy reasons, i.e. to save the user from having to maintain two dictionaries (OOo/OS X) in parallel.
+
+
Concerns: OpenOffice.org 2.x for Mac OS X (both Aqua and X11 versions)
+
 
+
Skills: Knowledge of languages C/C++/Objective C or Java, Mac OS X APIs and Application frameworks like Carbon or Cocoa for instance, knowledge of the Mac OS X spell checking APIs
+
 
+
Tasks:
+
Familiarize with the Mac OS X spell checking API's
+
Familiarize with the way OOo utilizes spell checkers
+
Make a prototype for OOo Mac OS X spell checker integration
+
 
+
; Contact
+
: dev@porting.openoffice.org
+
: Oliver Braun ( nerd at warpsite dot de )
+
: Thomas Lange ( Thomas.Lange at Sun.COM )
+
 
+
 
+
== QA ==
+
 
+
=== Release QA Tracking Tool ===
+
 
+
Tracking a release with dozens of languages and several platforms can be tedious. This is especially the case if the only used tool is a manually maintained table with colors indicating the status.
+
 
+
A web based tool should help us to keep track of the location and status of the builds as well as the responsible contact. The [http://qa.openoffice.org/localized/index.html workflow] in place should be supported. The tool should provide an [http://qa.openoffice.org/localized/status.html overview], the means to maintain a release including easy status manipulations.
+
 
+
; Contact
+
: dev@qa.openoffice.org
+
: Andre Schnabel (Andre.Schnabel at gmx.de)
+
 
+
=== Testtool Result Tracking Tool ===
+
 
+
Many of the QA team members are running automated tests for several releases, snapshots ... Every release should have successfully passed a number of tests. At the moment it is almost impossible to tell, what scripts have been run and what the results have been.
+
 
+
An online database could be of help here. The idea is to send the resultfiles (or an extract of the results) to this database, so they can be collected and analyzed.
+
 
+
A browser based frontend could help us to keep track of the testtool results.
+
 
+
; Contact
+
: dev@qa.openoffice.org
+
: André Schnabel (Andre.Schnabel at gmx.net)
+
: Helge Delfs (Helge.Delfs at Sun.COM)
+
 
+
==VBA interop: Chart API==
+
 
+
OpenOffice.org has Excel VBA interoperability support under development,
+
with some exciting preliminary results: eg. http://www.gnome.org/~michael/hypocycloid.jpeg
+
The work is essentially creating and extending simple mapping layers
+
between new VBA compatible object model APIs and the existing OOo UNO
+
APIs (using UNO).
+
 
+
A significant missing piece here is the Shape API (of which Charting
+
is an extension). Samples of existing wrappers for other objects can be
+
found here: http://go-oo.org/ooo-build/scratch/sc-vba/ and
+
http://go-oo.org/ooo-build/scratch/offapi-vba/
+
 
+
Skills: C++, Basic/VBA, [UNO]
+
 
+
; Contact
+
: dev at graphics.openoffice.org
+
: Noel Power <npower at openoffice.org>
+
  
----
+
===UNO service for grammar checkers in OOo Writer===
  
==OOo Project==
+
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.
  
===SoC Sample Suggestion Title===
+
* required skills/knowledge: Java, C++, UNO
  
Description
+
; Further information:
 +
: [http://soc-grammar.blogspot.com/ Project Blog]
 +
: [http://lingucomponent.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=1387990 Lingucomponent Mail List]
  
 
; Contact
 
; Contact
: list@project
+
: <dev@lingucomponent.openoffice.org>,
: Contact Person (email at domain)
+
: bruno-linux@uol.com.br
 +
[[Category:Education]]

Latest revision as of 05:25, 19 August 2013

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