[[Category:Marketing]]< [[Marketing]]
==OOo Miniconf at [http://www.mel8ourne.org/ linux.conf.au 2008]==

Miniconf [http://lca2007.linux.org.au/Miniconfs LCA 2007 Miniconf page]

OpenDay [http://lca2007.linux.org.au/OpenDay LCA 2007 OpenDay page]

The annual [http://lca2007.linux.org.au linux.conf.au (LCA)] is one of the major open source events world-wide. The OpenOffice.org community participated in the Miniconf program in Canberra 2005, in Dunedin NZ in 2006, and in Sydney 2007. The [http://www.mel8ourne.org/ 2008 LCA] will be held in [http://www.melbourne.vic.gov.au Melbourne, Australia] from 28 January to 2 February 2008, including Miniconf sessions during the first two days (28-29 January). If you would like to participate in the OOo Miniconf in 2008, please update this article or email events@marketing.openoffice.org [http://marketing.openoffice.org/servlets/ProjectMailingListList (subscribe)]

==Program ==

LCA is about Linux, but OOo is for all platforms. There is strong interest and support for OOo among the Linux community, and there is much overlap between the two communities, having a shared interest in free software and open source. The LCA Miniconf is currently the only formal OOo event in our region (Australia/NZ).

The OOo Miniconf includes formal presentations, workshops, Q&A and problem solving.

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Time || Presenter || Topic
|-
| || Speakers name here || Describe the presentation here
|-
| || ||
|-
| || ||
|-
| || ||
|-
| || ||
|-
| || ||
|-
|}

==Q&A and Demonstrations==

Demonstrations, Q&A and problem solving will be responsive to issues raised by vistors or participants in the Miniconf. These sessions will allow for one-on-one or small group problem solving and demonstration of features, for example:

put suggestions here

==About Linux Australia==

Linux Australia exists to serve and promote the Australian Linux and Open Source community. The organisation aims to do this best by taking enthusiasms within the community, such as FOSS issues, projects, education, advocacy just to name a few, and help them flourish, to succeed. The lifeblood of this organisation is the people in the community, and Linux Australia strives to be both relevant and useful to the community. For more details about Linux Australia visit: http://www.linux.org.au/

LCA 2007 Miniconf

2007-01-12T03:53:58Z

Sparcmoz: /* Program */

LCA 2007 Miniconf

2007-01-12T02:20:16Z

Sparcmoz: /* Program */

SDK Examples

2006-12-29T09:43:24Z

Sparcmoz:

This page records progress with testing the SDK Examples on new platforms - initially GNU/Linux SPARC and Mac Intel OS X. Testing should be followed by Issues created in IZ and patches. Please add results for other platforms.
Testing as at OOD680_m5 (2.0.4rc3), GNU/Linux SPARC tested using gcj-4.1.2

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Path to Example || Platform || Comment || Status / Link to IZ Issue
|-
| setsdkenv_unix || MacIntel OS X || Does not like spaces in OFFICE_HOME || Need set OFFICE_HOME=" ... path "
|-
| setsdkenv_unix || GNU/Linux SPARC || If no "java" commands available need adjust settings/settings.mk and settings/std.mk ||
|-
| examples/DevelopersGuide/FirstSteps || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/FirstSteps || MacIntel OS X || all || Needs a link libjpipe.jnilib -> libjpipe.dylib [http://qa.openoffice.org/issues/show_bug.cgi?id=69944 Issue69944]
|-
| examples/DevelopersGuide/Text || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/Text || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/UCB || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/UCB || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/Spreadsheet || GNU/Linux SPARC || unopkg failed ||
|-
| examples/DevelopersGuide/Spreadsheet || MacIntel OS X || unopkg failed || ERROR: (com.sun.star.uno.RuntimeException) { { Message = "unsatisfied query for interface of type com.sun.star.configuration.backend.XSingleLayerStratum!", Context = (com.sun.star.uno.XInterface) @0 } }
|-
| examples/DevelopersGuide/ScriptingFramework/SayHello || GNU/Linux SPARC || package is added but macro is not available until disabled and re-enabled || runtime error, see IZ
|-
| examples/DevelopersGuide/ScriptingFramework/SayHello || MacIntel OS X || package is added but macro is not available until disabled and re-enabled || macro runs OK
|-
| examples/DevelopersGuide/ScriptingFramework/ScriptSelector || GNU/Linux SPARC || build.xml needs property build.compiler=gcj (by ant) [exec] unopkg failed ||
|-
| examples/DevelopersGuide/ScriptingFramework/ScriptSelector || MacIntel OS X || (by ant) [exec] unopkg failed ||
|-
| examples/DevelopersGuide/ProfUNO/CppBinding || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/ProfUNO/CppBinding || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/ProfUNO/InterprocessConn || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/ProfUNO/InterprocessConn || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/OfficeDev || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/OfficeDev/Clipboard || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/OfficeDev/Linguistic || GNU/Linux SPARC || unopkg fails ||

|-
| examples/DevelopersGuide/OfficeDev || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/Charts || GNU/Linux SPARC || ||
|-
| examples/DevelopersGuide/Charts || MacIntel OS X || unopkg fails || ERROR: (com.sun.star.uno.RuntimeException) { { Message = "unsatisfied query for interface of type com.sun.star.configuration.backend.XSingleLayerStratum!", Context = (com.sun.star.uno.XInterface) @0 } }
|-
| examples/DevelopersGuide/Forms || GNU/Linux SPARC || Makefile has hard-coded "javac" should be $(SDK_JAVAC) all OK except not tested DataAwareness.run || OK - some minor labels and text truncation
|-
| examples/DevelopersGuide/Forms || MacIntel OS X || all OK except not tested DataAwareness.run || OK some minor text truncation in ControlValidation.run
|-
| examples/cpp/complextoolbarcontrols || GNU/Linux SPARC || unopkg works || needs patches [http://qa.openoffice.org/issues/show_bug.cgi?id=72679 Issue 72679] and [http://qa.openoffice.org/issues/show_bug.cgi?id=72793 Issue 72793]
|-
| examples/cpp/counter || GNU/Linux SPARC || OK || needs patch [http://qa.openoffice.org/issues/show_bug.cgi?id=72793 Issue 72793]
|-
| examples/cpp/remoteclient || GNU/Linux SPARC || OK || needs patch [http://qa.openoffice.org/issues/show_bug.cgi?id=72793 Issue 72793]
|-
| examples/cpp/DocumentLoader || GNU/Linux SPARC || OK || needs patches [http://qa.openoffice.org/issues/show_bug.cgi?id=72679 Issue 72679] and [http://qa.openoffice.org/issues/show_bug.cgi?id=72793 Issue 72793]
|}

[[Category:Porting]]
[[Category:MacOSX]]

SDK Examples

2006-12-22T06:43:08Z

2006-10-17T13:21:43Z

Sparcmoz: /* Rules (from LCA Organisers) */

LCA 2007 Miniconf

2006-10-17T10:54:19Z

Sparcmoz: /* LCA Rules*/

LCA 2007 Miniconf

2006-10-16T07:30:00Z

Sparcmoz: /* Timetable */

LCA 2007 Miniconf

2006-10-16T07:28:58Z

Sparcmoz: /* Demonstrations */

[[Category:Marketing]]< [[Marketing]]
==OOo Miniconf at linux.conf.au 2007==

The annual [http://lca2007.linux.org.au linux.conf.au (LCA)] is one of the major open source events world-wide. The OpenOffice.org community participated in the Miniconf program in Canberra 2005, and again in Dunedin NZ in 2006. Now we have been accepted on the program for 2007.

The 2007 LCA will be held in [http://www.cityofsydney.nsw.gov.au/ Sydney, Australia] from 15th to 20th January 2007.

If you like to participate in the OOo Miniconf on 16th January 2007, please update this article or email events@marketing.openoffice.org [http://marketing.openoffice.org/servlets/ProjectMailingListList (subscribe)]

There is also an [http://lca2007.linux.org.au/Miniconfs LCA Miniconf page] and when we are ready there will be a link to our wiki.

==Developing our Program ==

LCA is about Linux, but OOo is for all platforms. There is strong interest and support for OOo among the Linux community, and there is much overlap between the two communities, having a shared interest in free software and open source. The LCA Miniconf is currently the only formal OOo event in our region (Australia/NZ).

===Experience===

The 2005 Miniconf comprised of 2 days mainly being structured presentations with around 40-50 attending most sessions. The 2006 event was smaller but included structured presentations, demonstrations and workshop activities. It was interesting that many of the mainstream LCA conference presenters made use of OOo. During the 2006 event there was strong interest in Q&A and problem solving discussions and one-to-one or small group discussions. Much of the discussion was triggered by, and followed after, structured presentations.

===Objectives for 2007 Miniconf===

Based on the experience and from comments at the preceding events, the following objectives are proposed for 2007.

flexibility for LCA participants and OOo community to visit different Miniconfs

better opportunity for LCA participants to discuss issues and get help

more demonstration of OOo capabilities

==Program==

The OOo Miniconf will run for one day, including a small number of structured presentations. Informal workshops, Q&A and problem solving will be available continuously through the day. This will provide flexibility for participants to come and go when they like. It will also allow us to be responsive to needs or interests of individuals attending LCA, while also providing for in-depth focus on a few issues of significance for OOo.

===Formal Sessions===

Topics currently envisaged are:

case study about some interesting users of OOo

development and demonstration of special capabilities of OOo

report on community building and new developments

a guide to learning and help resources available to users

At some time during the program, there may be scope for a group discussion about next steps toward a dedicated OOo event for our region.

===Suggested Presentations===

Proposals are sought for presentations in the formal sessions. Please enter suggestions in the table below or private email to sparcmoz@openoffice.org

Do not worry about there being too many, possible duplications, off topic etc, we can sort that out later:

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name || Topic
|-
| Michael Still || Experiences of an author preparing a manuscript for publication using OOo
|-
| Michael Carden || National Archives of Australia use of OOo as a plugin to their [http://xena.sourceforge.net Xena] software for conversion of Office formats to ODF for preservation purposes.
|-
| Jim Watson || Developments in OOo - an overview of current community projects and some insights into the process
|-
| ||
|-
| ||
|-
| ||
|-
| ||
|}

===Demonstrations===

A number of workstations will be provided running OOo on different platforms. The following are already available, please add to the list if you can bring something, even if it is already listed, and later we can work out the best distribution of effort. Something with access to the conference wireless network, and some additional projectors would be useful.

OOo on GNU/Linux SPARC Sunblade 100

OOo on GNU/Linux Intel Compaq Armada 1750 (1999 vintage laptop)

portable projectors

These workstations and projectors will be used for one-on-one or small group problem solving and demonstration of features, to be run on-demand through the 2 days.

Some prepared demonstrations can be run on a continuous basis and re-cycled on demand. These would run for about 15-20 mins. Planned subjects for demonstrations include:

using styles in Writer

spreadsheet techniques using Calc

effective presentations with Impress

less well known features - database, math, etc

Any of the demonstrations can be adapted for larger groups if there is sufficient interest.

Demonstrations, Q&A and problem solving will be adapted and responsive to issues raised by vistors or participants in the Miniconf.

==Timetable==

the organisers have asked us to arrange our sessions to align with the conference timetable shown below. This will make it easier for people to drift between Miniconfs. We don't need to schedule the number of talks exactly as shown but what we do should fit into the time lines...

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
| Time || Session
|-
| 0900 || KEYNOTE (non-miniconf time)
|------------------------------
| 1030 || MORNING TEA
|------------------------------
| 1100 || TALK 1 - Start
|-
| 1140 || TALK 1 - End
|-
| 1150 || TALK 2 - Start
|-
| 1230 || TALK 2 - End
|------------------------------
| 1230 || LUNCH
|------------------------------
| 1400 || TALK 3 - Start
|-
| 1440 || TALK 3 - End
|-
| 1450 || TALK 4 - Start
|-
| 1530 || TALK 4 - End
|------------------------------
| 1530 || AFTERNOON TEA
|------------------------------
| 1600 || TALK 5 - Start
|-
| 1640 || TALK 5 - End
|-
| 1650 || TALK 6 - Start
|-
| 1730 || TALK 6 - End
|------------------------------
| 1730 || CLOSE
|}
Basically the day consists of 4 * 1.5 hour sessions. Which, depending
on the day will either be 1 * 90 minute tutorial, 2 * 40 minute talks,
or 4 * 15 minute short talks.

LCA 2007 Miniconf

2006-10-16T07:28:10Z

Sparcmoz: /* Timetable */

[[Category:Marketing]]< [[Marketing]]
==OOo Miniconf at linux.conf.au 2007==

The annual [http://lca2007.linux.org.au linux.conf.au (LCA)] is one of the major open source events world-wide. The OpenOffice.org community participated in the Miniconf program in Canberra 2005, and again in Dunedin NZ in 2006. Now we have been accepted on the program for 2007.

The 2007 LCA will be held in [http://www.cityofsydney.nsw.gov.au/ Sydney, Australia] from 15th to 20th January 2007.

If you like to participate in the OOo Miniconf on 16th January 2007, please update this article or email events@marketing.openoffice.org [http://marketing.openoffice.org/servlets/ProjectMailingListList (subscribe)]

There is also an [http://lca2007.linux.org.au/Miniconfs LCA Miniconf page] and when we are ready there will be a link to our wiki.

==Developing our Program ==

LCA is about Linux, but OOo is for all platforms. There is strong interest and support for OOo among the Linux community, and there is much overlap between the two communities, having a shared interest in free software and open source. The LCA Miniconf is currently the only formal OOo event in our region (Australia/NZ).

===Experience===

The 2005 Miniconf comprised of 2 days mainly being structured presentations with around 40-50 attending most sessions. The 2006 event was smaller but included structured presentations, demonstrations and workshop activities. It was interesting that many of the mainstream LCA conference presenters made use of OOo. During the 2006 event there was strong interest in Q&A and problem solving discussions and one-to-one or small group discussions. Much of the discussion was triggered by, and followed after, structured presentations.

===Objectives for 2007 Miniconf===

Based on the experience and from comments at the preceding events, the following objectives are proposed for 2007.

flexibility for LCA participants and OOo community to visit different Miniconfs

better opportunity for LCA participants to discuss issues and get help

more demonstration of OOo capabilities

==Program==

The OOo Miniconf will run for one day, including a small number of structured presentations. Informal workshops, Q&A and problem solving will be available continuously through the day. This will provide flexibility for participants to come and go when they like. It will also allow us to be responsive to needs or interests of individuals attending LCA, while also providing for in-depth focus on a few issues of significance for OOo.

===Formal Sessions===

Topics currently envisaged are:

case study about some interesting users of OOo

development and demonstration of special capabilities of OOo

report on community building and new developments

a guide to learning and help resources available to users

At some time during the program, there may be scope for a group discussion about next steps toward a dedicated OOo event for our region.

===Suggested Presentations===

Proposals are sought for presentations in the formal sessions. Please enter suggestions in the table below or private email to sparcmoz@openoffice.org

Do not worry about there being too many, possible duplications, off topic etc, we can sort that out later:

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name || Topic
|-
| Michael Still || Experiences of an author preparing a manuscript for publication using OOo
|-
| Michael Carden || National Archives of Australia use of OOo as a plugin to their [http://xena.sourceforge.net Xena] software for conversion of Office formats to ODF for preservation purposes.
|-
| Jim Watson || Developments in OOo - an overview of current community projects and some insights into the process
|-
| ||
|-
| ||
|-
| ||
|-
| ||
|}

==Demonstrations==

A number of workstations will be provided running OOo on different platforms. The following are already available, please add to the list if you can bring something, even if it is already listed, and later we can work out the best distribution of effort. Something with access to the conference wireless network, and some additional projectors would be useful.

OOo on GNU/Linux SPARC Sunblade 100

OOo on GNU/Linux Intel Compaq Armada 1750 (1999 vintage laptop)

portable projectors

These workstations and projectors will be used for one-on-one or small group problem solving and demonstration of features, to be run on-demand through the 2 days.

Some prepared demonstrations can be run on a continuous basis and re-cycled on demand. These would run for about 15-20 mins. Planned subjects for demonstrations include:

using styles in Writer

spreadsheet techniques using Calc

effective presentations with Impress

less well known features - database, math, etc

Any of the demonstrations can be adapted for larger groups if there is sufficient interest.

Demonstrations, Q&A and problem solving will be adapted and responsive to issues raised by vistors or participants in the Miniconf.

==Timetable==

the organisers have asked us to arrange our sessions to align with the conference timetable shown below. This will make it easier for people to drift between Miniconfs. We don't need to schedule the number of talks exactly as shown but what we do should fit into the time lines...

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
| Time || Session
|-
| 0900 || KEYNOTE (non-miniconf time)
|------------------------------
| 1030 || MORNING TEA
|------------------------------
| 1100 || TALK 1 - Start
|-
| 1140 || TALK 1 - End
|-
| 1150 || TALK 2 - Start
|-
| 1230 || TALK 2 - End
|------------------------------
| 1230 || LUNCH
|------------------------------
| 1400 || TALK 3 - Start
|-
| 1440 || TALK 3 - End
|-
| 1450 || TALK 4 - Start
|-
| 1530 || TALK 4 - End
|------------------------------
| 1530 || AFTERNOON TEA
|------------------------------
| 1600 || TALK 5 - Start
|-
| 1640 || TALK 5 - End
|-
| 1650 || TALK 6 - Start
|-
| 1730 || TALK 6 - End
|------------------------------
| 1730 || CLOSE
|}
Basically the day consists of 4 * 1.5 hour sessions. Which, depending
on the day will either be 1 * 90 minute tutorial, 2 * 40 minute talks,
or 4 * 15 minute short talks.

SDK Examples

2006-10-15T05:07:29Z

Sparcmoz: more results

This page records progress with testing the SDK Examples on new platforms - initially GNU/Linux SPARC and Mac Intel OS X. Testing should be followed by Issues created in IZ and patches. Please add results for other platforms.
Testing as at OOD680_m5 (2.0.4rc3), GNU/Linux SPARC tested using gcj-4.1.2

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Path to Example || Platform || Comment || Status / Link to IZ Issue
|-
| setsdkenv_unix || MacIntel OS X || Does not like spaces in OFFICE_HOME || Need set OFFICE_HOME=" ... path "
|-
| setsdkenv_unix || GNU/Linux SPARC || If no "java" commands available need adjust settings/settings.mk and settings/std.mk ||
|-
| examples/DevelopersGuide/FirstSteps || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/FirstSteps || MacIntel OS X || all || Needs a link libjpipe.jnilib -> libjpipe.dylib [http://qa.openoffice.org/issues/show_bug.cgi?id=69944 Issue69944]
|-
| examples/DevelopersGuide/Text || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/Text || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/UCB || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/UCB || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/Spreadsheet || GNU/Linux SPARC || unopkg failed ||
|-
| examples/DevelopersGuide/Spreadsheet || MacIntel OS X || unopkg failed || ERROR: (com.sun.star.uno.RuntimeException) { { Message = "unsatisfied query for interface of type com.sun.star.configuration.backend.XSingleLayerStratum!", Context = (com.sun.star.uno.XInterface) @0 } }
|-
| examples/DevelopersGuide/ScriptingFramework/SayHello || GNU/Linux SPARC || package is added but macro is not available until disabled and re-enabled || runtime error, see IZ
|-
| examples/DevelopersGuide/ScriptingFramework/SayHello || MacIntel OS X || package is added but macro is not available until disabled and re-enabled || macro runs OK
|-
| examples/DevelopersGuide/ScriptingFramework/ScriptSelector || GNU/Linux SPARC || build.xml needs property build.compiler=gcj (by ant) [exec] unopkg failed ||
|-
| examples/DevelopersGuide/ScriptingFramework/ScriptSelector || MacIntel OS X || (by ant) [exec] unopkg failed ||
|-
| examples/DevelopersGuide/ProfUNO/CppBinding || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/ProfUNO/CppBinding || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/ProfUNO/InterprocessConn || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/ProfUNO/InterprocessConn || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/OfficeDev || GNU/Linux SPARC || all || OK
|-
| examples/DevelopersGuide/OfficeDev || MacIntel OS X || all || OK
|-
| examples/DevelopersGuide/Charts || GNU/Linux SPARC || ||
|-
| examples/DevelopersGuide/Charts || MacIntel OS X || unopkg fails || ERROR: (com.sun.star.uno.RuntimeException) { { Message = "unsatisfied query for interface of type com.sun.star.configuration.backend.XSingleLayerStratum!", Context = (com.sun.star.uno.XInterface) @0 } }
|-
| examples/DevelopersGuide/Forms || GNU/Linux SPARC || Makefile has hard-coded "javac" should be $(SDK_JAVAC) all OK except not tested DataAwareness.run || OK - some minor labels and text truncation
|-
| examples/DevelopersGuide/Forms || MacIntel OS X || all OK except not tested DataAwareness.run || OK some minor text truncation in ControlValidation.run
|}

[[Category:Porting]]
[[Category:SparcPorting]]
[[Category:MacOSX]]

SDK Examples

2006-10-15T03:38:34Z

Sparcmoz: more results

SDK Examples

2006-10-15T03:17:56Z

Sparcmoz: more results

Extension Deployment

2006-10-12T08:15:06Z

Sparcmoz: /* Specifications for installation */

== First considerations ==

Extension deployement should not be considered as an independent task.
Indeed, when you need to deploy extensions on a number of workstations, you'll need also to deploy templates, autotexts, gallery themes, and so on, because you'll need to preserve a relative homogeneity. In fact, you'll often need to deploy extensions in the same time you need to deploy templates, autotexts and gallery themes.

This is the reason why it is suggested here to consider the following approach:

1 - to define the structure of a package which aims to deploy in one operation extensions, including macro and toolbars, templates, autotexts and gallery themes;

2 - to define the user interface of an administration tool whose goal is to create such a package;

3 - to define the user interface of a user tool which would enable the end user to install the package on her workstation, or the administrator to install it in the shared installation tree.

== Technical context ==
Before specifying the content of the package, we must keep in mind some technical constraints induced by the implementations of the configuration objects, and the rules for specifying their location.

=== The OOo registry ===
OOo comes with its own registry system.

The registry is implemented in a directory named "registry", as well in the shared installation directory as in the user .openoffice.org2/user directory.

When the user modifies its OOo environment, sometimes its registry is changed, sometimes not. The installation process should not alter directly the user OOo directory if this change cause alteration in the registry. In this case, the work should be taken in charge by OOo, thus the installation process should invoke OOo API.

=== Default locations ===
Default locations of the objects seem to be specified in the file
<code>$(insturl)/share/registry/schema/org/openoffice/Office/Common.xcs</code>

In most configuration files, some frequently used locations are referenced via variables:

$(insturl) represents the installation directory, eg. /opt/openoffice.org2.0

$(userurl) represents the user configuration directory, eg. /home/smith/.openoffice.org2/user

$(work) stands for the user work directory.

=== Templates ===
The default locations of templates are specified in the following XML part:
<code><pre>
<prop oor:name="Template" oor:type="oor:string-list">
<info>
<desc>Specifies the templates originate from these folders and sub-folders.</desc>
</info>
<value oor:separator=":">$(insturl)/share/template/$(vlang):$(userurl)/template</value>
</prop>
</pre></code>

Templates are objects very similar to other objects produced with the suite. The only differences stand in the 't' in place of 'd' in the second place of the suffix, and in the virtual tree for accessing to them, built from the set of paths declared in the configuration files.

From the time the user changes something in the paths, they are stored in the file
<code>$(userurl)/registry/data/org/openoffice/Office/Common.xcu</code>

=== Autotexts ===

The default location of autotexts is specified in the following XML part:
<code><pre>
<prop oor:name="AutoText" oor:type="oor:string-list">
<info>
<desc>Contains the directory which contains the AutoText modules.</desc>
</info>
<value oor:separator=":">$(insturl)/share/autotext/$(vlang):$(userurl)/autotext</value>
</prop>
</pre></code>

Autotexts are organized in categories. The user can create as many categories as she wants, and ask for storing them in one of the directories declared in the configuration file, provided that she has write access. Each category is implemented in a file named <category_name>.bau which is in fact a zip archive.

Nevertheless, if the category name contains special characters, they are silently dropped from the file name. Thus it is more robust to search the category name in the file BlockList.xml included in the archive.

=== Databases ===

The databases are described in .odb files which may be stored anywhere. this ones are standard OOo archive. The content.xml file describe the data source and some attributes of the database.

The databases are declared in the registry directory, in the file:
<code>

$(userurl)/registry/data/org/openoffice/Office/DataAccess.xcu

</code>

The database name must appear in the "RegisteredNames" node.

<code><pre>
<node oor:name="RegisteredNames">
...
<node oor:name="the_database_name" oor:op="replace">
<prop oor:name="Location" oor:type="xs:string">
<value>file://the/location/of/the/database.odb</value>
</prop>
<prop oor:name="Name" oor:type="xs:string">
<value>the_database_name</value>
</prop>
</node>
...
</node>
</pre></code>

=== Gallery's themes ===

At the moment, managment of themes in OOo seems a little bit twisted.

Themes are stored in three binary files, those format are inherited from StarOffice.

This files are suffixed with .sdg, .sdv and .thm.

The .thm file contains, among binary data, the name of the theme, as given by the user.

The name of each file is of the form <code>sgNNN.xxx</code> where NNN is a number (the same from the three files) and xxx the suffix.

Apparently, the only rule for choosing the number is to obtain unique file names in the target directory.

This implementation is adequate for a local managment of themes, but doesn't give satisfaction when exchanging themes between users. Indeed, the question is: how to detect duplicates during the installation?

; using the file name? : as the file name is, in a way, randomly given during installation, the same theme may be given different names depending on the history of previous installations on different workstations. Furthermore, OOo may have given the same filename to different themes created on different workstations.
; using the name stored in the .thm file? : if this name is too generic, as "people", "events" or "houses", the same name may be given to different themes created by different users.

Thus, at the installation time, it is pertinent to consider the following cases:
; the number and the theme name doesn't exist: to install directly the theme;
; the number already exists and the theme name doesn't exist: to search another discriminatory number;
; the theme name already exists: to ask the user if the existing theme must be overwritten, or the new one renamed, or its installation aborted.
It is important to systematically search for the theme name in all already existing themes.

=== Macros ===
to be completed

=== Toolbars ===
to be completed

=== The package manager ===

At this stage, it is important to consider the package managment provided by OOo V2.

The package manager can import, enable, disable and export packages.

In the package you can store one module containing several libraries of macros.

You can describe additional main menu items, tools menu items and buttons for lauching the macros. The buttons are grouped in one new toolbar.

At the moment, the package manager can't manage templates, autotexts nor gallery themes.

A package is a zip archive.

The root of this archive contains an <code>addons.xcu</code> file whose contains is described [http://api.openoffice.org/docs/DevelopersGuide/Components/Components.htm#1+7+3+3+Configuration here]

== Background ==
This project should not start from zero. Some work has already been done, and here is some non exhaustive reference to it.

* Bernard Marcelly has written a document called [http://documentation.openoffice.org/HOW_TO/index.html "How to Distribute Macros with an Addon"] containg macros making very easy to create a package.

* Didier Dorange-Pattoret has written a [http://www.dmaths.org/modules.php?name=Downloads&d_op=getit&lid=58 macro] allowing to easily install galleries.

* Laurent Godard has written DicOOo which allows to install dictionaries on a workstation, and which is now distributed with OOo V2.

* Philippe Allart has written a [http://adullact.net/frs/download.php/1176/mk_OOo_pack.zip simple bash script] which comply to the proposed
structure below, and which use the tool of Didier Dorange-Pattoret

== Specification of a configuration package ==
=== Layout ===
To be consistent with the technological choices of the developpers team of OOo, it is suggested that the package be implemented as a zip archive.

This archive should contains one directory for each type of object.

Perhaps, it would be a good idea to add a "goodies" directory, allowing to add objects not directly concerned by the configuration process, but which would be very usefull for end users.

Thus, the suggested tree could be as follows:

# /
#* tools allowing installation of the package
#* specifications for installation (location of templates, ...)
## /autotexts/
##* autotexts (.bau files) to be installed
## /packages/
##* packages (.zip files) to be installed
## /databases/
##* databases (.odb files) to be installed and possibly local data
## /templates/
##* templates to be installed
## /autocorr/
##* .dat files containing replacement rules and exceptions
## /wordbooks/
##* dictionaries to be installed
## /fonts/
##* fonts to be installed
## /gallery/
##* themes to be installed
## /goodies/

=== Dependancies ===

The objects in the package are not fully independants ones from others. For instance, a macro may refer to styles coming with a template and be called when the document is created.

Furthermore, some objects in the package may depend on the previous installation of other objects.

Thus, it will be very useful to identify all types of dependancies, and how and where to express them.

=== Specifications for installation ===

At this stage, it is necessary to define what will be specified, and how it will be, for the installation process.

It is useless to invent again the wheel, and it seems a good idea to reuse the [http://api.openoffice.org/docs/DevelopersGuide/Components/Components.htm#1+7+3+3+Configuration structure] of the addons.xcu file used by the package manager.

Indeed, this structure is very generic, in the sense that it doesn't contain specific tags. In fact, it's just a set of two columns tables containing properties/values pairs. Theses tables are organised in tree where each node have a name as an attribute.

Formally, the XML Schema is as follows:

<code>
XML Schema to be described
</code>

Now, the work stands in:
* to define the structure of the tree, and to give a name to each node;
* for each node, to define the content of the table, i.e. the set of properties/values pairs.

== Contributors ==
--[[User:Pallart|Pallart]] 16:34, 6 April 2006 (CEST)

[[category:Extensions]]

Extension Deployment

2006-10-12T08:07:46Z

Sparcmoz: /* Technical context */

== First considerations ==

Extension deployement should not be considered as an independent task.
Indeed, when you need to deploy extensions on a number of workstations, you'll need also to deploy templates, autotexts, gallery themes, and so on, because you'll need to preserve a relative homogeneity. In fact, you'll often need to deploy extensions in the same time you need to deploy templates, autotexts and gallery themes.

This is the reason why it is suggested here to consider the following approach:

1 - to define the structure of a package which aims to deploy in one operation extensions, including macro and toolbars, templates, autotexts and gallery themes;

2 - to define the user interface of an administration tool whose goal is to create such a package;

3 - to define the user interface of a user tool which would enable the end user to install the package on her workstation, or the administrator to install it in the shared installation tree.

== Technical context ==
Before specifying the content of the package, we must keep in mind some technical constraints induced by the implementations of the configuration objects, and the rules for specifying their location.

=== The OOo registry ===
OOo comes with its own registry system.

The registry is implemented in a directory named "registry", as well in the shared installation directory as in the user .openoffice.org2/user directory.

When the user modifies its OOo environment, sometimes its registry is changed, sometimes not. The installation process should not alter directly the user OOo directory if this change cause alteration in the registry. In this case, the work should be taken in charge by OOo, thus the installation process should invoke OOo API.

=== Default locations ===
Default locations of the objects seem to be specified in the file
<code>$(insturl)/share/registry/schema/org/openoffice/Office/Common.xcs</code>

In most configuration files, some frequently used locations are referenced via variables:

$(insturl) represents the installation directory, eg. /opt/openoffice.org2.0

$(userurl) represents the user configuration directory, eg. /home/smith/.openoffice.org2/user

$(work) stands for the user work directory.

=== Templates ===
The default locations of templates are specified in the following XML part:
<code><pre>
<prop oor:name="Template" oor:type="oor:string-list">
<info>
<desc>Specifies the templates originate from these folders and sub-folders.</desc>
</info>
<value oor:separator=":">$(insturl)/share/template/$(vlang):$(userurl)/template</value>
</prop>
</pre></code>

Templates are objects very similar to other objects produced with the suite. The only differences stand in the 't' in place of 'd' in the second place of the suffix, and in the virtual tree for accessing to them, built from the set of paths declared in the configuration files.

From the time the user changes something in the paths, they are stored in the file
<code>$(userurl)/registry/data/org/openoffice/Office/Common.xcu</code>

=== Autotexts ===

The default location of autotexts is specified in the following XML part:
<code><pre>
<prop oor:name="AutoText" oor:type="oor:string-list">
<info>
<desc>Contains the directory which contains the AutoText modules.</desc>
</info>
<value oor:separator=":">$(insturl)/share/autotext/$(vlang):$(userurl)/autotext</value>
</prop>
</pre></code>

Autotexts are organized in categories. The user can create as many categories as she wants, and ask for storing them in one of the directories declared in the configuration file, provided that she has write access. Each category is implemented in a file named <category_name>.bau which is in fact a zip archive.

Nevertheless, if the category name contains special characters, they are silently dropped from the file name. Thus it is more robust to search the category name in the file BlockList.xml included in the archive.

=== Databases ===

The databases are described in .odb files which may be stored anywhere. this ones are standard OOo archive. The content.xml file describe the data source and some attributes of the database.

The databases are declared in the registry directory, in the file:
<code>

$(userurl)/registry/data/org/openoffice/Office/DataAccess.xcu

</code>

The database name must appear in the "RegisteredNames" node.

<code><pre>
<node oor:name="RegisteredNames">
...
<node oor:name="the_database_name" oor:op="replace">
<prop oor:name="Location" oor:type="xs:string">
<value>file://the/location/of/the/database.odb</value>
</prop>
<prop oor:name="Name" oor:type="xs:string">
<value>the_database_name</value>
</prop>
</node>
...
</node>
</pre></code>

=== Gallery's themes ===

At the moment, managment of themes in OOo seems a little bit twisted.

Themes are stored in three binary files, those format are inherited from StarOffice.

This files are suffixed with .sdg, .sdv and .thm.

The .thm file contains, among binary data, the name of the theme, as given by the user.

The name of each file is of the form <code>sgNNN.xxx</code> where NNN is a number (the same from the three files) and xxx the suffix.

Apparently, the only rule for choosing the number is to obtain unique file names in the target directory.

This implementation is adequate for a local managment of themes, but doesn't give satisfaction when exchanging themes between users. Indeed, the question is: how to detect duplicates during the installation?

; using the file name? : as the file name is, in a way, randomly given during installation, the same theme may be given different names depending on the history of previous installations on different workstations. Furthermore, OOo may have given the same filename to different themes created on different workstations.
; using the name stored in the .thm file? : if this name is too generic, as "people", "events" or "houses", the same name may be given to different themes created by different users.

Thus, at the installation time, it is pertinent to consider the following cases:
; the number and the theme name doesn't exist: to install directly the theme;
; the number already exists and the theme name doesn't exist: to search another discriminatory number;
; the theme name already exists: to ask the user if the existing theme must be overwritten, or the new one renamed, or its installation aborted.
It is important to systematically search for the theme name in all already existing themes.

=== Macros ===
to be completed

=== Toolbars ===
to be completed

=== The package manager ===

At this stage, it is important to consider the package managment provided by OOo V2.

The package manager can import, enable, disable and export packages.

In the package you can store one module containing several libraries of macros.

You can describe additional main menu items, tools menu items and buttons for lauching the macros. The buttons are grouped in one new toolbar.

At the moment, the package manager can't manage templates, autotexts nor gallery themes.

A package is a zip archive.

The root of this archive contains an <code>addons.xcu</code> file whose contains is described [http://api.openoffice.org/docs/DevelopersGuide/Components/Components.htm#1+7+3+3+Configuration here]

== Background ==
This project should not start from zero. Some work has already been done, and here is some non exhaustive reference to it.

* Bernard Marcelly has written a document called [http://documentation.openoffice.org/HOW_TO/index.html "How to Distribute Macros with an Addon"] containg macros making very easy to create a package.

* Didier Dorange-Pattoret has written a [http://www.dmaths.org/modules.php?name=Downloads&d_op=getit&lid=58 macro] allowing to easily install galleries.

* Laurent Godard has written DicOOo which allows to install dictionaries on a workstation, and which is now distributed with OOo V2.

* Philippe Allart has written a [http://adullact.net/frs/download.php/1176/mk_OOo_pack.zip simple bash script] which comply to the proposed
structure below, and which use the tool of Didier Dorange-Pattoret

== Specification of a configuration package ==
=== Layout ===
To be consistent with the technological choices of the developpers team of OOo, it is suggested that the package be implemented as a zip archive.

This archive should contains one directory for each type of object.

Perhaps, it would be a good idea to add a "goodies" directory, allowing to add objects not directly concerned by the configuration process, but which would be very usefull for end users.

Thus, the suggested tree could be as follows:

# /
#* tools allowing installation of the package
#* specifications for installation (location of templates, ...)
## /autotexts/
##* autotexts (.bau files) to be installed
## /packages/
##* packages (.zip files) to be installed
## /databases/
##* databases (.odb files) to be installed and possibly local data
## /templates/
##* templates to be installed
## /autocorr/
##* .dat files containing replacement rules and exceptions
## /wordbooks/
##* dictionaries to be installed
## /fonts/
##* fonts to be installed
## /gallery/
##* themes to be installed
## /goodies/

=== Dependancies ===

The objects in the package are not fully independants ones from others. For instance, a macro may refer to styles coming with a template and be called when the document is created.

Furthermore, some objects in the package may depend on the previous installation of other objects.

Thus, it will be very useful to identify all types of dependancies, and how and where to express them.

=== Specifications for installation ===

At this stage, it is necessary to define what will be specified, and how it will be, for the installation process.

It is useless to invent again the wheel, and it seems a good idea to reuse the [http://api.openoffice.org/docs/DevelopersGuide/Components/Components.htm#1+7+3+3+Configuration structure] of the addons.xcu file used by the package manager.

Indeed, this structure is very generic, in the sens that it doesn't contain specific tags. In fact, it's just a set of two columns tables containing properties/values pairs. Theses tables are organised in tree where each node have a name as an attribut.

Formally, the XML Schema is as follows:

<code>
XML Schema to be described
</code>

Now, the work stands in:
* to define the structure of the tree, and to give a name to each node;
* for each node, to define the content of the table, i.e. the set of properties/values pairs.

== Contributors ==
--[[User:Pallart|Pallart]] 16:34, 6 April 2006 (CEST)

[[category:Extensions]]