| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> | |
| <HTML> | |
| <head> | |
| <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252"> | |
| <TITLE>StarOffice / OpenOffice.org “Q” Product Concept</TITLE> | |
| <META NAME="GENERATOR" CONTENT="StarOffice 7 (Win32)"> | |
| <META NAME="AUTHOR" CONTENT="Lutz Höger"> | |
| <META NAME="CREATED" CONTENT="20030730;18520000"> | |
| <META NAME="CHANGEDBY" CONTENT="Jörg Heilig"> | |
| <META NAME="CHANGED" CONTENT="20030808;11075370"> | |
| <STYLE> | |
| <!-- | |
| @page { size: 21cm 29.7cm; margin: 2cm } | |
| P { margin-bottom: 0.21cm } | |
| P.western { font-size: 12pt; so-language: en-US } | |
| H1 { margin-top: 0.62cm; margin-bottom: 0.41cm; page-break-before: always } | |
| H1.western { font-family: "Albany", sans-serif; font-size: 16pt; so-language: en-US } | |
| H1.cjk { font-size: 16pt } | |
| H1.ctl { font-size: 16pt } | |
| H2 { margin-top: 0.82cm; margin-bottom: 0.21cm } | |
| H2.western { font-family: "Albany", sans-serif; font-size: 14pt; so-language: en-US; font-style: normal } | |
| H2.cjk { font-family: "HG Mincho Light J"; font-size: 14pt; font-style: italic } | |
| H2.ctl { font-family: "Arial Unicode MS"; font-size: 14pt; font-style: italic } | |
| H3 { margin-bottom: 0.21cm } | |
| H3.western { font-family: "Albany", sans-serif; font-size: 12pt; so-language: en-US } | |
| H3.cjk { font-family: "HG Mincho Light J" } | |
| H3.ctl { font-family: "Arial Unicode MS" } | |
| H4 { margin-bottom: 0.21cm } | |
| H4.western { font-family: "Albany", sans-serif; so-language: en-US; font-style: normal } | |
| H4.cjk { font-family: "HG Mincho Light J"; font-size: 11pt; font-style: italic } | |
| H4.ctl { font-family: "Arial Unicode MS"; font-size: 11pt; font-style: italic } | |
| P.sdfootnote-western { margin-left: 0.5cm; text-indent: -0.5cm; margin-bottom: 0cm; font-size: 10pt; so-language: en-US } | |
| P.sdfootnote-cjk { margin-left: 0.5cm; text-indent: -0.5cm; margin-bottom: 0cm; font-size: 10pt } | |
| P.sdfootnote-ctl { margin-left: 0.5cm; text-indent: -0.5cm; margin-bottom: 0cm; font-size: 10pt } | |
| A.sdfootnoteanc { font-size: 57% } | |
| --> | |
| </STYLE> | |
| </head> | |
| <body LANG="de-DE" DIR="LTR"> | |
| <P LANG="en-US" ALIGN=LEFT STYLE="margin-top: 0.42cm; page-break-after: avoid"> | |
| <SDFIELD TYPE=DOCINFO SUBTYPE=TITLE>StarOffice / OpenOffice.org “Q” Product Concept</SDFIELD></P> | |
| <P LANG="en-US" CLASS="western">Lutz Hoeger, August 2003</P> | |
| <DIV ID="Table of Contents1" DIR="LTR" STYLE="background: transparent"> | |
| <DIV ID="Table of Contents1_Head" DIR="LTR"> | |
| <P LANG="en-US" STYLE="margin-top: 0.42cm; font-weight: medium; page-break-before: auto; page-break-after: avoid"> | |
| <FONT FACE="Albany, sans-serif"><FONT SIZE=4 STYLE="font-size: 16pt">Table | |
| of Contents</FONT></FONT></P> | |
| </DIV> | |
| <P LANG="en-US" STYLE="margin-bottom: 0cm"><FONT SIZE=3><A HREF="#1.Introduction|outline">1 | |
| Introduction</A> 2</FONT></P> | |
| <P LANG="en-US" STYLE="margin-bottom: 0cm"><FONT SIZE=3><A HREF="#2.Executive Summary|outline">2 | |
| Executive Summary</A> 3</FONT></P> | |
| <P LANG="en-US" STYLE="margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.Concept Overview|outline">3 | |
| Concept Overview</A> 4</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.Key Drivers (P2)|outline">3.1 | |
| Key Drivers (P2)</A> 4</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.1.Microsoft Office Interoperability|outline">3.1.1 | |
| Microsoft Office Interoperability</A> 4</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.2.Usability|outline">3.1.2 | |
| Usability</A> 4</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.3.Performance|outline">3.1.3 | |
| Performance</A> 5</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.4.Programmability|outline">3.1.4 | |
| Programmability</A> 5</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.1.5.Integration into Gnome Desktop and Microsoft Windows|outline">3.1.5 | |
| Integration into Gnome Desktop and Microsoft Windows</A> 5</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.General Improvements (P3)|outline">3.2 | |
| General Improvements (P3)</A> 5</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.1.Stability and Quality|outline">3.2.1 | |
| Stability and Quality</A> 5</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.2.Administration and Deployment|outline">3.2.2 | |
| Administration and Deployment</A> 6</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.3.Modern Look & Feel|outline">3.2.3 | |
| Modern Look & Feel</A> 6</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.2.4.Integration (Plugins, 3rd party applications)|outline">3.2.4 | |
| Integration (Plugins, 3rd party applications)</A> 6</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.Upcoming Opportunities (P4 and P5)|outline">3.3 | |
| Upcoming Opportunities (P4 and P5)</A> 7</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.1.Asian and CTL languages|outline">3.3.1 | |
| Asian and CTL languages</A> 7</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.2.Digital Signatures|outline">3.3.2 | |
| Digital Signatures</A> 7</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.3.Compelling upgrade features (e.g. multi media, OCR, DB)|outline">3.3.3 | |
| Compelling upgrade features (e.g. multi media, OCR, DB)</A> 8</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.4.Intelligent Document Tags |outline">3.3.4 | |
| Intelligent Document Tags </A> 8</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#3.3.5.Collaboration|outline">3.3.5 | |
| Collaboration</A> 8</FONT></P> | |
| <P LANG="en-US" STYLE="margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.Concept Details|outline">4 | |
| Concept Details</A> 9</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.Key Drivers|outline">4.1 | |
| Key Drivers</A> 9</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.1.Improving Microsoft Office Interoperability|outline">4.1.1 | |
| Improving Microsoft Office Interoperability</A> 9</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.2.Usability|outline">4.1.2 | |
| Usability</A> 14</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.3.Performance|outline">4.1.3 | |
| Performance</A> 17</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.4.Programmability|outline">4.1.4 | |
| Programmability</A> 18</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.1.5.Integration into the Gnome Desktop, and Microsoft Windows|outline">4.1.5 | |
| Integration into the Gnome Desktop, and Microsoft Windows</A> 20</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.General Improvements|outline">4.2 | |
| General Improvements</A> 22</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.1.Stability and Quality|outline">4.2.1 | |
| Stability and Quality</A> 22</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.2.Administration and Deployment|outline">4.2.2 | |
| Administration and Deployment</A> 22</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.3.Modern Look & Feel|outline">4.2.3 | |
| Modern Look & Feel</A> 23</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.2.4.Integration (Plug-ins, 3rd party applications)|outline">4.2.4 | |
| Integration (Plug-ins, 3rd party applications)</A> 25</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 0.5cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.Upcoming Opportunities|outline">4.3 | |
| Upcoming Opportunities</A> 27</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.1.Asian and CTL languages|outline">4.3.1 | |
| Asian and CTL languages</A> 27</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.2.Digital Signatures|outline">4.3.2 | |
| Digital Signatures</A> 29</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.3.Compelling upgrade features (e.g. multi media, OCR, DB)|outline">4.3.3 | |
| Compelling upgrade features (e.g. multi media, OCR, DB)</A> 30</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.4.Web Services|outline">4.3.4 | |
| Web Services</A> 30</FONT></P> | |
| <P LANG="en-US" STYLE="margin-left: 1cm; margin-bottom: 0cm"><FONT SIZE=3><A HREF="#4.3.5.Intelligent Document Tags |outline">4.3.5 | |
| Intelligent Document Tags </A> 31</FONT></P> | |
| </DIV> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <H1 LANG="en-US" CLASS="western"><A NAME="1.Introduction|outline"></A> | |
| 1 Introduction</H1> | |
| <P LANG="en-US" CLASS="western">(Lutz Hoeger, July 2003)</P> | |
| <P LANG="en-US" CLASS="western">This document provides a | |
| comprehensive, high-level overview of concepts for features in the | |
| next release of StarOffice / OpenOffice.org (SO/OOo) currently in the | |
| planning phase.</P> | |
| <P LANG="en-US" CLASS="western">The specification for such a large | |
| project covers many areas and many details. Consequently, it will | |
| not provide a complete list of all the details, but occasionally will | |
| include some details to aid in clarifying the discussion. Many more | |
| details have already been and will soon be submitted as feature | |
| issues in IssueZilla, completing the picture.</P> | |
| <P LANG="en-US" CLASS="western">In compiling this document, we've | |
| gathered feedback from users, developers and existing or potential | |
| customers: in direct communication at trade shows like Linux World, | |
| during events like the OpenOffice.org Conference, using surveys, and | |
| last but not least in discussions on the OpenOffice.org mailing | |
| lists. We then put together ideas to respond to these requirements, | |
| prioritized them, and finally assembled it all into the Product | |
| Concept. | |
| </P> | |
| <P LANG="en-US" CLASS="western">During the prioritization for this | |
| release, we had to strike a balance between the importance of each | |
| requirement and the goal of an 18-month cycle for releases. We've | |
| learned from discussion, particularly with enterprise customers, that | |
| this is their expected “heartbeat” for major releases of | |
| an office productivity suite.</P> | |
| <P LANG="en-US" CLASS="western">The structure of this document | |
| provides different levels of detail about the concept:</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">The Executive Summary (0.5 | |
| pages) is ideal for a “Got-only-5-minutes-hurry-up!” | |
| reader who wants to know what the overall direction is. It's a brief | |
| description of our answers to the highest priority requirements. | |
| This section contains neither any details nor a full list of areas | |
| we plan to work on. | |
| </P> | |
| <LI><P LANG="en-US" CLASS="western">The Concept Overview section | |
| (five pages) explains the prioritization and discusses all | |
| requirement areas. This section should provide a good “30-minute” | |
| overview of the responses to the requirements. While leaving out | |
| many of the details, it covers all the areas.</P> | |
| <LI><P LANG="en-US" CLASS="western">And finally, the Detailed | |
| Concept section (about 20 pages) completes the previous section with | |
| a much more detailed view into all aspects of the requirements, with | |
| some background information if available, and even illustrates parts | |
| of the concept by drilling down on some details.</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">Before beginning, let me introduce | |
| one convention used throughout this document. Code name “Geordi” | |
| stands for SO/OOo 1.1, and “Q” for the next major release | |
| after 1.1.</P> | |
| <P LANG="en-US" CLASS="western">And one final note, you'll find the | |
| document chapters tagged with different author names reflecting that | |
| many people contributed to this document. We all would be happy to | |
| get your feedback. So if you want to tell us something we could have | |
| done better, we may have forgotten or just want to ask a question, | |
| please refer in your comments to the section on which you are | |
| commenting. This will help us identify the person who can best | |
| respond to your feedback.</P> | |
| <H1 LANG="en-US" CLASS="western"><A NAME="2.Executive%20Summary|outline"></A> | |
| 2 Executive Summary</H1> | |
| <P LANG="en-US" CLASS="western">(Lutz Hoeger, July 2003)</P> | |
| <P LANG="en-US" CLASS="western">“Q” will be the next | |
| major release of StarOffice / OpenOffice.org (SO/OOo). Listed below | |
| are the concepts to address the key requirements of our existing and | |
| potential customers. These CTQs (Critical to Quality) are all | |
| centered around the main theme: migration to “Q”.</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Lower cost of interoperability | |
| with Microsoft Office. By providing better interoperability with | |
| Microsoft Office, “Q” will significantly decrease the | |
| cost of conversion between the two applications.</P> | |
| <LI><P LANG="en-US" CLASS="western">Lower cost of retraining<BR>“Q” | |
| will lower the training needs for average users by enhancing feature | |
| areas toward better standards of interaction. This will make the | |
| migration to SO/OOo cheaper.</P> | |
| <LI><P LANG="en-US" CLASS="western">Better Performance<BR>“Q” | |
| will come with noticeable improvements in startup performance as | |
| well as time to open or save a document.</P> | |
| <LI><P LANG="en-US" CLASS="western">General usability | |
| improvements<BR>Redesigning parts of “Q” to increase | |
| usability will increase productivity of the average user and the | |
| overall level of satisfaction when working with the product.</P> | |
| <LI><P LANG="en-US" CLASS="western">Enhanced programmability<BR>“Q” | |
| will make it easier to automate typical office suite tasks. By | |
| improved extensibility, “Q” will be better customizable | |
| to individual customer's needs.</P> | |
| <LI><P LANG="en-US" CLASS="western">Better integration into desktop | |
| systems<BR>Particularly on Gnome desktop systems, “Q” | |
| will integrate better with the existing infrastructure. This leads | |
| to a more intuitive use of “Q” for users who are already | |
| familiar with the desktop system, and provides better | |
| interoperability between SO/OOo and other desktop applications.</P> | |
| </UL> | |
| <H1 LANG="en-US" CLASS="western"><A NAME="3.Concept%20Overview|outline"></A> | |
| 3 Concept Overview</H1> | |
| <P LANG="en-US" CLASS="western">This section explains the | |
| prioritization and provides a general overview about all concept | |
| areas. More details are given in section 4, Concept Details.</P> | |
| <P LANG="en-US" CLASS="western">The priorities used in this concept | |
| have been set according to the general guidelines of priorities from | |
| different bug tracking systems, including IssueZilla. Although the | |
| <SPAN LANG="en-US"><FONT SIZE=3>latter</FONT></SPAN> doesn't | |
| specifically exclude feature issues from having priority 1, a P1 | |
| issue normally means that an area is broken and cannot be worked | |
| with. Typically P1 is reserved for bugs only. That's why the scale | |
| for requirement priorities ranks from P2 (highest) to P5 (lowest). We | |
| assigned them in the following way.</P> | |
| <H2 LANG="en-US" CLASS="western"><A NAME="3.1.Key%20Drivers%20(P2)|outline"></A> | |
| 3.1 Key Drivers (P2)</H2> | |
| <P LANG="en-US" CLASS="western">The overarching motto and strategy | |
| for this release is to lower the barrier for customers to migrate to | |
| StarOffice/OpenOffice.org (SO/OOo). Our concept addresses this at | |
| various levels, in different areas of the product. The following | |
| areas describe the key drivers for “Q” - the areas that | |
| we hear about most in our customer research. These are the areas with | |
| highest priority and also often the highest effort in development | |
| engineering. | |
| </P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.1.1.Microsoft%20Office%20Interoperability|outline"></A> | |
| 3.1.1 Microsoft Office Interoperability</H3> | |
| <P LANG="en-US" CLASS="western">(Dieter Loeschky, April 2003)</P> | |
| <P LANG="en-US" CLASS="western">Interoperability between Microsoft | |
| Office and SO/OOo is generally influenced by three factors. The | |
| first factor is the quality of the filter component, that is, the | |
| quality of the component that translates the content and structure of | |
| a Microsoft Office document into the content and structure of a | |
| SO/OOo document. The second factor is the compatibility of the | |
| feature set of the application in Microsoft Office versus the | |
| corresponding SO/OOo application. The third factor is the behavior | |
| or interpretation of features that exist in both applications. Even | |
| if another application and SO/OOo both support a certain feature, | |
| there might be differences in the way the feature is actually | |
| applied, so that documents in fact might look different although they | |
| have exactly the same values stored for the feature within their text | |
| engines. | |
| </P> | |
| <P LANG="en-US" CLASS="western">One (already resolved) example of | |
| this is the upper paragraph margin that exists in Microsoft Word and | |
| SO/OOo Writer. The <SPAN LANG="en-US"><FONT SIZE=3>latter</FONT></SPAN>, | |
| like many DTP and professional word processing applications, ignores | |
| this value for the first paragraph of a page. Microsoft Word does | |
| not. The result of this is that the documents look different, | |
| although exactly the same values are stored in both text engines.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.1.2.Usability|outline"></A> | |
| 3.1.2 Usability</H3> | |
| <P LANG="en-US" CLASS="western">(Matthias Mueller-Prove, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">“Q” will change its | |
| overall appearance in order to improve the usability for the majority | |
| of non-SO/OOo customers. These changes affect the menu structure, the | |
| toolbar User Interface, the terminology, and finally the overall | |
| window layout. | |
| </P> | |
| <P LANG="en-US" CLASS="western">In general, usability is about task | |
| conformance, familiarity, predictability, flexibility, robustness, | |
| customizability, and learnability. Several minor usability | |
| improvements support the usability of SO/OOo in aspects of these | |
| usability qualities. All new features will be evaluated against these | |
| qualities by the Sun StarOffice User Experience Team.</P> | |
| <P LANG="en-US" CLASS="western">Task conformance pushes us to | |
| reconsider the necessary steps for an action and reduce the number of | |
| mouse clicks in “Q” as much as possible. Predictability | |
| demands that we strive for a consistent user interface. We will | |
| provide a conceptual model that is predictable and consistent for all | |
| SO/OOo applications instead of conforming with the majority of | |
| competing applications. On the other hand, predictability calls for | |
| conformance with styleguides for the target platforms.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.1.3.Performance|outline"></A> | |
| 3.1.3 Performance</H3> | |
| <P LANG="en-US" CLASS="western">(Matthias Huetsch, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo will improve its performance | |
| in four areas that are especially important to customers. The two | |
| most visible areas of improvement will be decreasing the Startup Time | |
| and Document Open/Save Time. The third area of improvement will be | |
| Responsiveness in rendering more complex drawing objects as they, for | |
| example, occur in presentations. The fourth area is in the | |
| Scalability of large scale multi-user deployments like on Citrix, | |
| Tarantella, and SunRay servers. | |
| </P> | |
| <P LANG="en-US" CLASS="western">The performance improvements in the | |
| first three areas were identified as being mostly of an architectural | |
| nature. Significant improvement in any of these areas can be | |
| achieved through either refactoring the current architecture, or | |
| replacing architecture. The fourth area of scalability issues | |
| originates in a number of areas that can be addressed individually.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.1.4.Programmability|outline"></A> | |
| 3.1.4 Programmability</H3> | |
| <P LANG="en-US" CLASS="western">(Kay Ramme, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">Programmability describes the | |
| possibility of usinge SO/OOo or parts of it in custom solutions | |
| programmatically. The underlying technology for SO/OOo | |
| programmability is the SO/OOo component model UNO (Universal Network | |
| Objects) and the SO/OOo API . “Q” will make it easier | |
| on many levels to create solutions utilizing UNO and SO/OOo's API. | |
| This will be achieved through improved language bindings, IDE | |
| integration, easier deployment of add-on components into a SO/OOo | |
| installation, and a new scripting framework that allows use of other | |
| languages in addition to BASIC for scripting purposes.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.1.5.Integration%20into%20Gnome%20Desktop%20and%20Microsoft%20Windows|outline"></A> | |
| 3.1.5 Integration into Gnome Desktop and Microsoft Windows</H3> | |
| <P LANG="en-US" CLASS="western">(Christof Pintaske, June 2003)</P> | |
| <P LANG="en-US" CLASS="western">The overall requirement is to provide | |
| an easy to use desktop with an appealing and modern Look and Feel | |
| that is consistent throughout all applications.</P> | |
| <P LANG="en-US" CLASS="western">To achieve a better system | |
| integration, "Q" will make increased use of information and | |
| infrastructure that is provided with the Gnome desktop instead of | |
| creating platform independent solutions. | |
| </P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <H2 LANG="en-US" CLASS="western"><A NAME="3.2.General%20Improvements%20(P3)|outline"></A> | |
| 3.2 General Improvements (P3)</H2> | |
| <P LANG="en-US" CLASS="western">The next areas are still mandatory | |
| requirements. They fall under general improvements, that help | |
| facilitate a successful deployment of SO/OOo.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.2.1.Stability%20and%20Quality|outline"></A> | |
| 3.2.1 Stability and Quality</H3> | |
| <P LANG="en-US" CLASS="western">(Matthias Huetsch, June 2003)</P> | |
| <P LANG="en-US" CLASS="western">“Q” improves stability | |
| and quality by addressing the response to SO/OOo crashes with | |
| unsaved documents, which can result in lost data. Currently, SO/OOo | |
| performs an emergency backup of those documents only. Upon next | |
| startup, a Document Recovery dialog then offers to restore those | |
| documents to a previously known good state.</P> | |
| <P LANG="en-US" CLASS="western">The probability of data loss due to a | |
| crash will be reduced by augmenting the current emergency backup with | |
| regular backup copies of documents. The Document Recovery dialog | |
| will be improved by providing more guidance and feedback while | |
| restoring documents. An Error Report tool, available in the “Geordi” | |
| release, should provide data to help identify and eliminate crash | |
| causes.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.2.2.Administration%20and%20Deployment|outline"></A> | |
| 3.2.2 Administration and Deployment</H3> | |
| <P LANG="en-US" CLASS="western">(Dirk Grobler, Christof Pintaske, May | |
| 2003)</P> | |
| <P LANG="en-US" CLASS="western">With regard to deployment, "Geordi" | |
| offers a platform independent installation process, which can not | |
| easily be managed by any kind of management software. Instead of | |
| adding additional management capabilities in this area, SO/OOo "Q" | |
| changes the installation process. The platform independent | |
| installation is replaced by the support for standard, platform | |
| dependent installation routines - so called native installers - and | |
| their native installation packages. These are the Solaris Package | |
| (pkg) installation, the Linux RPM package manager (RPM) installation, | |
| and the Microsoft Installer (MSI) installation.</P> | |
| <P LANG="en-US" CLASS="western">The advantage of this approach is to | |
| leverage already existing deployment technology based on those native | |
| formats. With "Q", administrators will be able to install | |
| "Q" with their existing tooling.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.2.3.Modern%20Look%20&%20Feel|outline"></A> | |
| 3.2.3 Modern Look & Feel</H3> | |
| <P LANG="en-US" CLASS="western">(Christian Jansen, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">Users are asking for various look and | |
| feel improvements, which fit mainly into three categories.</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">The SO/OOo look and feel themes | |
| should be more intuitive. | |
| </P> | |
| <LI><P LANG="en-US" CLASS="western">The user interface should be | |
| better organized and emphasize the important information.</P> | |
| <LI><P LANG="en-US" CLASS="western">SO/OOo needs to provide more | |
| user feedback and responses.</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">For SO/OOo "Q" we will | |
| address these areas by improving the look & feel and adjusting it | |
| to the expectations of the majority of non-SO/OOo users while | |
| balancing it with the expectations of current SO/OOo users.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.2.4.Integration%20(Plugins,%203rd%20party%20applications)|outline"></A> | |
| 3.2.4 Integration (Plugins, 3rd party applications)</H3> | |
| <P LANG="en-US" CLASS="western">(Mathias Bauer, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">Integrating SO/OOo with 3rd party | |
| applications can be done on several levels:</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Create import and export filters | |
| to convert between the file formats.</P> | |
| <LI><P LANG="en-US" CLASS="western">Use the system clipboard for | |
| data exchange.</P> | |
| <LI><P LANG="en-US" CLASS="western">Use external communication means | |
| like pipes, files, command line parameters etc. to establish a work | |
| flow that uses SO/OOo and other applications together.</P> | |
| <LI><P LANG="en-US" CLASS="western">Link or embed data or files from | |
| other applications in(to) SO/OOo documents and vice versa.</P> | |
| <LI><P LANG="en-US" CLASS="western">Use the SO/OOo API or the API of | |
| other applications to integrate on a functional level.</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">The first two options are already | |
| widely used in SO/OOo. Adding support for more 3rd party applications | |
| simply means providing the necessary conversion routines and will not | |
| be discussed here in detail.</P> | |
| <P LANG="en-US" CLASS="western">External communication means are | |
| usually tailored for every single use case. Examples for this kind of | |
| integration are external e-mail clients. | |
| </P> | |
| <P LANG="en-US" CLASS="western">3rd party integration on an API level | |
| can be done in two ways:</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">the 3rd party application uses | |
| UNO to connect to SO/OOo and uses its APIs to get the wanted | |
| functionality</P> | |
| <LI><P LANG="en-US" CLASS="western">SO/OOo creates adapters to use | |
| the middleware technology of the 3rd party application (like Com, | |
| .NET or SOAP).</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">This concept document concentrates on | |
| the first approach. The latter one is addressed by UNO bridges like | |
| the ones we have (or will develop) for OLE Automation, .NET or SOAP.</P> | |
| <H2 LANG="en-US" CLASS="western"><A NAME="3.3.Upcoming%20Opportunities%20(P4%20and%20P5)|outline"></A> | |
| 3.3 Upcoming Opportunities (P4 and P5)</H2> | |
| <P LANG="en-US" CLASS="western">The final part of the concept | |
| contains optional enhancements in the area of upcoming opportunities | |
| that we can foresee today.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.3.1.Asian%20and%20CTL%20languages|outline"></A> | |
| 3.3.1 Asian and CTL languages</H3> | |
| <P LANG="en-US" CLASS="western">(Falko Tesch, July 2003)</P> | |
| <P LANG="en-US" CLASS="western">Internationalization (I18N) describes | |
| the ability and availability of a product for international markets. | |
| This means that the product has to comply with 3 important issues:</P> | |
| <OL> | |
| <LI><P LANG="en-US" CLASS="western">It needs to address locale | |
| specific features and customs.</P> | |
| <LI><P LANG="en-US" CLASS="western">It needs a good and | |
| comprehensive documentation and UI.</P> | |
| <LI><P LANG="en-US" CLASS="western">It needs localized tools and | |
| support for local utensils and tools, such as IME (input method | |
| engine) and the like.</P> | |
| </OL> | |
| <P LANG="en-US" CLASS="western">StarSuite 6.0 and "Geordi" | |
| support IME that enables the input of East-Asian scripting like | |
| Chinese, Korean and Japanese. Furthermore "Geordi" pays | |
| tribute to the most needed features for text processing in Asia, like | |
| vertical text layout, Ruby support, specific font effects and other. | |
| While "Geordi" covers features and needs for CJK markets, | |
| it takes only the first steps towards a specialized offer to the CTL | |
| (complex text layout) markets (Arabic, Hebrew, Thai, Hindi etc.). “Q” | |
| will complete the CJK (Chinese, Japanese, Korean) feature set and | |
| complete CTL features started with "Geordi":</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Refining already existing CJK | |
| features and adding competitive features to fully compete with other | |
| office productivity suites for CJK, like local office software, such | |
| as Hangul (Korea), Ichitaro (Japan) and WPS Office (PR China).</P> | |
| <LI><P LANG="en-US" CLASS="western">Introducing full localized CTL | |
| support for Arabic and Hebrew-spoken countries as well as for India | |
| (Hindi plus 6 other major languages spoken)</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">With “Geordi”, SO/OOo | |
| demonstrates it's suitability for the CTL markets (e.g. Arabic and | |
| Hebrew regions)</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.3.2.Digital%20Signatures|outline"></A> | |
| 3.3.2 Digital Signatures</H3> | |
| <P LANG="en-US" CLASS="western">(Michael Brauer, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">Security for office document content | |
| can be divided into two features, digital signatures and encryption. | |
| </P> | |
| <P LANG="en-US" CLASS="western">Digital signatures themselves are a | |
| relatively new topic for office applications. The requirement to | |
| protect data from being modified has existed for many years , | |
| however. In the past, it has been addressed by features that | |
| protected documents from being edited within the office application. | |
| With digital signatures, these features will be enhanced to offer | |
| secure protection of document content, inside SO/OOo, and outside of | |
| it.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.3.3.Compelling%20upgrade%20features%20(e.g.%20multi%20media,%20OCR,%20DB)|outline"></A> | |
| 3.3.3 Compelling upgrade features (e.g. multi media, OCR, DB)</H3> | |
| <P LANG="en-US" CLASS="western">Encryption is a feature that has been | |
| supported by office applications for a long time. Enhancement in | |
| this area mainly affected the encryption algorithm themselves, to | |
| make them more secure. However, since there was no standardized way | |
| in which encryption algorithms are applied to documents, processing | |
| such documents outside an office application was complex. By | |
| supporting new XML encryption standards, and due to SO/OOo's XML file | |
| format, this will become much easier.</P> | |
| <P LANG="en-US" CLASS="western">Although the requirements cover many | |
| improvements and new features for SO/OOo, this section is reserved | |
| for features that make the upgrade particularly compelling for | |
| existing SO/OOo customers. Since we don't know of any specific | |
| customer requirements that fit exclusively into this section, it's | |
| content will be determined later.Web Services</P> | |
| <P LANG="en-US" CLASS="western">(Kai Sommerfeld, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">Web Services become more and more | |
| important as they easily can be used to establish B2B communication | |
| in a platform independent way. There are lots of Web Services | |
| available that offer a broad range of functionality, for example | |
| Google offers a Web Service for searching the Internet.</P> | |
| <P LANG="en-US" CLASS="western">It would be valuable, if SO/OOo could | |
| act as a Web Services client, meaning that it could access and use | |
| arbitrary Web Services.</P> | |
| <P LANG="en-US" CLASS="western">Additionally it could be interesting | |
| to offer SO/OOo's functionality as Web Services. An example for such | |
| a Web Service is a document transformation service, which would be | |
| based on SO/OOo's document import and export.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.3.4.Intelligent%20Document%20Tags%20|outline"></A> | |
| 3.3.4 Intelligent Document Tags | |
| </H3> | |
| <P LANG="en-US" CLASS="western">(Andreas Martens, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo will support an interface for | |
| intelligent and extensible document tags. This interface will allow | |
| third party vendors to offer additional information/services on the | |
| basis of textual analysis. This is a win-win situation. SO/OOo gets a | |
| feature without the effort of reinventing the wheel. For third party | |
| vendors it creates a business opportunity around SO/OOo.</P> | |
| <P LANG="en-US" CLASS="western">Initially, all words/phrases which | |
| are recognized as keywords will be underlined. The user is able to | |
| open context menus for these marked words and to choose additional | |
| actions.</P> | |
| <P LANG="en-US" CLASS="western">Example: A vendor offers a component | |
| with different dictionaries (technical, juristic, medicinal). The | |
| SO/OOo document will be scanned for entries in these dictionaries. | |
| For marked words the context menu contains the names of the | |
| dictionaries where the word has been found. The user chooses a | |
| dictionary and the component displays the complete entry.</P> | |
| <P LANG="en-US" CLASS="western">Example: The supporting component is | |
| based on a customer list. If the name of a customer is present in a | |
| SO/OOo document it will be underlined. The context menu may offer | |
| actions like “address”, “send email”, “show | |
| business volumes”, “show last order” et cetera. The | |
| chosen information will be displayed or another program like an email | |
| client will be started. | |
| </P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="3.3.5.Collaboration|outline"></A> | |
| 3.3.5 Collaboration</H3> | |
| <P LANG="en-US" CLASS="western">To be completed later</P> | |
| <H1 LANG="en-US" CLASS="western"><A NAME="4.Concept%20Details|outline"></A> | |
| 4 Concept Details</H1> | |
| <P LANG="en-US" CLASS="western">This section contains details about | |
| the product concept. | |
| </P> | |
| <H2 LANG="en-US" CLASS="western"><A NAME="4.1.Key%20Drivers|outline"></A> | |
| 4.1 Key Drivers</H2> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.1.1.Improving%20Microsoft%20Office%20Interoperability|outline"></A> | |
| 4.1.1 Improving Microsoft Office Interoperability</H3> | |
| <P LANG="en-US" CLASS="western">(Dieter Loeschky, April 2003)</P> | |
| <P LANG="en-US" CLASS="western">In the past, interoperability between | |
| Microsoft Office and SO/OOo was improved by completing the import and | |
| export filters. In "Geordi" interoperability between | |
| Microsoft Office and SO/OOo was improved by also adding features to | |
| SO/OOo and by changing SO/OOo's behavior and interpretation of single | |
| features. | |
| </P> | |
| <P LANG="en-US" CLASS="western">For “Q”, interoperability | |
| will be improved in a very large scale by continuing to add features | |
| to SO/OOo. Changes in the filters are of course still required to | |
| support the new features or changed behavior.</P> | |
| <P LANG="en-US" CLASS="western">The movement of effort from the | |
| filter development into the application development is in fact a very | |
| natural process. At a certain stage, interoperability of a certain | |
| feature cannot be improved by the filter any longer, because it | |
| already converts all data that is supported from one application to | |
| the other. At this point, if the feature still behaves differently, | |
| the SO/OOo application itself may be enhanced.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.1.1 SO/OOo Writer</H4> | |
| <P LANG="en-US" CLASS="western">For SO/OOo Writer, there are four | |
| main areas in which interoperability with Microsoft Office will be | |
| improved: tables, drawing objects, numberings/bullets and spacing. | |
| The improvements in these main areas will be completed by many other | |
| small enhancements in other areas that also raise interoperability | |
| issues.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Tables</P> | |
| <P LANG="en-US" CLASS="western">The most important improvement will | |
| be the support of automatic page breaks within cells. Currently, this | |
| can cause significant differences in layout of the same document | |
| between a non-SO/OOo application and SO/OOo Writer if the document | |
| contains tables that do not fit on a single page. Two other important | |
| improvements will be the support of tables within tables and of | |
| tables where text flows around them. Table interoperability will be | |
| completed by a border model that provides better interoperability | |
| with other applications, including Microsoft Word. Interoperability | |
| improvements mentioned above are considered to be a much higher | |
| priority than those that can be achieved by introducing a different | |
| table model.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Drawing objects</P> | |
| <P LANG="en-US" CLASS="western">A second very important area where | |
| interoperability will be improved is in SO/OOo drawing objects. The | |
| most important improvement will be supporting other applications' | |
| drawing objects within page headers and footers. In addition to this, | |
| missing alignment, anchoring and position modes will be added. | |
| Finally, there will be a unification of drawing objects and SO/OOo | |
| Writer's so called fly frames, i.e. graphic, text box and OLE | |
| objects. Many options that are available for frames will be made | |
| available to drawing objects as well and vice versa. The user | |
| interface of both kind of objects will also be unified.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Numbering and bullets</P> | |
| <P LANG="en-US" CLASS="western">Interoperability of numberings and | |
| bullets, the third main area mentioned above, will also be addressed | |
| by many small enhancements. Negative indents will be supported and it | |
| will be possible to change the indent values for every paragraph | |
| individually. Tabulators will be supported within numbers. Last but | |
| not least, the the calculation of chapter numbers and table of | |
| contents will be enhanced.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Spacing</P> | |
| <P LANG="en-US" CLASS="western">The fourth important area for | |
| improvement can be summarized by the word “spacing.” | |
| Although the differences are very small (typically less than half a | |
| point) and will hardly be noticed by the user, the end result might | |
| be that an imported page contains two lines less of text on a SO/OOo | |
| Writer page. This again can result in images and text boxes appearing | |
| on different pages, and the document may look completely different in | |
| SO/OOo Writer.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.1.2 SO/OOo Calc</H4> | |
| <P LANG="en-US" CLASS="western">Most interoperability problems | |
| between Microsoft Excel and SO/OOo Calc that exist today result from | |
| an incompatible feature set. The biggest advance in interoperability | |
| can be achieved by adding new and changing existing features in Calc | |
| to achieve better compatibility.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Breaking the row limit</P> | |
| <P LANG="en-US" CLASS="western">Currently, 32,000 is the maximum | |
| number of rows in a Calc spreadsheet. Cell content beyond row 32,000 | |
| is lost when a file with more rows is imported into SO/OOo. If more | |
| than 32,000 rows are needed for a specific spreadsheet, there's no | |
| easy way to get equivalent results using only SO/OOo's 32,000 rows. | |
| It is therefore important to adjust our row limit. The number of rows | |
| in a spreadsheet will be increased to 65,536, with provisions to make | |
| it relatively easy to further increase that number in later versions.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Calculation</P> | |
| <P LANG="en-US" CLASS="western">The second important issue is | |
| calculation. Although the set of formula functions is very similar | |
| across most spreadsheet applications, some special-case features of | |
| calculation with these functions are not yet supported in SO/OOo. | |
| Currently, when documents that use these additional features are | |
| loaded in SO/OOo, the formula cells will show error values or even | |
| different results from those in the original document. To get the | |
| same results as in the original, the spreadsheets would have to be | |
| changed manually. Especially in the case of array formulas, these | |
| required changes would be quite extensive, making it difficult to | |
| create an equivalent calculation in SO/OOo. We have identified a set | |
| of features that cause problems.They will be addressed in <SPAN LANG="en-US"><FONT SIZE=3>"Q"</FONT></SPAN>.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Form controls</P> | |
| <P LANG="en-US" CLASS="western">Another important feature that will | |
| be added to SO/OOo is the ability to create form controls (list | |
| boxes, check boxes, etc.) that are connected to spreadsheet cells. | |
| These controls get their values from the cells, and update the cells | |
| if something is selected. With the increased flexibility that will be | |
| needed to support the form layer's own new features, we will be able | |
| to also implement this connection to spreadsheet cells.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Cell attributes</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo supports slightly different | |
| cell attributes than competing applications. This leads to | |
| differences in the appearance or behavior of imported documents that | |
| contain these attributes. We will add corresponding features to | |
| SO/OOo to eliminate the differences in imported documents. We will | |
| extend the validation feature, annotations, scenarios, ranges and | |
| hyperlinks, as well as some cell formatting attributes. | |
| </P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">DataPilot</P> | |
| <P LANG="en-US" CLASS="western">Currently, basic functionality and | |
| interoperability is available in SO/OOo's DataPilot. In <SPAN LANG="en-US"><FONT SIZE=3>"Q"</FONT></SPAN>, | |
| we will extend the DataPilot to the state-of-the-art feature set for | |
| reports based on spreadsheet cell data. The most important of these | |
| features are page fields, settings for fields and individual | |
| elements, and the table formatting options.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Sorting</P> | |
| <P LANG="en-US" CLASS="western">Finally, it's common amongst the | |
| competing applications to preserve as much of the original sorting | |
| order as possible, when sorting a spreadsheet according by some sort | |
| keys. In SO/OOo they end up in a random order. We can change the | |
| implementation of sorting so that the original order is preserved | |
| where sorting criteria are equal.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.1.3 SO/OOo Impress</H4> | |
| <P LANG="en-US" CLASS="western">"Geordi" improved | |
| interoperability with Microsoft PowerPoint in many aspects. To | |
| further improve interoperability completely new features need to be | |
| added to the application and the drawing layer.</P> | |
| <P LANG="en-US" CLASS="western">Build effects</P> | |
| <P LANG="en-US" CLASS="western">The current animation system of | |
| SO/OOo Impress supports one effect per shape with all effect types | |
| individually implemented. Execution of all effects is either | |
| automatic or manually per slide. Users request to have an equivalent | |
| set of effects and to preserve the order of execution of effects when | |
| exchanging presentations between SO/OOo Impress and non-SO/OOo | |
| applications. | |
| </P> | |
| <P LANG="en-US" CLASS="western">Instead of manually implementing | |
| every new shape effect, it is necessary to support an animation core | |
| that is flexible to handle new effects that may be added later. The | |
| first step is to add a core component that can fully load and store | |
| non-SO/OOo effects for improved interoperability. Due to the higher | |
| demands for hardware supported rendering this first step will not be | |
| visually equal on all effects. Also playing the effects in real time | |
| will not be solved by this. | |
| </P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Timeline</P> | |
| <P LANG="en-US" CLASS="western">To support a timeline concept, there | |
| will be a timeline feature for SO/OOo Impress. With this timeline, | |
| interoperability is enhanced by preserving the order and timing by | |
| which the shape effects are executed. Users will be able to add more | |
| than one effect to each shape and to have effects that are partly | |
| automatic and partly triggered by mouse clicks. <BR>This will also | |
| include a user interface to change the new introduced timeline and | |
| effect features. “Q” will also provide a shortcut, for | |
| the user to select an animation theme for a slide, so that the slide | |
| and shape effects are automatically set to fit the theme.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Collaboration</P> | |
| <P LANG="en-US" CLASS="western">Interoperability with other | |
| presentation programs, including Microsoft PowerPoint, will be | |
| improved by adding means to use sticky note like comments in Impress. | |
| Currently, upon import, SO/OOo Impress ignores this information. | |
| This improvement will enhance interoperability by preserving document | |
| content and by giving SO/OOo Impress users who need to interoperate | |
| with other application users the ability to exchange comments on | |
| their work.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Header and Footers</P> | |
| <P LANG="en-US" CLASS="western">Sometimes headers and footers in | |
| Impress presentation slides get lost during a roundtrip from | |
| Microsoft PowerPoint to SO/OOo Impress. The reason for this is the | |
| different way headers and footers are used in Microsoft PowerPoint | |
| and SO/OOo Impress. The SO/OOo Impress method for using headers and | |
| footers is much more flexible than Microsoft PowerPoint's.</P> | |
| <P LANG="en-US" CLASS="western">To meet this requirement and to | |
| improve ease of use, SO/OOo Impress will provide easier access to | |
| it's header and footer feature. This will not only enhance | |
| interoperability by keeping header and footer information persistent, | |
| but will also provide the user with an easier interface to create | |
| them in SO/OOo Impress. There will also be an easy to use dialog to | |
| change the header and footer for the current page or for all pages.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Extended Drawing Shapes</P> | |
| <P LANG="en-US" CLASS="western">Often drawing shapes, such as | |
| “AutoShapes” in Microsoft PowerPoint, can be found in | |
| competing presentation program applications. They provide an easy | |
| way of adding drawings to presentations. Therefore a set of | |
| predefined shapes of different categories like 'block arrows', 'flow | |
| charts', 'stars and banners', 'callouts' and 'action buttons' can be | |
| provided. | |
| </P> | |
| <P LANG="en-US" CLASS="western">For example, in the current version | |
| of SO/OOo, imported Microsoft Office documents that contain | |
| Autoshapes are mostly displayed correctly. There does not exist, | |
| however, the ability to edit WordArt objects or to change 3D-objects. | |
| Interchanging documents between SO/OOo and Microsoft Office leads to | |
| the loss of functionality of these drawing objects.</P> | |
| <P LANG="en-US" CLASS="western">To meet this requirement, an | |
| implementation for extended drawing objects in SO/OOo will be | |
| designed, including new dialogs to edit imported WordArt objects and | |
| to change imported 3D objects. This will not only enhance | |
| interoperability through supporting all Microsoft Office AutoShapes, | |
| but make them fully editable and allow SO/OOo Impress users to create | |
| functionally equal drawing shapes themselves.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <H4 LANG="en-US" CLASS="western">4.1.1.4 SO/OOo Base (Forms)</H4> | |
| <P LANG="en-US" CLASS="western">An evolving standard for data entry | |
| applications are W3C's XForms. XForm controls can be embedded into | |
| any XML based file format like XHTML, and they support data entry | |
| based on XML schemes. It is likely that XForms will replace at least | |
| HTML/HTTP forms in the mid term future. By adding XForms support to | |
| SO/OOo, it will not only keep up with recent development trends, but | |
| in combination with the OASIS OpenOffice XML file format it also | |
| becomes a powerful alternative to XHTML/XForms. What makes it | |
| interesting to use an OASIS OpenOffice XML and XForms based SO/OOo as | |
| a data entry client is that it offers much more layout capabilities | |
| than XHTML/XForms based clients, but uses exactly the same open | |
| protocols as XHTML/XForms based clients on the server side. Moreover, | |
| since SO/OOo is also a powerful tool to create forms, even form | |
| creation gets easier and does not require additional tools.</P> | |
| <P LANG="en-US" CLASS="western">While XForms are already an | |
| improvement for data entry applications, it is conceivable that data | |
| entry applications will improve further. In some of the recently | |
| developed applications, data entry is not limited to classical form | |
| controls, but arbitrary text or other content can by included into | |
| the form data. Additionally, some applications provide the ability to | |
| extend forms at run time. An example for this are meeting minutes, | |
| where an agenda item might be duplicated any times. These | |
| capabilities allow it to use data entry applications not only for | |
| static and simple forms, but also for such complex things like | |
| minutes, bills or letters. In any case, the actual form data will | |
| stay in an XML schema. These schema could be either a user defined | |
| one, or one that is standardized by organizations like OASIS. In the | |
| later category are the UBL schemes that are currently developed by an | |
| OASIS technical committee. | |
| </P> | |
| <P LANG="en-US" CLASS="western">In such scenarios, the user creates | |
| new documents based on existing document templates. In the new | |
| document, data can be entered only at predefined locations, for | |
| instance within certain fields, controls or text boxes. Moreover only | |
| very few editing features will be enabled. For instance, text | |
| sections might be duplicated but not inserted at any location. This | |
| way, it can be ensured that the document always has a defined | |
| structure. This again allows it to bind every editable data to | |
| elements of an XML schema and therefor to submit them as XML form | |
| data.</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo capabilities for such form | |
| based work flows will be improved. The starting point is the XForm | |
| enhancements described above. Further steps will be the inclusion of | |
| for instance field or paragraph contents into XML form data and | |
| possibilities to enter data into them in Writer's read only mode. The | |
| capabilities to specify application behavior within templates will be | |
| improved. Finally, certain complex editing operations, like | |
| duplicating a section, will be allowed in Writer's read only mode as | |
| well. By adding data entry capabilities to SO/OOo step by step, more | |
| and more work flows can be implemented with SO/OOo. | |
| </P> | |
| <P LANG="en-US" CLASS="western">SO/OOo will also improve its | |
| interoperability with the form functionality of Microsoft Office, in | |
| particular of Microsoft Word. Microsoft Word features two completely | |
| different concepts for form functionality: form fields and form | |
| controls. Form fields are the more ancient concept and are not | |
| supported by "Geordi", but are nevertheless frequently used | |
| by Microsoft Word users. SO/OOo will address this by implementing | |
| equivalents for these form fields.</P> | |
| <P LANG="en-US" CLASS="western">Form controls offer a functionality | |
| similar to form controls in SO/OOo applications. For “Q”, | |
| we will implement some new control types like scroll bars, toggle | |
| buttons, and a rich text control, and enhance existing control types | |
| with functionality currently not present, for example multi-columnar | |
| list boxes, and spell checking in text controls.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.1.5 SO/OOo Chart</H4> | |
| <P LANG="en-US" CLASS="western">Additional functionality will be | |
| added to the Chart core. This added functionality will ease Bug | |
| fixing and integration of new features. | |
| </P> | |
| <P LANG="en-US" CLASS="western">The most important feature that will | |
| be added will allow data series to get their input from individual | |
| cell-ranges for x-values, y-values, labels, etc. Without it, some | |
| imports from non-SO/OOo spreadsheets can only produce an empty | |
| output. Technically, this requires new interfaces for the | |
| communication between SO/OOo Chart and either SO/OOo Calc or SO/OOo | |
| Writer. Moreover, the source data concept within the SO/OOo Chart | |
| needs to be redesigned completely.</P> | |
| <P LANG="en-US" CLASS="western">Some new chart types have to be | |
| integrated too – especially bubble and surface charts. A bubble | |
| chart requires an additional input range for the bubble sizes. As | |
| this additional range does not fit into the current source data | |
| structure the new source data concept mentioned above is a | |
| prerequisite for offering a bubble chart as well.</P> | |
| <P LANG="en-US" CLASS="western">Moreover, the integration of a new | |
| chart type into the old SO/OOo Chart core could jeopardize existing | |
| functionality, as chart type dependent code is spread over the whole | |
| project. To eliminate this fundamental problem a new SO/OOo Chart | |
| core will encapsulate chart type dependent code in separate UNO | |
| components with well defined interfaces.</P> | |
| <P LANG="en-US" CLASS="western">The re-implementation of the SO/OOo | |
| Chart core is a necessary, long-lasting task that has to be finished | |
| before any of the requested new features can be started. The | |
| re-implementation of the current functionality is expected to take at | |
| least until the end of the calendar year.</P> | |
| <P LANG="en-US" CLASS="western">The missing features for | |
| interoperability with competing applications include:</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Flexible source range selection | |
| for different parts of data series (x-values, y-values, labels etc.)</P> | |
| <LI><P LANG="en-US" CLASS="western">Flexible combination of | |
| different chart types (mostly line & bar)</P> | |
| <LI><P LANG="en-US" CLASS="western">Free positioning of data point | |
| labels (often requested for pie charts)</P> | |
| <LI><P LANG="en-US" CLASS="western">Take format for data point | |
| labels from corresponding SO/OOo Calc cell</P> | |
| <LI><P LANG="en-US" CLASS="western">Pull out 3d pie segments (often | |
| requested)</P> | |
| <LI><P LANG="en-US" CLASS="western">Pseudo 3d look (this type of 3d | |
| charts is often used in magazines)</P> | |
| <LI><P LANG="en-US" CLASS="western">Bubble chart</P> | |
| <LI><P LANG="en-US" CLASS="western">Surface chart</P> | |
| <LI><P LANG="en-US" CLASS="western">More flexible legend (resizable, | |
| removable entries)</P> | |
| <LI><P LANG="en-US" CLASS="western">Arbitrary content for data point | |
| labels</P> | |
| <LI><P LANG="en-US" CLASS="western">X error bars</P> | |
| <LI><P LANG="en-US" CLASS="western">Filled radar chart</P> | |
| <LI><P LANG="en-US" CLASS="western">Pull out outermost segments of | |
| 2d donut charts</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">The order of the items reflects a | |
| proposed prioritization. The highest priorities are given to those | |
| missing features that cause more information loss and are used more | |
| often.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.1.2.Usability|outline"></A> | |
| 4.1.2 Usability</H3> | |
| <P LANG="en-US" CLASS="western">(Matthias Mueller-Prove, May 2003)</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.2.1 Menu Structure</H4> | |
| <P LANG="en-US" CLASS="western">The redesign of the menu structure | |
| will take the general concepts of the competing applications into | |
| account. Two prominent examples of menu changes for “Q” | |
| are the organization of menu items of the View menu and a new Table | |
| menu for Writer.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.2.2 Toolbars</H4> | |
| <P LANG="en-US" CLASS="western">The user interface of toolbars will | |
| be completely redesigned. “Q” provides for small toolbars | |
| that can be rearranged with drag'n'drop. The new design makes better | |
| use of the screen estate by using the space more efficiently. The | |
| dynamic exchange of toolbar content will be eliminated.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.2.3 Terminology</H4> | |
| <P LANG="en-US" CLASS="western">The terminology used for the user | |
| interface for menus, prominent dialogs and alert messages will be | |
| revised in order to utilize the existing knowledge of office | |
| productivity users.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.2.4 Window Layout</H4> | |
| <P LANG="en-US" CLASS="western">Impress will get a new window layout | |
| that introduces a tool pane for SO/OOo. The tool pane offers specific | |
| commands for presentations to make it more easy for the user to | |
| manage and edit slides, import styles and slides from other files and | |
| to run her presentation.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.2.5 Application Separation</H4> | |
| <P LANG="en-US" CLASS="western">For the user, “Q” will | |
| also look more like separate applications. The Microsoft Windows | |
| Start menu / Linux desktop panel, SO/OOo's “File” and | |
| “Window” menu, document window titles, and the options | |
| dialog will reflect this change. | |
| </P> | |
| <P LANG="en-US" CLASS="western">Along with this new concept we will | |
| eliminate obsolete settings from the options dialog and make clear | |
| which settings have effects in which part of the application.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.2.6 General Interaction</H4> | |
| <P LANG="en-US" CLASS="western">The interaction model for text, | |
| tables and images in Writer and for objects and layers in Draw and | |
| Impress will implement state-of-the-art selection techniques.</P> | |
| <P LANG="en-US" CLASS="western">For “Q” we will revise | |
| the interaction concepts for compound tasks like mail merge and | |
| creating charts.</P> | |
| <P LANG="en-US" CLASS="western">Finally, the enhanced Undo | |
| functionality will significantly improve robustness of the product. | |
| </P> | |
| <H4 LANG="en-US" CLASS="western">4.1.2.7 Usability of the Database | |
| application</H4> | |
| <P LANG="en-US" CLASS="western">(Frank Schoenheit, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">Currently, the database access (DBA) | |
| functionality in SO/OOo exposes various differences from other | |
| database applications. Those differences can be assigned to two | |
| groups: usability and interoperability. These issues are | |
| predominant with users who are not able to locate the functionality | |
| they need (though often it is present). They then do not feel | |
| comfortable with SO/OOo's user interface which follows a different | |
| philosophy in this area.</P> | |
| <P LANG="en-US" CLASS="western">Additionally, having a competitive | |
| database application, instead of a set of database access components, | |
| clearly is an important feature for potential users and customers.</P> | |
| <P LANG="en-US" CLASS="western">We will address this with a redesign | |
| of SO/OOo's database application. In the first instance, this will | |
| lead to it being recognized as a state-of-the-art end user oriented | |
| database application, and make former users of other database | |
| products, like Microsoft Access, feel more comfortable. In the | |
| second instance, it will address most of the problems customers have | |
| with the current user interface.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">A New Database Application</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo DBA (with a new name which is | |
| to be discussed) will be an own application, instead of hiding within | |
| Writer, Calc and Impress documents. This will be perceived as a | |
| competitive database application then, which will be equal to the | |
| other major applications in SO/OOo.</P> | |
| <P LANG="en-US" CLASS="western">This new application will be | |
| accessible from the main menu – File|New is where users expect | |
| to create a new database, so we will add a Database item, which opens | |
| the application and offers the user a reasonable set of choices how | |
| to proceed (e.g. create a dBase data source, connect to an existing | |
| foreign database via an auto pilot).</P> | |
| <P LANG="en-US" CLASS="western">We will not abandon the concept of | |
| data sources. This is not only for reasons of feasibility (a | |
| database engine is a very heavy-weight project), but also for reasons | |
| of openness: We continue SO/OOo's philosophy to allow the user to | |
| work with whatever database is already present in her work | |
| environment, from client-side single-user file-based databases up to | |
| server-side databases participating in a corporate work flow.</P> | |
| <P LANG="en-US" CLASS="western">The layout and user interface of this | |
| new application will, at the first glance, be recognized as | |
| relatively similar to what typical database application users already | |
| know. Where it makes sense, the application will provide a look&feel, | |
| including functional concepts, that are intuitive.</P> | |
| <P LANG="en-US" CLASS="western">As a consequence of this new database | |
| access application, we will give it its own top-level topic in | |
| SO/OOo's help system. This will increase the user's ability to find | |
| help with database topics.</P> | |
| <P LANG="en-US" CLASS="western">The functionality of the current Data | |
| Source Administration dialog, and large parts of the functionality of | |
| the current data source browser, will be merged in the new | |
| application, providing one single entry point for database | |
| functionality in SO/OOo.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Data Sources</P> | |
| <P LANG="en-US" CLASS="western">We will re-implement the user | |
| interface of SO/OOo DBA. We will move away from the current | |
| technician-oriented user interface to a more end-user oriented work | |
| flow and terminology.</P> | |
| <P LANG="en-US" CLASS="western">In addition, several measures will be | |
| taken to make the “data source” concept feel more like | |
| the “database” concept the user is used to from other | |
| office suites. Though the underlying core concepts will not be | |
| changed, SO/OOo users then will have less problems when migrating | |
| from other database applications.</P> | |
| <P LANG="en-US" CLASS="western">We will change the way that data | |
| sources in SO/OOo are administrated – we will put more focus on | |
| meeting the user in her own vocabulary of concepts, by creating a | |
| more intuitive user interface, and by exposing most of the technical | |
| details to advanced users only.</P> | |
| <P LANG="en-US" CLASS="western">An auto pilot will be created which | |
| allows the import/export of data sources (file based), and thus | |
| migrate them between installations. This will not only unburden the | |
| user from the manual work which is currently required for this, but | |
| also support the impression of a “database” in opposite | |
| to a “data source” which the user cannot really control.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Form Documents</P> | |
| <P LANG="en-US" CLASS="western">Form Documents provide a highly | |
| customizable view to database data, thus they are the user's primary | |
| choice when working with such data.</P> | |
| <P LANG="en-US" CLASS="western">The main improvement desired by | |
| SO/OOo users in the area of form functionality is usability. Thus, we | |
| will make changes to SO/OOo affecting the user interface in several | |
| ways. The user will recognize SO/OOo data-aware forms (which covers | |
| form design as well as form usage) as a dedicated solution, in | |
| opposite to the current situation, where form functionality is | |
| recognized as a small and hidden add-on to SO/OOo text documents.</P> | |
| <P LANG="en-US" CLASS="western">This list ranges from small and | |
| rather cosmetic changes which will sum up to a much better user | |
| experience, to larger projects such as a dedicated simple mode for | |
| the property browser, which consists of specialized views for the | |
| different object types, and presents only the most often used aspects | |
| of these objects to the user, this way exposing the full power of the | |
| property browser to advanced users only.</P> | |
| <P LANG="en-US" CLASS="western">Additionally, functionality | |
| enhancements will be made to SO/OOo's form layer. Included here are | |
| additions to the form controls which are required in the Microsoft | |
| Interoperability Chapter, but also new implementations (such as | |
| real-time filter controls) which will bring SO/OOo nearer to the | |
| current state-of-the-art.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Common Tasks</P> | |
| <P LANG="en-US" CLASS="western">We will provide the user with more | |
| auto pilots for the most common tasks in the database area, | |
| respectively enhance the existing auto pilots. In SO/OOo “Q”, | |
| we will have an enhanced report and form auto pilot, and new pilots | |
| for designing new tables, and designing customized data views aka | |
| queries.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.1.3.Performance|outline"></A> | |
| 4.1.3 Performance</H3> | |
| <P LANG="en-US" CLASS="western">(Matthias Huetsch, May 2003)</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.3.1 Startup Time</H4> | |
| <P LANG="en-US" CLASS="western">The most visible performance | |
| improvement in SO/OOo will be the substantial shortening of the time | |
| required for first startup, in particular when the system has not | |
| been used for some time or after a system reboot. The improved first | |
| startup time will correspond to the time used by competing | |
| applications.</P> | |
| <P LANG="en-US" CLASS="western">Generally, the decrease in startup | |
| time will be addressed through refactoring the code and removing the | |
| strong interdependencies between:</P> | |
| <P LANG="en-US" CLASS="western">Application 'Core', 'User Interface' | |
| and 'Filter' code</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Application code and 'Common | |
| User Interface' code spread over several shared libraries</P> | |
| <LI><P LANG="en-US" CLASS="western">Application code and | |
| 'Accessibility Helper Class' code spread over several shared | |
| libraries</P> | |
| <LI><P LANG="en-US" CLASS="western">Several large shared libraries | |
| tied together due to the use of a global initialization pattern</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">In combination, these refactoring | |
| actions shall result in loading a relatively lightweight framework | |
| plus the necessary application code and document filters upon | |
| startup, only, and will thus reduce both the startup time as well as | |
| the initial memory consumption.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.3.2 Document Open/Save Time</H4> | |
| <P LANG="en-US" CLASS="western">The second most visible performance | |
| improvement in SO/OOo will be decreasing the time required for | |
| opening or saving larger documents, in particular for documents in | |
| the native XML format. This time improvement will be comparable with | |
| competing applications.</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo will implement this time | |
| savings with SO/OOo API enhancements that are optimized for XML | |
| import / export and are fully supported by the application internal | |
| implementations. Code optimizations along the entire import / export | |
| component chain will be evaluated to identify and eliminate | |
| bottlenecks.</P> | |
| <P LANG="en-US" CLASS="western">Responsiveness</P> | |
| <P LANG="en-US" CLASS="western"><SPAN LANG="en-US"><FONT SIZE=3>"Q"</FONT></SPAN> | |
| will speed up the graphics display and increase the responsiveness in | |
| rendering complex drawing objects.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">This improvement will be addressed | |
| with a redesign of both the graphics toolkit, adding e.g., support | |
| for modern hardware acceleration, and the presentation engine, making | |
| use of double-buffering and other caching techniques.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.3.3 Scalability</H4> | |
| <P LANG="en-US" CLASS="western">Large scale multi-user deployments in | |
| which possibly hundreds of SO/OOo application instances are running | |
| on a single multi-processor server will be improved beyond what | |
| “Geordi” already addresses. Scalability issues can be | |
| summarized and addressed as follows:</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">System Load</P> | |
| <P LANG="en-US" CLASS="western">A high number of context switches per | |
| second is caused by SO/OOo instances temporarily yielding control to | |
| other processes or threads. This behavior induces a high load on the | |
| system scheduler, and may as well adversely affect the responsiveness | |
| of SO/OOo itself.</P> | |
| <P LANG="en-US" CLASS="western">This will be addressed by giving up | |
| current cooperative and timer based polling concepts in favor of | |
| preemptive and event driven concepts.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Memory Consumption</P> | |
| <P LANG="en-US" CLASS="western">The amount of non-shareable memory | |
| per SO/OOo process to a large extend determines the number of | |
| instances that can run simultaneously on a given server machine.</P> | |
| <P LANG="en-US" CLASS="western">This will be addressed by reducing | |
| the size of writeable data segments in shared libraries and special | |
| purpose memory allocators for compact mass object storage.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.1.4.Programmability|outline"></A> | |
| 4.1.4 Programmability</H3> | |
| <H4 LANG="en-US" CLASS="western">4.1.4.1 UNO/Office API Improvements</H4> | |
| <P LANG="en-US" CLASS="western">(Stephan Bergmann, Daniel Boelzle, | |
| Kai Sommerfeld, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">The Office UNO API is very fine | |
| grained. Although this offers maximum flexibility, programmers often | |
| want to have simplified high-level UNO interfaces. This enables rapid | |
| application development and helps even lower-skilled developers to | |
| reach their goals quickly. To address this problem we need to provide | |
| a new set of task-oriented high-level convenience UNO services.</P> | |
| <P LANG="en-US" CLASS="western">UNO defines language independent | |
| concepts like services, interfaces or the Any data type. The binding | |
| to concrete languages often maps these concepts One to One. This is | |
| not always the optimum because it may require the developer to learn | |
| constructs that are unusual or even strange for a certain programming | |
| language. A popular example for this is the queryInterface call, | |
| which should be a simple cast in Java. For the next Office release we | |
| will provide new UNO features which will simplify the usage of UNO in | |
| general or for particular language bindings.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.4.2 Integrated IDE for multiple | |
| scripting languages</H4> | |
| <P LANG="en-US" CLASS="western">(Thomas Benisch, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">With the language independent | |
| scripting framework it will be possible to script SO/OOo in any | |
| supported scripting language. This raises the need for a lightweight | |
| scripting IDE, which is integrated into SO/OOo and supports multiple | |
| scripting languages including SO/OOo Basic, Java and JavaScript.</P> | |
| <P LANG="en-US" CLASS="western">The scripting IDE will be based on a | |
| language independent IDE binding concept. A scripting language can | |
| only be integrated into the IDE, if the corresponding interfaces are | |
| supported by the scripting runtime.</P> | |
| <P LANG="en-US" CLASS="western">It is planned, that the current Basic | |
| IDE and its dialog editor will be refactored and modularized, which | |
| will be the base for the new scripting IDE.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.4.3 Type Life Cycle</H4> | |
| <P LANG="en-US" CLASS="western">(Daniel Boelzle, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">The Universal Network Objects (UNO) | |
| Component Model with its support for different languages gains | |
| popularity. UNO paves the way to access the SO/OOo API and | |
| development of extensions by 3rd party developers.</P> | |
| <P LANG="en-US" CLASS="western">This way, developers have to face | |
| quite some problems introducing and using UNO types concurrently. If | |
| it is feasible, it is desirable that UNO types have a controlled life | |
| cycle.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.4.4 .NET Bridge</H4> | |
| <P LANG="en-US" CLASS="western">(Joachim Lingner, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo uses software bridges in order | |
| to have pieces of code, which may be subjected to certain language- | |
| and runtime specific requirements and restrictions, interact with | |
| each other. For example, Java code or C++ code cannot interact | |
| naturally. The same goes for C++ code compiled with different | |
| compilers. | |
| </P> | |
| <P LANG="en-US" CLASS="western">All those particular requirements to | |
| a piece of code is referred to as environment and it is said that a | |
| piece of code lives (or runs) in an environment. Now, to have code | |
| from one environment access code in another environment, one needs to | |
| have a bridge. Because of the multitude of possible combinations of | |
| environments, bridges use an intermediary environment, namely the UNO | |
| environment. | |
| </P> | |
| <P LANG="en-US" CLASS="western">If a new compiler is to be used or | |
| software written in a new language, then one only needs to provide a | |
| bridge into the UNO environment and all other environments for which | |
| there is also a UNO bridge may interact with the new environment.</P> | |
| <P LANG="en-US" CLASS="western">The CLI – UNO bridge enables | |
| programmers to use languages which produce CLI (Common Language | |
| Infrastructure) compatible code. This includes languages such as C#, | |
| C++ .NET, and Visual Basic .NET.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.4.5 Live Deployment and GUI</H4> | |
| <P LANG="en-US" CLASS="western">(Daniel Boelzle, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">The development of 3rd party | |
| extensions for OpenOffice.org using the OpenOffice.org API is gaining | |
| popularity. The common tool to deploy those extensions into an Office | |
| installation is pkgchk. The user raises the pkgchk deployment tool | |
| specifying a package file to be installed. The tool then scans the | |
| content of the package file and handles different content types with | |
| respect to their file extensions:</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">UNO shared library components | |
| (.dll, .so files)</P> | |
| <LI><P LANG="en-US" CLASS="western">UNO Java components (.jar files)</P> | |
| <LI><P LANG="en-US" CLASS="western">UNO Python components (.py | |
| files)</P> | |
| <LI><P LANG="en-US" CLASS="western">UNO typelibrary files (.rdb | |
| files)</P> | |
| <LI><P LANG="en-US" CLASS="western">SO/OOo Basic scripts and dialogs | |
| (script.xlb and dialog.xlb files)</P> | |
| <LI><P LANG="en-US" CLASS="western">Configuration schemata and data | |
| (.xcs, .xcu files)</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">Currently users have to shut down a | |
| running office process before running the pkgchk deployment tool | |
| adding or removing packages. It may be desirable that users can | |
| deploy packages while running an office process and trigger removal | |
| of existing packages. Moreover, the currently used pkgchk deployment | |
| tool is a command line tool. If deployment can be performed while | |
| running the office process, a proper user interface is nice, too | |
| (e.g. in “Tools” menu bar).</P> | |
| <P LANG="en-US" CLASS="western">The need to shut down the offices | |
| using a shared installation is even worse, e.g. Imagine having a | |
| shared installation used by a thousand users, before something can be | |
| deployed into this shared installation, it has to be ensured that | |
| every running office started out of this installation has been | |
| terminated. Otherwise this office instances may work with | |
| inconsistent data, which can lead to data loss or crashes.</P> | |
| <P LANG="en-US" CLASS="western">Different content types are deployed | |
| differently. Thus the problems that occur upon insertion/removal of a | |
| package at runtime are different. | |
| </P> | |
| <H4 LANG="en-US" CLASS="western">4.1.4.6 Scripting Framework</H4> | |
| <P LANG="en-US" CLASS="western">(Noel Power, April 2003)</P> | |
| <P LANG="en-US" CLASS="western">Currently Scripting support for | |
| SO/OOo exists for one language only, SO/OOo Basic. Users, Developers | |
| and ISVs who wish to extend SO/OOo using scripting are locked into | |
| this single offering. It is advantageous from strategic point of view | |
| to support Java and Java derivatives such as JavaScript and | |
| BeanShell for scripting. Other scripting languages such as Python | |
| could also be added as the market dictates.</P> | |
| <P LANG="en-US" CLASS="western">A framework is needed to allow new | |
| scripting languages to be added and supported. It should be possible | |
| to easily plug in additional languages runtimes. The framework needs | |
| to provide an environment to enable users to easily and quickly | |
| develop, deploy and execute scripts. Scripting should be easy. A | |
| script developer should be able to write and test a script with a | |
| minimal set of steps. They should be able to experiment and learn | |
| within the scripting environment, enabling them to accomplish their | |
| scripting tasks easily and quickly. | |
| </P> | |
| <P LANG="en-US" CLASS="western">Scripting in SO/OOo will be made more | |
| easy, intuitive and low cost. This is mainly due to the complexity | |
| and low level nature of the current SO/OOo API. In order for | |
| scripting to be be easy, intuitive and low cost, the SO/OOo API needs | |
| to be simplified. Such a simplified API should be well documented, | |
| script focused and high-level. This would allow users to intuitively | |
| discover the necessary objects and interfaces needed to program a | |
| specific task rather than having to work through a mountain of | |
| documentation.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.1.5.Integration%20into%20the%20Gnome%20Desktop,%20and%20Microsoft%20Windows|outline"></A> | |
| 4.1.5 Integration into the Gnome Desktop, and Microsoft Windows</H3> | |
| <P LANG="en-US" CLASS="western">(Christof Pintaske, June 2003)</P> | |
| <P LANG="en-US" CLASS="western">(Requirements for integration into | |
| Microsoft Windows need to be determined later)</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.5.1 Look and Feel</H4> | |
| <P LANG="en-US" CLASS="western">“Geordi” emulates the | |
| color-scheme and basic font setting of a running Gnome-2.x desktop. | |
| "Q" is required to pickup the style of all basic widget | |
| elements (buttons, slider, fixed-text, check-boxes and so on) in a | |
| way that exactly reflects the current GTK widget theme. The majority | |
| of dialogs should not show any immediately visible differences to a | |
| dialog implemented in the GTK widget set. Focus, modality, and | |
| guidelines for widget placement will not be adapted.</P> | |
| <P LANG="en-US" CLASS="western">"Geordi" uses a proprietary | |
| engine for installing, naming, and selecting fonts. Font names on the | |
| system may be invalid in SO/OOo, or denote to a completely different | |
| font and vice versa. The "Q" font handling scheme has to be | |
| consistent with the Desktop and the major applications. Naming of | |
| fonts shipping with "Geordi" or older versions of SO/OOo | |
| must not change. Explicit settings for font replacement must remain | |
| intact as well.</P> | |
| <P LANG="en-US" CLASS="western">This will be addressed by using the | |
| systems font configuration (Fontconfig2). Doing so will be as well | |
| beneficial for the startup performance since "Q" will not | |
| need to examine fonts at startup.</P> | |
| <P LANG="en-US" CLASS="western">"Geordi" uses a mixture of | |
| X11/cursorfont mouse pointer, pointer specifically designed for | |
| SO/OOo, and pointer that are modeled similar to those found on other | |
| platforms, like Microsoft Windows. This is inconsistent with other | |
| applications on the Gnome desktop and it inhibits proper pointer | |
| settings for accessible desktop themes (large cursor settings, high | |
| contrast themes, ...). "Q" should use Gnome compliant | |
| cursors where appropriate.</P> | |
| <P LANG="en-US" CLASS="western">Hotkey/Accelerator scheme should be | |
| aligned with the Gnome desktop. Common tasks should reflect in equal | |
| keys. Keys already taken by the window manager should not be offered | |
| or used for application bindings.</P> | |
| <P LANG="en-US" CLASS="western">It would be nice to have Gnome input | |
| methods available in SO/OOo as well (currently only available in | |
| Gnome-edit and Gnome-terminal).</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.5.2 Printing</H4> | |
| <P LANG="en-US" CLASS="western">"Q" is required to be able | |
| to provide the same printing experience as "Geordi" without | |
| the need of neither own printer configuration functionality nor own | |
| printer configuration data on a Gnome Desktop system. It may | |
| eventually provide an own UI to the system configuration if the | |
| systems UI is insufficient or otherwise unusable.</P> | |
| <P LANG="en-US" CLASS="western">The CUPS system encapsulates and | |
| provides access to locally connected printer, and remote printer | |
| accessed through the IPP, LPD, SMB and many other protocols. | |
| </P> | |
| <P LANG="en-US" CLASS="western">CUPS provides a legacy layer that | |
| enables "Geordi" to chose from and to print to all printers | |
| configured within CUPS. However "Q" will be enhanced to | |
| query printer capabilities from CUPS and comply with CUPS | |
| configuration settings, thus making the proprietary SO/OOo printer | |
| administration obsolete in favor of the according desktops system | |
| solution.</P> | |
| <P LANG="en-US" CLASS="western">Currently there is no system-wide | |
| print dialog available. If there'll be shareable UI available in "Q" | |
| timeframe it should be integrated instead of implementing a | |
| proprietary UI.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.5.3 Integration of network | |
| neighborhood</H4> | |
| <P LANG="en-US" CLASS="western">"Q" is required to be able | |
| to load and store files on SMB shares to allow for interoperability | |
| in a network of Microsoft Windows computers. The UI has to be | |
| extended to give convenient access to this functionality. Further on | |
| it is desired to be able to handle all URLs that are valid in the | |
| Gnome Desktop file manager (Nautilus)</P> | |
| <P LANG="en-US" CLASS="western">Gnome provides a virtual file system | |
| service (GnomeVFS). It makes various file systems transparent to the | |
| user. Amongst others it is able to cope with protocols like HTTP, | |
| FTP, NFS, SMB, local files, WebDAV. Further on it provides MIME | |
| information and maintain an according application registry.</P> | |
| <P LANG="en-US" CLASS="western">"Q" will be enabled to use | |
| GnomeVFS. The main benefit is to improve interoperability with | |
| Windows SMB shares. GnomeVFS will as well improve interoperability | |
| with the Nautilus file manager since contents will be available in | |
| both applications through the same URI. Further on SO/OOo will be | |
| able to handle external data conforming to the system MIME settings. | |
| </P> | |
| <H4 LANG="en-US" CLASS="western">4.1.5.4 Desktop integration</H4> | |
| <P LANG="en-US" CLASS="western">A user of Microsoft Windows is able | |
| to create new, empty SO/OOo documents on the desktop. The Gnome | |
| Desktop shall offer a competitive feature. This will be addressed by | |
| creating an according Bonobo component for Nautilus.</P> | |
| <P LANG="en-US" CLASS="western">The most important applications on | |
| the Gnome desktop will be immediately available from the Gnome start | |
| menu. An according top level entry for SO/OOo needs be added. | |
| </P> | |
| <P LANG="en-US" CLASS="western">It is required to inform all | |
| application on the Gnome desktop about how to handle SO/OOo files. | |
| Especially the browser and the file manager need to be able handle | |
| them appropriately and to show an appropriate icon. This will be | |
| addressed by registering the SO/OOo MIME types in the according | |
| system registry.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.5.5 Application interoperability</H4> | |
| <P LANG="en-US" CLASS="western">Available browser plugins will be | |
| made available for the SO/OOo “Insert -> Object -> | |
| {Plugin|Sound|Video} mechanism.</P> | |
| <P LANG="en-US" CLASS="western">The Ximian Evolution address book | |
| will be imported into SO/OOo.</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.5.6 Installation</H4> | |
| <P LANG="en-US" CLASS="western">The Gnome Desktop system will be | |
| delivered as a set of packages in the <A HREF="http://www.rpm.org"> | |
| RPM</A> format. It's necessary to seamlessly deploy and update SO/OOo | |
| together with other parts of the operating system. | |
| </P> | |
| <P LANG="en-US" CLASS="western">Currently most Linux distributions | |
| provide RPMs that correspond to a complete "Geordi" network | |
| installation. "Q" will be delivered as a more fine grained | |
| set of packages that enable individual installation, update and | |
| patching of functional entities. Shareable files for system | |
| integration will be installed in the system and not in every users | |
| home directory as in "Geordi"</P> | |
| <H4 LANG="en-US" CLASS="western">4.1.5.7 Configuration</H4> | |
| <P LANG="en-US" CLASS="western">SO/OOo makes use of a set of helper | |
| applications. Application that can be used as helper application in | |
| SO/OOo need to useable without further administration. "Q" | |
| will make use of the Gnome desktop configuration where possible. | |
| Examples here are default mailer, default web browser, and proxy | |
| settings. The SO/OOo Configuration component will provide a | |
| transparent access to the system settings, which will be resolved via | |
| a plugable backend architecture.</P> | |
| <H2 LANG="en-US" CLASS="western"><A NAME="4.2.General%20Improvements|outline"></A> | |
| 4.2 General Improvements</H2> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.2.1.Stability%20and%20Quality|outline"></A> | |
| 4.2.1 Stability and Quality</H3> | |
| <P LANG="en-US" CLASS="western">(Matthias Huetsch, June 2003)</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.1.1 Document Recovery</H4> | |
| <P LANG="en-US" CLASS="western">Any potential crash of SO/OOo that | |
| could result in lost data will be addressed by defaulting to a new | |
| Auto Recovery mechanism performing a regular backup of documents and | |
| settings. This Auto Recovery mechanism will restore a users work | |
| environment to the state before SO/OOo terminated.</P> | |
| <P LANG="en-US" CLASS="western">The Document Recovery dialog will be | |
| enhanced to guide a user through this Auto Recovery process of | |
| restoring documents and to provide detailed feedback upon the | |
| recovery progress.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.1.2 Error Reporter</H4> | |
| <P LANG="en-US" CLASS="western">Stability improvements for SO/OOo are | |
| required to be measurable. In order to be able to characterize the | |
| current stability level, this requirement was pulled-in to the SO/OOo | |
| “Geordi” release and has been addressed by an Error | |
| Reporter application, recording crash data and user feedback about | |
| document loss or preservation.</P> | |
| <P LANG="en-US" CLASS="western">This Error Reporter will help to | |
| identify and eliminate crash causes, as well as provide a metric to | |
| show improvements in the stability levels achieved for SO/OOo “Q” | |
| and subsequent releases.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.2.2.Administration%20and%20Deployment|outline"></A> | |
| 4.2.2 Administration and Deployment</H3> | |
| <P LANG="en-US" CLASS="western">(Dirk Grobler, Christof Pintaske, May | |
| 2003)</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.2.1 Deployment | |
| </H4> | |
| <P LANG="en-US" CLASS="western">The installation paradigm changes | |
| from being primarily single user oriented to being administrator | |
| oriented. It is looking for large scale installations and | |
| administrations. This issue will be addressed by conforming the | |
| installation process to the respective systems installer services, | |
| since these services already provide or enable an existing | |
| installation tooling.</P> | |
| <P LANG="en-US" CLASS="western">The "Geordi" | |
| user-installation as a required step of a network-installation will | |
| cease to exist. The office applications will be fully functional from | |
| the first start. Gathering user specific data will be postponed to | |
| the first application start or queried directly from the system. | |
| Document and setting defaults will be generated on the fly during the | |
| first start or on demand.</P> | |
| <P LANG="en-US" CLASS="western">The repair mode of the setup will be | |
| dropped. Repairing the installed files is already handled by the | |
| native package mechanism (usually by a reinstall). This does not | |
| affect user driven changes since user and system files are strictly | |
| separated.</P> | |
| <P LANG="en-US" CLASS="western">Upgrading and patching will be | |
| performed by means of the respective system installer.</P> | |
| <P LANG="en-US" CLASS="western">Since Solaris and Linux do not | |
| necessarily provide a GUI for the installation we will provide a | |
| graphical front-end to guide the user through the installation | |
| process of the packages. Nevertheless the respective packages can be | |
| installed completely independent of this front-end.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.2.2 SO/OOo Configuration | |
| </H4> | |
| <P LANG="en-US" CLASS="western">Improvements for the handling of | |
| configuration data are planned that effect the whole application. | |
| These are additions to the existing configuration technology:</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Reset of configuration settings | |
| within the Options Dialog</P> | |
| <P LANG="en-US" CLASS="western">Currently, it is not possible for a | |
| user to return to his initial settings provided during the | |
| installation process. This gap will be addressed with the | |
| introduction of 'reset to default' functionality in the SO/OOo | |
| Options Dialog. A user is able to select a specific settings page | |
| within the options dialog and can press the reset button and the | |
| respective settings will be reset to their installation default. | |
| Quitting the dialog with the OK button will make the settings | |
| persistent.</P> | |
| <LI><P LANG="en-US" CLASS="western">Protection of configuration | |
| settings.</P> | |
| <P LANG="en-US" CLASS="western">Administrators have the possibility | |
| to protect configuration settings against changes by the user, so | |
| that the settings are effectively read-only. "Geordi" | |
| reflects the read-only status only for a few selected settings in | |
| the option dialog. Settings not addressed could still be overwritten | |
| by the user and applied for the lifetime of the SO/OOo session. For | |
| the "Q" release this gap is closed and all read-only | |
| settings are reflected as such in the Options dialog.</P> | |
| </UL> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Notification handling</P> | |
| <P LANG="en-US" CLASS="western">Changes of configuration settings | |
| are currently very seldom reflected to the user. Only a few | |
| components within SO/OOo are able to listen and apply notifications | |
| of configuration settings. In some specific deployment scenarios, | |
| like SunRay deployments, it is very common that applications are | |
| long running.</P> | |
| <P LANG="en-US" CLASS="western">Therefore it is important that | |
| SO/OOo is able to react and apply configuration changes, when they | |
| occur instead of requiring a restart. "Q" addresses the | |
| misbehavior by introducing a consistent configuration notification | |
| handling.</P> | |
| </UL> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.2.3.Modern%20Look%20&%20Feel|outline"></A> | |
| 4.2.3 Modern Look & Feel</H3> | |
| <P LANG="en-US" CLASS="western">(Christian Jansen, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">Since we have started to improve the | |
| look and feel in "Geordi", we will continue this work with | |
| "Q". This chapter gives an overview of what will be done to | |
| get a more up-to-date user interface which provides more satisfaction | |
| to work with.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.3.1 Toolbars</H4> | |
| <P LANG="en-US" CLASS="western">The look and feel of toolbars will be | |
| improved by introducing a completely renewed technology for toolbar | |
| handling. They will get a modern, intuitive look and will be improved | |
| for usability. For example, the handling of dragging a toolbar will | |
| be improved by adding an area which indicates that it is possible to | |
| drag a toolbar. Toolbars will also be improved by adding more | |
| feedback during drag and drop interactions. This means for example | |
| that toolbars will be “magnetic,” so that they jump | |
| automatically to their correct position. Another important feature | |
| is that toolbars in "Q" will not use the whole application | |
| width anymore when they are docked. From the visual appearance | |
| toolbars will get a more flattened look.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.3.2 Widget style</H4> | |
| <P LANG="en-US" CLASS="western">Another very important area to | |
| improve is to renew the look of widgets (widgets in graphical user | |
| interfaces, are a combination of a graphic symbol and some program | |
| code to perform a specific function. E.g. a scroll-bar or button.) | |
| Depending on the level of system integration, SO/OOo will use the | |
| widget style of the Desktop. If this is not possible for "Q" | |
| the current widget style will be improved in a way that SO/OOo looks | |
| attractive enough in environments like Gnome 2.x /3.x or Microsoft | |
| Windows Longhorn (the successor of Microsoft Windows XP).</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.3.3 Tool Pane</H4> | |
| <P LANG="en-US" CLASS="western">With SO/OOo "Q" a “new” | |
| type of dialog will be introduced. We call this dialog Tool Pane, | |
| since it is related to tool windows, e.g. the Stylist. It works like | |
| modeless dialogs do. The Tool Pane by default will be vertically | |
| docked and positioned to the left or the right of the document. Tool | |
| Panes will be introduced in SO/OOo Impress first, because SO/OOo | |
| Impress is an application where turning to more modeless user | |
| interface makes most sense.</P> | |
| <P LANG="en-US" CLASS="western">Tool Panes can contain for example a | |
| list of predefined presentation layouts which can easily be applied | |
| to the presentation by dragging a thumbnail of a layout onto the | |
| slide. To give the Tool Panes a modern look they will come in a | |
| web-like style. Tool Panes will have less complex layouts than | |
| “standard” dialogs, this assures a much easier handling | |
| and saves time when creating a presentation.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.3.4 Dialog Design In General</H4> | |
| <P LANG="en-US" CLASS="western">SO/OOo "Q" dialogs will be | |
| improved in the following areas:</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Disabled items will not have a | |
| 3D style, a disabled state will only be grayed out.</P> | |
| <LI><P LANG="en-US" CLASS="western">Tool Windows, like the color | |
| palette, will be modernized by removing the old fashioned | |
| 3D-borders.</P> | |
| <LI><P LANG="en-US" CLASS="western">Selections, like they are for | |
| example displayed in the Gallery, will be replaced by a more | |
| state-of-the-art look.</P> | |
| </UL> | |
| <H4 LANG="en-US" CLASS="western">4.2.3.5 AutoPilots (Wizards)</H4> | |
| <P LANG="en-US" CLASS="western">Currently, many AutoPilots in | |
| "Geordi" are designed differently from each other. Some of | |
| them are more than five years old and never changed in their | |
| appearance. For SO/OOo "Q" the look of the AutoPilots will | |
| be unified to a design which is orientated towards a typical Wizard | |
| design used by Mozilla or other applications like an Installer. | |
| Having a consistent look over all AutoPilots within SO/OOo improves | |
| usability and provides a higher overall satisfaction because users | |
| will come faster to a result. The renewed AutoPilots will also come | |
| with a minimum of technical expressions, users will be assisted | |
| through the steps by adding short notes or explanations into the | |
| dialog.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.3.6 System Integration</H4> | |
| <P LANG="en-US" CLASS="western">Being a good citizen in a desktop | |
| environment is a very important topic. The SO/OOo system integration | |
| will be improved for Gnome based Desktops. System integration for the | |
| look and feel means that typical desktop behaviors or looks have to | |
| be also used in SO/OOo e.g., the mouse pointer has to look in SO/OOo | |
| the same as on the desktop.</P> | |
| <P LANG="en-US" CLASS="western">A good system integration includes | |
| also a set of document and application icons which fit the style of | |
| the desktop, on that SO/OOo runs. For "Q" we will have icon | |
| sets, that will take care of the typical style of the desktop | |
| environments.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.2.4.Integration%20(Plug-ins,%203rd%20party%20applications)|outline"></A> | |
| 4.2.4 Integration (Plug-ins, 3rd party applications)</H3> | |
| <P LANG="en-US" CLASS="western">(Mathias Bauer, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">The main subject of this chapter is | |
| about linking and embedding data in or from SO/OOo. To better | |
| understand this, here is a short description of the current | |
| functionality and the history of its development.</P> | |
| <P LANG="en-US" CLASS="western">In the past SO/OOo was made up by | |
| single applications that supported the OLE compound document | |
| architecture and so were able to embed and link objects from other | |
| applications that also support this architecture. The same technology | |
| was used to embed objects from the different SO/OOo applications into | |
| each other.</P> | |
| <P LANG="en-US" CLASS="western">The biggest drawback of this approach | |
| was that it worked only on Microsoft Windows. SO/OOo versions on | |
| other platforms were only able to display a cached representation of | |
| the embedded object (usually a GDI metafile).</P> | |
| <P LANG="en-US" CLASS="western">When SO/OOo was redesigned to follow | |
| a platform independent approach for its GUI, the support for OLE was | |
| removed with the exception of the ability to embed 3rd party objects | |
| into SO/OOo and activate them in an external window on Microsoft | |
| Windows (so called “Outplace activation”). The more | |
| advanced “Inplace activation” of 3rd party objects | |
| (editing embedded objects in an own window inside the embedding | |
| container document) was abandoned and also the ability to embed | |
| SO/OOo objects into 3rd party applications was completely removed. | |
| Another dropped feature was the ability to link to external files | |
| instead of embedding them.</P> | |
| <P LANG="en-US" CLASS="western">The internal embedding functionality | |
| (embedding SO/OOo documents into each other) still used the old code | |
| formerly written to wrap the OLE interfaces, but most of the OLE | |
| related parts of the implementation were removed. Because we didn't | |
| have any replacement for OLE, all SO/OOo modules had to be put into | |
| one single application, otherwise we would lose the ability to | |
| activate SO/OOo “Inplace” even in our own applications.</P> | |
| <P LANG="en-US" CLASS="western">Meanwhile, customers responded with | |
| several suggestions for improvement. These suggestions included the | |
| following: | |
| </P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Inplace Activation is seen as | |
| indispensable functionality of modern applications on Microsoft | |
| Windows.</P> | |
| <LI><P LANG="en-US" CLASS="western">The inability to embed SO/OOo | |
| objects into other applications is a strong competitive disadvantage | |
| against the competing applications if the customer uses such | |
| application techniques in his own IT solutions.</P> | |
| </UL> | |
| <H4 LANG="en-US" CLASS="western">4.2.4.1 Support for OLE</H4> | |
| <P LANG="en-US" CLASS="western">The following concept will show how | |
| SO/OOo can get the needed functionality and how we can develop this | |
| in a multi step procedure.</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo can embed its own formats on | |
| all platforms and also OLE objects from other applications on | |
| Microsoft Windows. "Geordi" adds the new feature that | |
| SO/OOo objects can be embedded via OLE into other applications' | |
| documents on Microsoft Windows. In this case and also in the case of | |
| 3rd party objects embedded in SO, activation of the object is only | |
| possible “Outplace”, no “Inplace” activation | |
| is possible. | |
| </P> | |
| <P LANG="en-US" CLASS="western">“Q” will allow “Inplace” | |
| activation in both cases and also add the currently missing feature | |
| of linked objects.</P> | |
| <P LANG="en-US" CLASS="western">Besides that the whole embedding | |
| functionality and API (currently C++, in future UNO based) will be | |
| redesigned to support arbitrary embedding techniques, objects and | |
| persistence models. The switch to an API solution will also | |
| drastically improve the maintainability, stability and extendibility | |
| of the code.</P> | |
| <P LANG="en-US" CLASS="western">Some examples for features that will | |
| be enabled by these changes:</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">It might be possible to add | |
| support for comparable embedding and activation procedures from | |
| other platforms like Bonobo on Gnome (if there is a demand for | |
| that). This can be done without changing any existing code, only | |
| some new services have to be implemented that use the same | |
| interfaces as the services that are used to support OLE. Because the | |
| OLE and Bonobo interfaces are quite similar, this seems to be a | |
| reachable goal for later steps.</P> | |
| <LI><P LANG="en-US" CLASS="western">Embedding, persistence and | |
| activation will be treated as orthogonal functionality, that means | |
| embedded objects are not forced to support persistence or | |
| activation. So we can have embedded and activatable objects without | |
| own persistence data (“lightweight” objects) like | |
| embedded charts that get their data from an embedding container. | |
| This is a feature that makes our own charts more usable and more | |
| comparable to state-of-the-art solutions.</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">The enhanced embedding capabilities | |
| also improve the interoperability of Microsoft Office with StarOffice | |
| on the file level. In StarOffice 6.0 embedded SO/OOo objects in | |
| exported Microsoft Office documents are stored in Microsoft Office | |
| file format or in our old binary format. The first alternative has | |
| the drawback that the object must be exported and imported back when | |
| loaded again and this export/import cycle may cause some data loss. | |
| The latter alternative has the drawback that there is no way to | |
| activate the embedded object in the document if it is loaded into the | |
| Microsoft Office application, and of course the old binary format is | |
| also at risk to cause data loss, <SPAN LANG="en-US"><FONT SIZE=3>e.g.</FONT></SPAN> | |
| we will lose all CJK attributes). | |
| </P> | |
| <P LANG="en-US" CLASS="western">Since "Geordi" those | |
| objects can be stored as full featured OLE objects using our XML file | |
| format, with full support for activation in a Microsoft Office | |
| container without any possible data loss. “Q” will add | |
| the Inplace Activation of these objects in the Microsoft Office | |
| container and so enhance the user experience and interoperability.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.4.2 Browser Integration</H4> | |
| <P LANG="en-US" CLASS="western">A first implementation of a | |
| Mozilla/Netscape plug-in for Windows already exists, along with | |
| ActiveX control for Microsoft Internet Explorer, and a signed Java | |
| applet. All these objects when embedded into a browser use a local | |
| SO/OOo installation to view SO/OOo documents inside a browser.</P> | |
| <P LANG="en-US" CLASS="western">In “Q” the plug-in will | |
| be completed and extended to other platforms. All objects will get | |
| some enhancements and optimizations, because even the ActiveX control | |
| and the Java applet suffer from some usability problems.</P> | |
| <P LANG="en-US" CLASS="western">We will enable editing functionality | |
| for documents loaded by the embedded browser objects.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.4.3 Integration of 3rd party UNO | |
| components</H4> | |
| <P LANG="en-US" CLASS="western">In "Geordi" we developed | |
| the very powerful Addon concept that already enables customers to use | |
| our ODK to develop components that can be easily integrated into | |
| SO/OOo and the SO/OOo GUI. Especially the GUI integration will be | |
| enhanced in “Q” together with the changes in the | |
| application framework GUI code.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.4.4 Integration with mail | |
| clients</H4> | |
| <P LANG="en-US" CLASS="western">Will be determined later.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.4.5 Integration of media files | |
| into SO/OOo</H4> | |
| <P LANG="en-US" CLASS="western">Currently SO/OOo can only use browser | |
| plug-ins to play videos in <SPAN LANG="en-US"><FONT SIZE=3>e.g.</FONT></SPAN> | |
| a presentation, and unfortunately these plugins do not work in SO/OOo | |
| on Linux or Solaris. So a different and more powerful way to work | |
| with media files is needed. Possibly this can be combined with the | |
| new embedding API mentioned in the section about OLE.</P> | |
| <H4 LANG="en-US" CLASS="western">4.2.4.6 Support for filter | |
| development</H4> | |
| <P LANG="en-US" CLASS="western">SO/OOo already has a concept for the | |
| development of filter components. In the past very often the | |
| necessary configuration files for filters caused some problems, so | |
| the filter configuration will be changed for a better manageability. | |
| Additionally all internal filters will be converted to real filter | |
| components to make it easy to replace them.</P> | |
| <H2 LANG="en-US" CLASS="western"><A NAME="4.3.Upcoming%20Opportunities|outline"></A> | |
| 4.3 Upcoming Opportunities</H2> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.3.1.Asian%20and%20CTL%20languages|outline"></A> | |
| 4.3.1 Asian and CTL languages</H3> | |
| <P LANG="en-US" CLASS="western">(Falko Tesch, July 2003)</P> | |
| <H4 LANG="en-US" CLASS="western">4.3.1.1 CJK Requirements</H4> | |
| <P LANG="en-US" CLASS="western">Since SO/OOo is already CJK enabled | |
| and has a lot of CJK-specialized features, the "Q" release | |
| aims more on a sophistication and refinement of existing features.</P> | |
| <P LANG="en-US" CLASS="western">This applies to all applications such | |
| as Calc, Writer and Impress/Draw.</P> | |
| <P LANG="en-US" CLASS="western">Improvements are to be done in the | |
| following areas:</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Text Grid</P> | |
| <P LANG="en-US" CLASS="western">For Asian users the text grid is a | |
| valuable help to learn writing in school as well as a traditional way | |
| of writing in good manner and style.</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo text grid abilities will be | |
| enhanced by more versatile printing options, more default templates | |
| to choose from and additional adjustments that can be applied on the | |
| behavior of Western text within text grid.</P> | |
| <P LANG="en-US" CLASS="western">Doing so will put SO/OOo in line or | |
| ahead of our competitors and enhancing our text grid it is a valuable | |
| issue gathering more acceptance of traditional users.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Enhanced IME Support</P> | |
| <P LANG="en-US" CLASS="western">The IME is the most crucial | |
| instrument for all East-Asian users. It enables them to input their | |
| characters. While Sun Solaris provide standard IMEs, the Linux | |
| community provides various ones.</P> | |
| <P LANG="en-US" CLASS="western">Customers have requested that SO/OOo | |
| support as many IMEs as possible. It will help SO/OOo to consolidate | |
| its position within the Asian Linux world as it is already leading in | |
| the Western world.</P> | |
| <P LANG="en-US" CLASS="western">Furthermore we will have a more | |
| sophisticated read-out of IMEs. Since the IMEs that come with | |
| Microsoft Windows are all using an extensive unified interface | |
| (contrary to Linux for example) users are used to certain amenities, | |
| such as automatic language detection while typing. Unfortunately the | |
| variety of different IMEs throughout Microsoft Windows, Sun Solaris | |
| and Linux brought us to choose the smallest common denominator. This | |
| will change.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">AutoCompletion et al</P> | |
| <P LANG="en-US" CLASS="western">“Q” will support | |
| AutoCompletion and AutoCorrection for all East-Asian languages. | |
| </P> | |
| <H4 LANG="en-US" CLASS="western">4.3.1.2 CTL Requirements</H4> | |
| <P LANG="en-US" CLASS="western">Numbering and Bullets</P> | |
| <P LANG="en-US" CLASS="western">In Arabic and Hebrew regions people | |
| write right-to-left (RTL). Therefore also they use numberings and | |
| bullets on the right side with right alignment.</P> | |
| <P LANG="en-US" CLASS="western">Since “Geordi” takes care | |
| of basic features of aligning bullets, "Q" will give more | |
| intelligent automatism like in well-known products on these markets.</P> | |
| <P LANG="en-US" CLASS="western">Also a bigger variety on localized | |
| numbering symbols will attract more users.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Special Formatting</P> | |
| <P LANG="en-US" CLASS="western">Like East-Asians also CTL users are | |
| accustomed to various ways of formatting their text. These are mostly | |
| minor issues but having them will give SO/OOo a more complete and | |
| respectable estimate. | |
| </P> | |
| <P LANG="en-US" CLASS="western">Also addressing certain features not | |
| only to CTL users in general but to address them to the specific user | |
| group (like Arabic) will enhance it even more.</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">RTL-UI</P> | |
| <P LANG="en-US" CLASS="western">While a lot of Arabic and Hebrew | |
| people are used to work in an English left-to-right (LTR) environment | |
| to accomplish their (RTL) work, they highly value if a product is | |
| also available in their local (RTL) flavor. Even if a RTL-UI is not | |
| perfect and the users might switch back to an English LTR-UI the | |
| RTL-UI can often be considered the “door-opener” to these | |
| people.</P> | |
| <P LANG="en-US" CLASS="western">“Geordi” already provides | |
| a framework for RTL-UI. Early adopters such as Tk Open Systems in | |
| Israel have brought up first promising prototypes. "Q" will | |
| be a major leap forward to give those people tools at hand to | |
| generate a full RTL-UI enabled office for the Arabic and Hebrew | |
| market.</P> | |
| <H4 LANG="en-US" CLASS="western">4.3.1.3 Generic I18N Requirements</H4> | |
| <P LANG="en-US" CLASS="western">Documentation and UI Style</P> | |
| <P LANG="en-US" CLASS="western">Most users in East Asia and in CTL | |
| countries are used to an existing set of terms and nomenclature. | |
| SO/OOo will use this to ease transfer and learning for the users. It | |
| will also familiarize them quicker with our product.</P> | |
| <P LANG="en-US" CLASS="western">Special attention has to be given on | |
| possible cultural issues and clashes with UI terms as well as with | |
| the localized documentation (see the PR China - Taiwan example in the | |
| Overview section).</P> | |
| <P LANG="en-US" CLASS="western">To accomplish this goal “Q” | |
| will provide the user with a good and easy-to-read online help as | |
| well as printed documentation in their native language.</P> | |
| <P LANG="en-US" CLASS="western">Another important issue is technical | |
| documentation that will give engineers in those countries the feeling | |
| of being taken serious and valued (even if they feel more comfortable | |
| with the English originals after all).</P> | |
| <P LANG="en-US" CLASS="western"><BR><BR> | |
| </P> | |
| <P LANG="en-US" CLASS="western">Impress and Calc Issues</P> | |
| <P LANG="en-US" CLASS="western">While there is a UI and there is a | |
| document area there is also a canvas that resides “in between” | |
| the document view and the application UI.</P> | |
| <P LANG="en-US" CLASS="western">Even in a non-RTL-UI RTL documents | |
| and RTL canvas are common to Arabic and Hebrew customers.</P> | |
| <P LANG="en-US" CLASS="western">”Geordi” already takes | |
| this in account and automatically mirrors canvas tools such as | |
| rulers, scroll-bars etc.</P> | |
| <P LANG="en-US" CLASS="western">In "Q" Impress/Draw and | |
| Calc will follow.</P> | |
| <P LANG="en-US" CLASS="western">RTL users are have the habit to start | |
| reading from upper right to lower left. This means for Calc and | |
| Impress that the column and row headers have to mirror (in Calc) and | |
| the arrangement of slides templates in Impress have to be mirrored. | |
| </P> | |
| <H4 LANG="en-US" CLASS="western">4.3.1.4 Tool Integration</H4> | |
| <P LANG="en-US" CLASS="western">Every country has its own special | |
| cases and rules. And not all can be addressed by a single product | |
| such as SO/OOo. | |
| </P> | |
| <P LANG="en-US" CLASS="western">But when launching in those markets a | |
| build-in support for the most important tools and their vendors is | |
| advisable. | |
| </P> | |
| <P LANG="en-US" CLASS="western">Examples:</P> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Multi-language multi-script | |
| countries like India (7 major languages and scripts) are used to use | |
| on-screen keyboards to visualize the various keyboard layouts.</P> | |
| </UL> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">East-Asian countries like Korea | |
| that use Chinese characters (Hanja) in their everyday work need | |
| transliterations, dictionaries and special input methods.</P> | |
| </UL> | |
| <UL> | |
| <LI><P LANG="en-US" CLASS="western">Arabic world that uses a very | |
| sophisticated style of Arabic to create and edit holy texts (Koran).</P> | |
| </UL> | |
| <P LANG="en-US" CLASS="western">All these countries have one thing in | |
| common:</P> | |
| <P LANG="en-US" CLASS="western">They all have local vendors that | |
| create, program and sell value-added software for office productivity | |
| suites.</P> | |
| <P LANG="en-US" CLASS="western">Supporting these tools and/or giving | |
| developers of such companies documentation at hand to provide tools | |
| also for SO/OOo can raise the meter for acceptance considerably. | |
| (Again this shows how valuable a localized technical documentation | |
| is.)</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.3.2.Digital%20Signatures|outline"></A> | |
| 4.3.2 Digital Signatures</H3> | |
| <P LANG="en-US" CLASS="western">(Michael Brauer, May 2003)</P> | |
| <P LANG="en-US" CLASS="western">As said above, digital signatures | |
| themselves are a relatively new topic for office applications, but | |
| the requirement to protect data from being modified has always | |
| existed. In SO/OOo, like in other office suites, it has been | |
| addressed by documents and document pieces that could be protected | |
| from being edited, like text sections in Writer or tables in Calc. | |
| Sometimes the protection is a simple option. Sometimes the | |
| protection is combined with a password. In both cases, these | |
| features are nothing more than an edit protection built into SO/OOo. | |
| They do not add any real security to a document, because they cannot | |
| protect documents from being changed outside SO/OOo. This in fact has | |
| become much easier with the introduction of the XML file formats, | |
| that even removed the little piece of security that the proprietary | |
| and undocumented binary file formats had.</P> | |
| <P LANG="en-US" CLASS="western">Though the existing protection | |
| features don't offer security, they show where demand for and benefit | |
| of digital signatures seems to be highest. Therefore, adding digital | |
| signatures to SO/OOo in “Q” will start with adding | |
| digital signatures to the existing protection features. This not only | |
| makes these features secure, it also allows customers to use | |
| signatures with very little learning effort. Most important however | |
| is that customers this way get a solid set of digital signature | |
| features that they can use in their environment and in their | |
| workflows. To better support digital signature based workflows from | |
| the beginning, multiple independent signatures will be supported for | |
| one and the same document piece. Based on customer experience with | |
| these features, support for hierarchical signatures or other kinds of | |
| nested signatures might be added in later SO/OOo versions as well.</P> | |
| <P LANG="en-US" CLASS="western">To actually save digital signatures | |
| in SO/OOo files, W3C's XML Signature recommendation will be used. It | |
| is not only a standard that very well fits into the strategy of | |
| reusing existing standards for SO/OOo's file format, but it also can | |
| be assumed that this standard will be supported widely in the near | |
| future.</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo's signature features for | |
| documents will make use of the same security framework that is used | |
| for other security features in SO/OOo, like for Basic macros. That is | |
| to say, there will be one key management and a common set of | |
| signature methods in SO/OOo.</P> | |
| <P LANG="en-US" CLASS="western">In contrast to signatures, encryption | |
| is a feature that has been supported by office applications for a | |
| long time. In "Geordi", encryption is available for whole | |
| documents. Since there was no encryption standard available at the | |
| time the XML file format was introduced, encryption currently is done | |
| as a SO/OOo specific extension of the ZIP packages that contain the | |
| XML files. As soon as encryption based on the recently finished W3C | |
| XML Encryption recommendation becomes more widespread, that may be | |
| the case for “Q” or later, it will be supported by SO/OOo | |
| as well. It again will make use of SO/OOo's common security framework | |
| for key management and encryption methods. | |
| </P> | |
| <P LANG="en-US" CLASS="western">Since the W3C Encryption | |
| specification does not only support encryption of whole documents but | |
| also of document parts, future SO/OOo versions might also support | |
| encryption for document parts only, like this will be the case for | |
| signatures in “Q” already.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.3.3.Compelling%20upgrade%20features%20(e.g.%20multi%20media,%20OCR,%20DB)|outline"></A> | |
| 4.3.3 Compelling upgrade features (e.g. multi media, OCR, DB)</H3> | |
| <P LANG="en-US" CLASS="western">To be determined later.</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.3.4.Web%20Services|outline"></A> | |
| 4.3.4 Web Services</H3> | |
| <P LANG="en-US" CLASS="western">(Kai Sommerfeld, May 2003)</P> | |
| <H4 LANG="en-US" CLASS="western">4.3.4.1 SO/OOo Web-Services Client | |
| (WebServices-1)</H4> | |
| <P LANG="en-US" CLASS="western">Basically, from the current state, | |
| there are three approaches to cover Web Services partly or fully. The | |
| different approaches are:</P> | |
| <OL TYPE=A> | |
| <LI><P LANG="en-US" CLASS="western">Access Web Services via Java | |
| mechanisms from Java.</P> | |
| <LI><P LANG="en-US" CLASS="western">Use an invocation based | |
| approach.</P> | |
| <LI><P LANG="en-US" CLASS="western">Have a full featured UNO | |
| language binding</P> | |
| </OL> | |
| <P LANG="en-US" CLASS="western">A: As UNO components for SO/OOo can | |
| already be written in Java, there is already the possibility to | |
| access web services. The usage of web services via Java is limited to | |
| Java and does not allow to export the Offices API as a web service.</P> | |
| <P LANG="en-US" CLASS="western">B: A diploma thesis has been written | |
| to have more direct UNO support. With this UNO component, it is | |
| possible to seamlessly access web services from Star Basic (please | |
| see | |
| http://udk.openoffice.org/java/examples/wsproxy/component_description.html | |
| for more details). The implementation of this component is not yet | |
| feature complete. Most Web Services can be accessed, but some, that | |
| use special features currently cannot be used. To use it for general | |
| purpose, it is necessary to extend the component to support this | |
| features. Being a UNO service, this component can be in principal | |
| used from any language supported by UNO, for instance SO/OOo Basic, | |
| C++ or Java. But access to web services is only for these languages | |
| seamless, which support the XInvocation and the XPropertySet for | |
| invoking methods respectively accessing properties. The only language | |
| currently doing this is SO/OOo Basic. For all other languages it is | |
| kind of nasty and inconvenient. | |
| </P> | |
| <P LANG="en-US" CLASS="western">C: The most general and most | |
| expensive approach to web services support in SO/OOo respectively UNO | |
| is a web services language binding. This renders web services to be | |
| fully UNO accessible and allows the export of UNO objects as web | |
| services as well as the import of any web service. Web services are | |
| then directly programmable in any UNO supported language, without any | |
| additional burden.</P> | |
| <H4 LANG="en-US" CLASS="western">4.3.4.2 SO/OOo UDDI Browser | |
| (WebServices-2)</H4> | |
| <P LANG="en-US" CLASS="western">There are several free UDDI browsers | |
| available from 3rd parties. A good example is a web based browser at | |
| http://www.soapclient.com/uddisearch.html. This browser includes a | |
| generic SOAP client, which supports even live testing of Web | |
| Services. UDDI browsers can be used to obtain the URL of the WSDL | |
| file for certain Web Services. The WSDL file can then be used to | |
| create a UNO component instance representing the Web Service, like | |
| described above. There seems to be no real need for a SO/OOo UDDI | |
| Browser, because the actual value-add is very small. The | |
| implementation effort would be medium to high.</P> | |
| <P LANG="en-US" CLASS="western">Another approach would be the | |
| integration of Web Services into the coming Scripting Framework. Web | |
| Services could then seamlessly be offered via the macro selection | |
| dialog. Further investigation is needed, to clarify details.</P> | |
| <H4 LANG="en-US" CLASS="western">4.3.4.3 SO/OOo Web Services Provider | |
| (not covered by requirements so far)</H4> | |
| <P LANG="en-US" CLASS="western">Web Services use SOAP for remote | |
| method invocation. A UNO-SOAP language binding could be implemented | |
| to offer every SO/OOo functionality that is available as a UNO | |
| service as a Web Service. See also “SO/OOo Web-Services | |
| Client”.</P> | |
| <P LANG="en-US" CLASS="western">The effort to implement a UNO-SOAP | |
| language binding is very high (raw estimation: at least 3 months).</P> | |
| <H3 LANG="en-US" CLASS="western"><A NAME="4.3.5.Intelligent%20Document%20Tags%20|outline"></A> | |
| 4.3.5 Intelligent Document Tags | |
| </H3> | |
| <P LANG="en-US" CLASS="western">(Andreas Martens, May 2003)</P> | |
| <H4 LANG="en-US" CLASS="western">4.3.5.1 User</H4> | |
| <P LANG="en-US" CLASS="western">If an Intelligent Document Tag | |
| component is installed, the user is able to activate and deactivate | |
| it. If it's activated the recognized keywords are underlined. The | |
| mouse cursor changes its appearance if it is above such keyword. A | |
| context menu shows up if the user presses the right mouse button. The | |
| content of the menu are the possible actions for this keyword, | |
| typically the names of the dictionaries which contains the keyword. | |
| The user choose an action and the component reacts accordingly.</P> | |
| <H4 LANG="en-US" CLASS="western">4.3.5.2 SO/OOo</H4> | |
| <P LANG="en-US" CLASS="western">SO/OOo has to separate the document | |
| content into sentences. These sentences will be passed to the | |
| component. If any sentence is changed by the user it has to be | |
| analyzed again.</P> | |
| <P LANG="en-US" CLASS="western">SO/OOo controls the underlining and | |
| the mouse cursor appearance for keywords. If the user calls the | |
| context menu the SO/OOo has to ask the component for the menu | |
| entries. If the user chooses an entry the SO/OOo calls the component | |
| with the chosen entry (in form of a number, an ID). | |
| </P> | |
| <H4 LANG="en-US" CLASS="western">4.3.5.3 Component</H4> | |
| <P LANG="en-US" CLASS="western">The component has to support three | |
| interfaces.</P> | |
| <P LANG="en-US" CLASS="western">If a sentence has been passed the | |
| component has to deliver all start- and end-positions of keywords in | |
| this sentence.</P> | |
| <P LANG="en-US" CLASS="western">If a sentence and a character | |
| position have been passed the component has to deliver the available | |
| actions as context menu entries and the corresponding IDs.</P> | |
| <P LANG="en-US" CLASS="western">If the component is called with such | |
| an ID it has to react accordingly (see examples above).</P> | |
| </body> | |
| </HTML> |