https://wiki.openoffice.org/w/api.php?action=feedcontributions&feedformat=atom&user=TraApache OpenOffice Wiki - User contributions [en]2026-05-06T04:20:44ZUser contributionsMediaWiki 1.35.14https://wiki.openoffice.org/w/index.php?title=LD_LIBRARY_PATH&diff=34067LD LIBRARY PATH2007-06-02T18:09:59Z<p>Tra: </p>
<hr />
<div>Some arguments, links, etc. why the use of LD_LIBRARY_PATH is bad in general.<br><br />
[http://prefetch.net/articles/linkers.badldlibrary.html LD_LIBRARY_PATH is not the solution]<br><br />
[http://www.xahlee.org/UnixResource_dir/_/ldpath.html Why LD_LIBRARY_PATH is bad]</div>Trahttps://wiki.openoffice.org/w/index.php?title=LD_LIBRARY_PATH&diff=34066LD LIBRARY PATH2007-06-02T18:09:32Z<p>Tra: </p>
<hr />
<div>Some arguments, links, etc. why the use of LD_LIBRARY_PATH is bad in general.<br><br />
[http://prefetch.net/articles/linkers.badldlibrary.html LD_LIBRARY_PATH is not the solution]<br><br />
[http://www.xahlee.org/UnixResource_dir/_/ldpath.html Why LD_LIBRARY_PATH is bad]<br />
Page edited by Tino Rachui</div>Trahttps://wiki.openoffice.org/w/index.php?title=2nd_Mac_porters_meeting&diff=211882nd Mac porters meeting2006-11-28T20:44:02Z<p>Tra: /* Content */</p>
<hr />
<div>=== When? ===<br />
<br />
<big>'''2nd and 3rd of December 2006'''</big><br />
<br />
=== Where? ===<br />
<br />
Google Hamburg<br />
ABC-Strasse 19<br />
20354 Hamburg<br />
Germany<br />
<br />
==='''How to get there'''===<br />
Airport: HAM<br />
There is a bus connection from the airport. <br />
<br />
Hamburg Airport does not yet have a direct rail connection to the city centre. <br />
The nearest subway & suburban railway station, Ohlsdorf, is served by<br />
suburban rail lines S1 and S11 and the subway line U1; all of these will take you<br />
to or from the main station, Hauptbahnhof, or Jungfernstieg [city centre].<br />
<br />
Ohlsdorf station and the Terminals are connected by the number 110 bus,<br />
the "Airport-Express", which runs every 10 minutes.<br />
<br />
A taxi costs about 10 euros in one direction.<br />
<br />
[FIXME] : find additionnal informations for people who didn't find how connect from airport to the meeting<br />
( both directions)<br />
<br />
[[Image:060818_CityAnb-W.jpg]]<br />
<br />
-> search in Hamburg Airport website :[[http://www.ham.airport.de/index_en.phtml Hamburg Airport Website]]<br />
<br />
Other links : [[http://www.ham.airport.de/en/verkehrsanbindung.html City anbindung]]<br />
<br />
=== What? ===<br />
<br />
A fun weekend of hacking! Google will provide the following facilities on-site:<br />
<br />
* A largish room with projectors for talks<br />
* 5 Mac PRO workstations for hacking use during the conference<br />
* Lunch on Saturday and Sunday<br />
<br />
Google status: Things look OK at this point, unless there are any last minute snags.<br />
<br />
Other hardware available : ericb will provide a macbook pro + a mac mini (powerpc) with prebuilt Aqua version<br />
<br />
Tino will provide an Imac 20" for workshops<br />
<br />
=== Where to stay ===<br />
<br />
'''NB: Rates might not be accurate'''<br />
<br />
'''Side Hotel'''<br />
<br />
Side Hotel<br />
Drehbahn 49<br />
20354 Hamburg<br />
+49 (040) 30-99-90<br />
+49 (040) 30-99-93-99 fax<br />
info@side-hamburg.de<br />
reservation@side-hamburg.de<br />
<br />
This is a very nice, modern hotel within seven minutes' walk from the office.<br />
<br />
Superior Category<br />
Single Room: €135,00<br />
Double Room: €160,00<br />
<br />
Deluxe Category<br />
Single Room: €150,00<br />
Double Room: €175,00<br />
<br />
These prices include breakfast, and all taxes.<br />
<br />
'''Four Seasons Hotel'''<br />
<br />
Raffles Vier Jahreszeiten (Four Seasons Hotel)<br />
Neuer Jungfernstieg 9-14<br />
+49 (040) 34-94-0<br />
+49 (040) 34-94-2600 fax<br />
emailus.hvj@raffles.com<br />
<br />
The name "Four Seasons" speaks for itself.<br />
<br />
Superior Category (view to the courtyard)<br />
Single Room: €155,00<br />
Double Room (single occupancy): €180,00<br />
Double Room (double occupancy): €205,00<br />
<br />
Deluxe Category (view to the Alster)<br />
Single Room: €220,00<br />
Double Room: €270,00<br />
<br />
These prices do not include breakfast, but do include all taxes.<br />
<br />
'''Marriott Hotel'''<br />
Very near to the office is the:<br />
<br />
Marriott Hotel<br />
ABC-Straße 52<br />
20354 Hamburg<br />
+49 (040) 350-50<br />
<br />
Special Rates<br />
Standard Deluxe Single or Double Room: €146,00<br />
<br />
These prices include a French buffet (coffee, tea, croissants, etc).<br />
<br />
This is a standard chain hotel, within two minutes' walk from the office.<br />
<br />
<pre><br />
Additionnal Hotel (ericb reserved here), very close to Google Office :<br />
<br />
Hotel Oper, Drehbahn 15- 23 Hamburg, 20354<br />
http://hotels.germany-bookings.com/hotel/de/topoper.html<br />
</pre><br />
<br />
===Todo===<br />
<br />
2) write a list of interested people<br />
<br />
[[user:ericb]] ericb<br />
pjanik<br />
obr<br />
fheckl<br />
tra<br />
ssa<br />
[[user:jsi]]<br />
[[user:mmp]]<br />
kaib<br />
martink<br />
[[user:smsm1]] shaunmcdonald<br />
[[user:cloph]] cloph (to be confirmed)<br />
<br />
[complete the list]<br />
<br />
4) Find money for travels, rooms and food<br />
<br />
By plane? <br />
come together by car?<br />
Note: I'll propose the amount of money we need to Louis.<br />
<br />
=== Content ===<br />
<br />
Common sessions / Workshops around native issues: <br />
<br />
<pre><br />
<br />
Warning: this is a draft <br />
<br />
(Initial version Eric Bachard, modifications by Tino Rachui) :<br />
<br />
Agenda<br />
<br />
- Greeting and Introduction<br />
- Latest Mac porting news<br />
- Status of the Mac port<br />
- Definition of and agreement on an agenda for the weekend<br />
- Go ...<br />
<br />
<br />
Suggestions of interesting topics for the meeting:<br />
<br />
- Technical description of work in progress<br />
- What needs to be done toward an alpha version of the port<br />
- Define manageable chunks of work <br />
<br />
Technical points to fix together:<br />
<br />
1) Reorganize the tree for native version ( ericb'd vote for an obr task :-) )<br />
<br />
2) Improve configure for both Aqua and X11 version / ( Claude Lohmaier )<br />
A) modify configure step : provide config.parms.aqua, <br />
config.parms.X11 containing specific Mac OS X command line, and just use <br />
./configure --with-config.parms=config.parms.aqua ( or config.parms.X11 ) <br />
<br />
B) or fix configure. Current issues : bad or wrong/missing autodetection <br />
of things<br />
<br />
3) Session (workshop?) about native controls implementation : <br />
code review/design or continue the work <br />
<br />
4) In case everything is not ready<br />
current work in progress: fonts <br />
(multiline sallayout : understand what has to be done, describe the todo) <br />
- workshop about debugging OpenOffice.org on Mac OS X :<br />
gdb .. maybe complete with leaks and/or other tools ?<br />
<br />
Possible action items : <br />
<br />
- discuss and define a precise todolist<br />
- divide the work <br />
- describe party : describe with words and sentences what has exactly to be<br />
done for missing parts: <br />
<br />
Where in the code, who can provide informations, tips...etc<br />
- write a list of missing classes and methods.<br />
- define code intregration strategy<br />
- define rules for code review based on wiki<br />
- define a plan for Aqua Human Interface Guidelines integration <br />
(modify menus ? ) <br />
<br />
Other subjects for what volunteers can propose workshops :<br />
<br />
- Debuging /using tools for track and /or analyse bugs (very well adapted <br />
to workshops) <br />
- QA workshop for Mac OS X <br />
- windowing (salinst*)<br />
- redrawing<br />
- fonts<br />
- native printing (WIP by Yvan Barthélemy, who will provide informations ) <br />
- packaging <br />
..etc (propose other)<br />
</pre><br />
<br />
===Agenda===<br />
<br />
{| border="1"<br />
|+ Saturday<br />
! Time !! Activity<br />
|-<br />
! 10:00 - 12:00<br />
| Early bird hacking<br />
|-<br />
! 12:00 - 13:00<br />
| Sessions<br />
|-<br />
! 13:00 - 19:00<br />
| Porting, porting ..<br />
|}<br />
<br />
{| border="1"<br />
|+ Sunday<br />
! Time !! Activity<br />
|-<br />
! 10:00 - 14:30<br />
| Morning HackAThon<br />
|-<br />
! 14:30 - 15:00<br />
| Closing session for travellers<br />
|-<br />
! 15:00 - 18:00<br />
| More hacking!<br />
|}<br />
<br />
<br />
<br />
[[User:Ericb|Ericb]] 11:16, 10 October 2006 (CEST)<br />
<br />
[[Category:Porting]]<br />
[[Category:MacOSX]]<br />
[[Category:Aqua]]</div>Trahttps://wiki.openoffice.org/w/index.php?title=User:Ericb&diff=17589User:Ericb2006-09-28T07:05:58Z<p>Tra: /* Todo */</p>
<hr />
<div>==Public Documentation License Notice==<br />
<br />
The contents of this Documentation (excepted Native Port Roadmap),are subject to the Public Documentation License Version 1.0 (the "License"); you may only use this Documentation if you comply with the terms of this License. A copy of the License is available at http://www.openoffice.org/licenses/PDL.html.<br />
The Original Documentation is "Mac OS X native port". The Initial Writer of the Original Documentation is (JCA) Eric Bachard (C) 2005-2006. All Rights Reserved. (Initial Writer contact(s): ericb@openoffice.org.)<br />
<br />
=='''Mac OS X Native port'''==<br />
<br />
<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;"><br />
'''The first Mac OS X native port objective is make OpenOffice.org run without X11 use, to make it a real Mac application.'''<br />
<br />
'''The second one is respect Aqua Human interface Guidelines'''<br />
<br />
''' This is a long term work, and every help and/or contributions, like donations** are welcome.'''<br />
</div><br />
<br />
**see http://contributing.openoffice.org/index.html<br />
<br />
=='''Native Port Roadmap'''==<br />
<br />
==='''2006'''===<br />
<br />
* June 2006: work in progress <br />
<br />
- Basis: frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui)<br />
<br />
Done: <br />
implement threads<br />
create, manage instance<br />
create, manage windows (including parents)<br />
create, manage events<br />
create manage drawing, resizing<br />
create, add menus (Pavel Janik)<br />
toggle window fullscreen (Pierre de Filippis)<br />
make font server work (Stephan Schaefer)<br />
<br />
* Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now<br />
** font selection<br />
** font size<br />
** simple font attributes (bold, italic)<br />
<br />
Next step: document first part, and propose design<br />
<br />
- native filepicker (Oliver Braun)<br />
<br />
- native printing implementation (Oliver?)<br />
<br />
- native font implementation (Eric Bachard)<br />
<br />
* September 2006: <br />
<br />
- first proofs of concept: fonts, filepicker .. (more?)<br />
- show the results (OOoCon 2006?)<br />
<br />
==='''2007'''===<br />
<br />
* January 2007: first alpha implementation<br />
<br />
=='''Strategy for native port'''==<br />
<br />
'''Possible Actions''': <br />
<br />
Identify us:<br />
<br />
#Complete the arrays below<br />
#Update photos on frapr.com?<br />
<br />
Share the work:<br />
<br />
#Divide the work between little Teams<br />
#Update Todo list regularly -> needs some love these days ... [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s]<br />
<br />
Help:<br />
<br />
#Teach tools between us<br />
#Do a debug party on IRC<br />
#write documentation<br />
<br />
Meet us:<br />
<br />
#IRC<br />
#Mac Meeting (like nov2005 in Hamburg?)<br />
<br />
Inform:<br />
<br />
#Update website regularly<br />
#Blogs<br />
<br />
<br />
'''WHO''':<br />
<br />
Mac Team:<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
|Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation ||<br />
|-<br />
|ericb|| x || x || || 1 || x ||<br />
|-<br />
|pjanik|| || || || || ||<br />
|-<br />
|ssa|| || || || || ||<br />
|-<br />
|maho|| || || || || ||<br />
|-<br />
|tinor|| || || || || ||<br />
|-<br />
|schmidtm|| || || || || ||<br />
|-<br />
|ebischoff|| || || || || ||<br />
|-<br />
|obr|| || || || || ||<br />
|-<br />
|cl|| || || || || ||<br />
|-<br />
|aliscafo|| || || || || ||<br />
|-<br />
|fheckl|| || || || || ||<br />
|-<br />
|Fridrich|| || || || || ||<br />
|-<br />
|}<br />
<br />
<br />
'''Other resources''':<br />
<br />
fonts: ?<br />
<br />
events: ?<br />
<br />
QA: ?<br />
<br />
graphical: ?<br />
<br />
Communication: ?<br />
<br />
<br />
<br />
'''WHAT''': Status of most important tasks<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Task || Names|| Urgency (1=higher)|| Work in Progress || Done || Code review || Debug || Integration || <br />
|-<br />
|Get rid of X11|| || 1 || x || x || || || ||<br />
|-<br />
|Bundle|| || 1 || x || || || || | ||<br />
|-<br />
|Drawing|| || 1 || x || || || || || ||<br />
|-<br />
|Fonts|| || 1 || x || || || || || ||<br />
|-<br />
|Events management|| || 2 || x || || || || || ||<br />
|-<br />
|Controls (see list) ||ericb, aliscafo || 2 || x || || || || || ||<br />
|-<br />
|Native FilePicker|| || 3 || x || x || || || || ||<br />
|-<br />
|Native Printing|| || 3 || x || || || || || ||<br />
|-<br />
|Native SpellChecker|| || 4 || || || || || || ||<br />
|-<br />
|Player|| || 4 || x || || || || || ||<br />
|}<br />
<br />
<br />
Other tasks:<br />
<br />
Help for writing bug lists, status of bugs ..etc<br />
<br />
Write howto use gdb, leaks, other tools<br />
<br />
'''WHEN''':<br />
<br />
From Christian Lippka (last meeting, 25th of august 2006): <br />
Aug 26 00:21:38 ChristianL<br />
from my point of view what is missing for point 1:<br />
text layout, complete font support, keyboard support,<br />
fixing repaint issues, having aqua install and run out of the box<br />
<br />
'''September 2006'''<br />
<br />
Present the current state of the project at the 2006 OpenOffice conference in Lyon and Paris<br />
<br />
'''Late 2006'''<br />
<br />
fix OpenOffice.org launch<br />
fix drawing (repainting)<br />
Implement missing methods and fix most important bugs (mainly the one leading to crash) in:<br />
ATS<br />
Salgraphics<br />
Salinstance<br />
<br />
'''January or February 2007'''<br />
<br />
make Java work (works partially)<br />
make intensive debug<br />
present something working as alpha<br />
<br />
'''June 2007 '''<br />
<br />
Implementation of:<br />
native filepicker<br />
native printing<br />
<br />
=='''2nd Mac porters meeting'''==<br />
<br />
===Todo===<br />
<br />
1) define location and date<br />
Easy to attend for all people coming<br />
Some University?<br />
An airport close to the meeting is prefered<br />
<br />
2) write a list of interested people<br />
<br />
ericb<br />
pjanik<br />
obr<br />
fheckl<br />
tra<br />
<br />
[complete the list]<br />
<br />
3) define needed resources <br />
<br />
rooms for 10 to 20 people (as cheap as possible)<br />
Food?<br />
Hardware: 1 per workshop -> 4 machines would be great<br />
<br />
4) Find money for travels, rooms and food<br />
<br />
By plane? <br />
come together by car?<br />
Note: I'll propose the amount of money we need to Louis.<br />
<br />
<br />
5) Location<br />
<br />
Last minute : Hamburg will probably be prefered.<br />
<br />
Pavel proposed Prague (Florian and me would have prefered), but probably not possible.<br />
<br />
[FIXME]<br />
<br />
6) Duration <br />
<br />
A weekend: e.g. Saturday 2nd / Sunday 3rd december 2006 <br />
<br />
Other possibilities: Saturday 9th / Sunday 10th december 2006<br />
Begin of January 2007<br />
<br />
7) Content<br />
<br />
Common sessions / Workshops around native issues: <br />
<br />
- windowing (salinst*)<br />
- redrawing<br />
- fonts<br />
- controls<br />
- native printing<br />
- packaging<br />
..etc (propose other)<br />
<br />
===Agenda (can be modified)===<br />
<br />
[FIXME] create an array ..<br />
<br />
<br />
Saturday:<br />
<br />
- Common session from 12:00 to 15:00 <br />
<br />
- Workshops: From 16:00 to 19:00 <br />
<br />
[Saturday evening: some dinner in the city? ]<br />
<br />
<br />
Sunday:<br />
<br />
- Workshops from 10:00 to 12:00<br />
<br />
- Conclusions from 13:00 to 14:00<br />
<br />
Time to return after ...<br />
<br />
=='''IRC Mac port meetings'''==<br />
<br />
This section has been moved to [[MacOSXPortMeetings]].<br />
<br />
==Description of the Native Port problem==<br />
<br />
=== How does OpenOffice.org work on Mac OS X? ===<br />
<br />
Currently, on Mac OS X, OpenOffice.org uses X11, as "client": X11 is a graphical server, coming from Unix world, and able to run under Linux, *BSD, Solaris, Mac OS X.<br />
<br />
- X11 is run as an application, managed like other Apple applications.<br />
- All unix like applications are managed by X11, and from Aqua environment, only X11 is seen as only one applicatiion, <br />
even if other Unix/Linux (e.g.) applications are runing.<br />
<br />
OpenOffice.org asks X11 to display a window, waits for X11 acknowledgment, and OpenOffice.org displays the window. All transactions use the network, locally or not. the same mechanism is used for everything to be displayed.<br />
<br />
[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)<br />
<br />
=== Issues and known problems ===<br />
<br />
All events are managed by OpenOffice.org and X11, using the Xlib<br />
<br />
Only .ttf fonts type is currently available. Note: '''system fonts are available '''<br />
<br />
The rendering is made by X11, not by Mac OS X rendering engine.<br />
<br />
X11 and all its clients are seen as one application only: drag and drop protocol does not work because of that (solution: Pasteboard Manager)<br />
<br />
==== Other links ====<br />
<br />
http://wiki.services.openoffice.org/wiki/List_of_OpenOffice.org_Mac_OS_X_issues_and_problems#<br />
<br />
http://wiki.services.openoffice.org/wiki/Printing_problems_with_OpenOffice.org_2.0_for_Mac_OS_X#Reporting_printing_problems<br />
<br />
[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)<br />
<br />
== What do we have to do?==<br />
<br />
* Implement direct access to Apple graphical engine, using Apple API: Quartz2D/CoreGraphics (and replacing Xlib use)<br />
<br />
like: instantiate, manage events and threads for a graphical instance + all needed objects, drawing: manage all drawing cases<br />
<br />
* Implement native events management, using CarbonEventManager (replacing Xlib management)<br />
<br />
* Implement native font use, using Apple Type Server and ATSUI (for Unicode Imagery) (replacing X11 management)<br />
<br />
Work in progress: http://wiki.services.openoffice.org/wiki/Fonts_starting_point_and_documentation<br />
<br />
* Implement native sound, using QuickTime (replacing Java Media Framework): [[Mac OS X Porting - Native Audio and Video]]<br />
<br />
* Implement native Drag and drop, Implementing Pasteboard Manager: [[Mac OS X Porting - Native Drag and drop]]<br />
<br />
* Implement Native Filepicker<br />
<br />
* Implement Native Printing: current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]]<br />
<br />
* Implement Apple Spellchecker<br />
<br />
=='''Where is located the code to be modified?'''==<br />
<br />
Most of the changes are located in vcl (Visual Class Layer), for everything graphical, events, fonts, rendering and printing.<br />
<br />
Other, for sound and movies will be in avmedia (where the player is implemented in OpenOffice.org sources).<br />
<br />
For drag and drop, dtrans is concerned (Pasteboard Manager implementation)<br />
<br />
[FIXME]: Filepicker? Apple Spellchecker?<br />
<br />
[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)<br />
<br />
=='''How will the new implementation be tested?==<br />
<br />
Currently, all openOffice.org code can be compiled without using the Xlib. but of course, a lot of features are missing,<br />
<br />
and the final package simply won't work<br />
<br />
In vcl module", a '''toy''' called svdem is built at buildtime. This binary is linked to libvcl* and so all new stuff can be tested.<br />
<br />
e.g. : draw anti-aliased lines works well. <br />
<br />
Everything implemented in aqua vcl code will be included in libvclplug_aqua, and svdem source code will contain a specific part to proceed tests.<br />
<br />
<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;"><br />
<br />
'''The magic is: when all needed features will work with svdem, it will work in the new version of OpenOffice.org !!'''<br />
<br />
</div><br />
<br />
<br />
<br />
[FIXME]: add more complete list of features to implement and test.<br />
<br />
== '''Sort of documentation about VCL around Native Mac OS X port''' ==<br />
<br />
<br />
Do we really need to understand how it works? ;-)<br />
<br />
<br />
vcl content:<br />
<br />
ls -laR | wc -l<br />
1750<br />
<br />
-> Uff 1750 files to analyse :-/<br />
<br />
Our purpose is to describe the vcl organisation. The content of vcl is so important, that at the begining, the content will looks a bit confused. e.g. class names ..etc have nothing to do, only description with words and sense, but this will need some time before we can understand everything.<br />
<br />
How analyse with more efficiency? After some months to anlalyse '''"horizontaly"''', it appears that list all the content of a directory is not the solution. Of course, we learned a lot, but we now have to complete with '''"orthogonal"''' method (compared to the previous one). The first method wasn't obviously not the good/best way to describe vcl.<br />
<br />
[UPDATE] After some investigations, the use of Design patterns seems to be the most efficient approach to describe vcl. Will try to do so asap.<br />
<br />
[FIXME] a different approach (will ask confirmation to Philipp Lohman), could be a description of how it work in runtime. First define what an instance is, a frame, and what exactly is concerned by such "objects".<br />
<br />
With that, we can write a list of different objects all using the same scheme: empty boxes (means pure virtual methods and classes in generic libvvcl), really implemented in the specific part, and finally, the API "encapsulated".<br />
<br />
The most difficult is to see where the API is used. But for all the parts, this is the same.<br />
<br />
Finally, '''what is important is the design of vcl'''. Which '''patterns''' are used? What are the dependencies, how works the stack for the events, how works the scheduler, the timers too is very important, even fundamental for Aqua implementation. Will have a look at gsl mailing list, and other resources. Probably everything is already (randomly) written somewhere.<br />
<br />
=== VCL organisation ===<br />
<br />
Thank's to Philipp Lohmann for this short, but precise description:<br />
<br />
Basically vcl is divided in the system dependent and the system independent part. The interface between these two is mostly the Sal interface (every interface name Sal*: SalInstance, SalFrame, SalGraphics, SalPrinter, etc.).<br />
<br />
SalInstance is a factory that can create all the other abstracted interfaces of the system dependent part. It also provides the main loop SalInstance::Yield()<br />
<br />
SalFrame abstracts any kind of system window.<br />
<br />
SalVirtualDevice abstracts an offscreen window (e.g. a Pixmap on X11)<br />
<br />
SalPrinter and SalInfoPrinter abstract the system print queues where SalInfoPrinter is for querying and SalPrinter for actual printing.<br />
<br />
SalGraphics is an interface produced by either SalFrame, SalVirtualDevice or SalPrinter which is used for actual drawing operations (text, bitmaps, vector graphics)<br />
<br />
SalSound is for sound playing.<br />
<br />
SalBitmap provides memory for bitmap graphics as well as methods converting this memory to a system handle (e.g. a Pixmap on X11).<br />
<br />
SalOpenGL provides OpenGL functionality if available.<br />
<br />
SalTimer is an interface for periodically triggering the event queue (to timer implementation).<br />
<br />
SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific).<br />
<br />
SalSystem has some system specific methods that did not belong anywhere else:-)<br />
<br />
Of all these there interfaces is at least one implementation per system (Windows, X11 or Mac). The Unix implementation also has a plugin concept to allow for integration of different native toolkits (currently gtk and Qt) which became necessary for the implementation of Native Widget Framework (NWF) to display controls like their normal desktop counterparts.<br />
<br />
Basically the independent part (what is beneath vcl/source directory) has generic methods for drawing, window handling and stuff which it brings into a suitable form and then delegates to the system specific implementaion (located beneath vcl/win for Windows and vcl/unx for the X11 platforms).<br />
<br />
[[User:Ericb|Ericb]] 16:12, 1 July 2006 (CEST)<br />
<br />
===Sub-directories description ===<br />
<br />
==== '''Organisation of vcl directories''' ====<br />
<br />
[[Image:aquavcl_organisation_complete_02.jpg]]<br />
<br />
==== '''Directories in vcl. Short description''' ====<br />
<br />
''' aqua ''': The name Aqua means Apple look and feel, and is well known as [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html Aqua Human Interface Guidelines]. This look and feel means Mac OS X. The work was begun by (probably) P. luby, Dan Williams Herbert Duerr (most of fonts stuff) and Ed Peterlin. Currently in ruin, this directory does contain a lot of ideas to investigate. The most important part of needed changes for native version (3.0) will be done inside aqua dir inc: does contain all vcl relative includes [PART1]<br />
<br />
''' prj ''': Does contain build.lst and d.lst build.lst give us dependencies: probably a lot for vcl, build 98th module over ~148. Everything graphical depends in vcl. <br />
<br />
''' qa ''' does contain all quality assurancy stuff<br />
<br />
'''source''': the most important:-) This directory contains common sources for all architectures and OS. Mainly: Windows, Unix: Linux , Mac OS X (X11), Solaris, including generic, kde and gtk plugins, and Aqua (Mac OS X without X11, work currently in progress). <br />
<br />
Depending on the OS and the architecture, binaries are built or not.<br />
<br />
''' test ''': This directory does contain all the needed stuff for tests. As example, in qa/testdocuments, you'll find three documents (one writer, one calc and one impress) for tests purpose. <br />
Other available tests are about memcheck and persistent window state. <br />
<br />
''' unx ''': this directory does contain all unixes stuff. We have to understand what is inside to implement aqua port. For example, a lot of classes/strutures and objects use Xlib calls we have to replace with Carbon/Cocoa call (at least at first time) for Mac OS X native port.<br />
<br />
''' win ''': Doing Mac OS X native port, I first believed this directory was not interesting for us, but I was wrong: OpenOffice.org roots are inside this directory, and a lot of comments and resources are inside. Mainly interesting if Carbon is used.<br />
<br />
'''workben''': Does contain a toy called "svdem". svdem is a binary, used for new implementations. For example, actual aqua development uses svdem intensively, to verify all important properties we need: <br />
<br />
- display a window first (al least ...:)) <br />
<br />
- close cleanly this window<br />
<br />
- display a point<br />
<br />
- trace a line<br />
<br />
- trace an area <br />
<br />
- superpose two areas doing some important graphical operations, (like xor),<br />
<br />
- display a character<br />
<br />
- display a menu. <br />
<br />
- intercept events correctly.<br />
<br />
[FIXME] add more tests<br />
<br />
[[User:Ericb|Ericb]] 13:21, 3 June 2006 (CEST)<br />
<br />
==Naming convention ==<br />
<br />
* Class names start with upper case letters, to improve readability.<br />
<br />
* Implemented Class names are derived from the virtual classes but can of course take arbitrary names.<br />
To increase readability, it's recommended to closely follow the base class name.<br />
<br />
* '''Impl prefix: means Implementation details'''. The concerned class or method or function is not used outside of this module, so no external code (or other libraries) can see it.<br />
<br />
<br />
'''[[ Events types using Carbon API (Mac OS X): ]]''' A lot of events have to be managed in runtime. Here is a short description<br />
<br />
- do not freeze because bad event loops<br />
<br />
- event types implementation: currently, they are defined in vcl/aqua/inc/aquavclevents.hxx<br />
<br />
<br />
Apart: exact sense of hedabu? -> [FIXME] as far as I understood it: it is like "copy" to deliver software into the solver, with extra magic. The header files for example are manipulated so paths need not be exact. "headabu" is supposed to disappear little by little.<br />
<br />
== '''What do we have to build in vcl?'''==<br />
<br />
Two libraries, corresponding ressources (localized) and a toy so called « svdem »<br />
<br />
'''Common part''': <br />
<br />
in grey on right. The result will be a non architecture dependant library, built in all cases: for instance, libvcl680mxi.dylib on Mac Intel.<br />
<br />
'''Specific part " a plugin " ''': <br />
<br />
Light yellow: aqua part will only concern Mac OS X (non X11) the name will probably be libvcl_aqua680mxi.dylib <br />
<br />
As you can see, win means windows part, in blue<br />
<br />
For Unix build (Linux, Solaris or current Mac OS X X11), in purple.<br />
<br />
Result will be:<br />
<br />
libvclplug_PLUGIN680mxi.DLLSUFFIX , where PLUGIN can be iether gen (generic) or gtk (using gtk+) or kde (using qt), and DLLSUFFIX can be either .so (linux) or .dylib (Mac OS X) ...etc (I'm not sure for other cases).<br />
<br />
Example: libvcl680mxi.dylib and libvclplug_aqua680mxi.dylib<br />
<br />
'''In runtime''', libvclplug_aqua will be linked to libvcl680. the first one will contain the real implementation (respecting the API, e.g. Carbon) while the generic libvcl will only contain pure virtual methods ...etc like "empty boxes".<br />
<br />
=== Current Aqua content ===<br />
<br />
A more complete description of aqua (Mac OS X / no X11 specific): [[Image:Vcl_aqua_organisation_02_tree.jpg]]<br />
<br />
<br />
==EXISTING objects to build in aqua==<br />
<br />
===Sal APP "everything application"===<br />
<br />
[FIXME] add all objects descriptions<br />
<br />
==== saldata ====<br />
<br />
* '''Defined in plugin exclusively''' (i.e. for headers)<br />
<br />
Unix: unx/source/app/saldata.cxx (header in unx/inc)<br />
<br />
'''Aqua: aqua/source/app/saldata.cxx (header in win/inc)'''<br />
<br />
Windows: win/source/app/saldata.cxx (header in aqua/inc)<br />
<br />
* Role: saldata contains various kind of data used by the implementation for the concerned platform. '''It is a bunch of global data collections reserved for the platform'''<br />
<br />
It is just completely platform dependent, and nobody except this plugin can see it.<br />
<br />
'''Saldata is something like a "second sal", but providing an abstraction regarding windowing and graphics''', while SAL module provides an abstraction more Operating System oriented) <br />
<br />
e.g. : have a look at XRequest array in vcl/unx/source/app/saldata.cxx => all calls are for Xlib (X11). Ok, useless there, but interesting:-)<br />
<br />
[FIXME]: use Windows implementation could be a good starting point. Nothing is the same, but the current aquavcl cws uses similar objects, and it works very correctly.<br />
<br />
<br />
saldatax.cxx uses classes SalInstance, SalObject, SalFrame, SalVirtualDevice, SalPrinter and fontList.<br />
<br />
Current list of possible objects who can be instantiated/released:<br />
<br />
structure SalData: does contain pointers on all kind of objects from other classes used in saldata.<br />
<br />
inline functions: [FIXME]: complete the description<br />
<br />
- SetSalData:<br />
- GetSalData:<br />
- GetAppSalData:<br />
<br />
==== salinst ====<br />
<br />
=> implemented in vcl/aqua/source/app/salinst.cxx<br />
<br />
Role: <br />
<br />
* get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor),<br />
<br />
* instantiates/releases a lot of other objects using Get() / CreateObject() / DestroyObject() methods.<br />
<br />
<br />
Current list of possible objects who can be instantiated/released:<br />
<br />
* VirtualDevice [FIXME]: exact role?<br />
<br />
*Printer <br />
<br />
- GetDefaultPrinter/ CreatePrinter() / DestroyPrinter - what a name ;-) -<br />
<br />
- InfoPrinter (Get/Create/Delete)<br />
<br />
- PrinterQueue (DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState)<br />
<br />
* System (Create / Delete) [FIXME]: what means system here?<br />
<br />
* Events: <br />
<br />
AquaSalInstance::SetEventCallback()<br />
<br />
AquaSalInstance::SetErrorEvenCallback()<br />
<br />
AquaSalInstance::GetConnectionIdentifier()<br />
<br />
* Menu / MenuItem: <br />
<br />
AquaSalInstance::CreateMenu() / same for DestroyMenu()<br />
<br />
AquaSalInstance::CreateMenuItem / same DestroyMenuItem()<br />
<br />
* Sound: <br />
<br />
AquaSalInstance::CreateSalSound() => object to a pointer of SalSound type<br />
<br />
Note: AquaSalInstance::DestroySalSound is not implemented (?)<br />
<br />
* Timer: CreateTimer() /<br />
<br />
AquaSalInstance:: DestroyTimer() is not yet implemented (?)<br />
<br />
<br />
Class MacImeStatus: inherits of SalI18NImeStatus<br />
<br />
-> only there to see if there is a window to toggle into menubar [FIXME]??<br />
<br />
AquaSalInstance::CreateI18NImeStatus(): instantiates MacImeStatus<br />
<br />
'''For futher informations, see: ''' '''[[Content of salinst.cxx]]'''<br />
<br />
([[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) )<br />
<br />
==== salmain ====<br />
<br />
Role: if possible, runs the standard vcl application code SVMain()<br />
<br />
([[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST))<br />
<br />
==== salsound ====<br />
<br />
==== salsys ====<br />
<br />
==== saltimer ====<br />
<br />
=== Sal GDI (everything Graphical Display Interface) ===<br />
<br />
====salgdinativewidgets====<br />
<br />
[[native controls]]<br />
<br />
==== salatslayout ====<br />
<br />
==== salatsuiutils ====<br />
<br />
==== salfontutils ====<br />
<br />
==== salmathutils ====<br />
<br />
==== sal bmp ====<br />
<br />
==== salvd ====<br />
<br />
==== salframe ====<br />
<br />
==== salpixmaputils====<br />
<br />
==== salprn ====<br />
<br />
====salrectangle====<br />
<br />
==== salvd ====<br />
<br />
=== Sal Window===<br />
<br />
==== salframe ====<br />
<br />
====salobj====<br />
<br />
== TO BE IMPLEMENTED (missing in Aqua)==<br />
<br />
===Audio===<br />
<br />
====audioconvert====<br />
(obsolete?) <br />
<br />
====devaudio====<br />
(obsolete?)<br />
<br />
====native sound====<br />
<br />
====salimpsound====<br />
<br />
====vsound====<br />
<br />
===i18n===<br />
<br />
===keysymnames===<br />
<br />
===saldisp===<br />
<br />
===sm===<br />
<br />
<br />
[FIXME]: is session manager usefull?<br />
<br />
<br />
== What is used for Linux, Windows, Mac OS X ...build ? ==<br />
<br />
'''[[Description of the dependencies]]'''<br />
<br />
'''[[Windows]]'''<br />
<br />
'''[[MacOS X]]'''<br />
<br />
'''[[Linux]]'''<br />
<br />
'''[[Solaris]]'''<br />
<br />
== Content of Aqua ==<br />
<br />
'''[[Click here to see the complete list]]'''<br />
<br />
<br />
'''Content of vcl/inc'''<br />
<br />
Notes: <br />
<br />
1) Where to find includes<br />
<br />
<foo/bar.hxx> means you can find bar.hxx in the foo module. The new style file is foo/inc/foo/bar.hxx, old style is foo/inc/bar.hxx and sometimes the file is somewhere else in the tree or generated. The deliver process copies/generates the file into solver at solver/680/build_type/inc/foo. Good for fixing broken builds. ;-)<br />
<br />
2) <br />
suffix .h (for C calls or first version?) or .hxx (C++) <br />
<br />
'''A) Family of includes''':<br />
<br />
Looking more closely at the list brings to the fore (expression from dictionary ;-) ) that include names are<br />
informatives. Most of the time, the name gives the function/role.<br />
What is interesting is the files with name begining with "sal". sal means System Abstraction Layer + include's function (or explicit name). <br />
<br />
Partial list, for example:<br />
<br />
salatype.hxx<br />
<br />
salbmp.hxx<br />
<br />
salctrlhandle.hxx<br />
<br />
salctype.hxx<br />
<br />
salframe.hxx<br />
<br />
salgdi.hxx<br />
<br />
salgeom.hxx<br />
<br />
sallayout.hxx (main header for fonts services)<br />
...<br />
salmenu<br />
salnativewidgets<br />
...etc<br />
<br />
Other important families are "sv" and "uno" or "win" (window) prefixed. sal family will be analysed apart.<br />
<br />
'''B) Includes of includes'''<br />
<br />
Some includes are more important than other. To prove this, just have a look is sufficient: some are always needed, and some more rarely.<br />
<br />
To verify, a simple test to do in vcl/inc:<br />
<br />
egrep -H "#include" ./* | wc -l gives me 681 lines ! And some of them are the same...<br />
<br />
To know more, the precedent command line can be modified to make appear the numerous call <br />
to the same includes files.<br />
<br />
<br />
egrep -H "#include" ./* | cut -d"#" -f2 | sort > liste.txt<br />
<br />
The content of liste.txt is explicit: dllapi.h, sv.h and some other are very important, while some other includes are only one or two times used. We can see too that vos includes are numerous, even if vos is deprecated**<br />
<br />
**see http://wiki.services.openoffice.org/wiki/Source_code_directories<br />
<br />
<br />
I'm nearly sure that a complete analysis of just this result will give us a lot of information.<br />
<br />
I propose to change the order of analysis starting with dllapi.h and sv.h.<br />
<br />
<br />
<br />
[to be continued]<br />
<br />
'''B1) "sal" includes family'''<br />
<br />
[[salinst.hxx]] This seems to be the main include file<br />
<br />
[[salatype.hxx]]<br />
<br />
[[salctrlhandle.hxx]]<br />
<br />
[[salctype.hxx]]<br />
<br />
[[salframe.hxx]]<br />
<br />
[[salgdi.hxx]]<br />
<br />
[[salgeom.hxx]]<br />
<br />
'''[[ sallayout.hxx ]]''' <-- see Native Fonts implementation<br />
<br />
[[salgtype.hxx]]<br />
<br />
[[vcl/inc/salobj.hxx]]<br />
<br />
<br />
'''B2) Classicals includes'''<br />
<br />
file: abstdlg.hxx [ means abstract dialog ]<br />
<br />
This includes does contain the following classes definitions:<br />
<br />
[FIXME] : choose a precise presentation template for classes <br />
<br />
<br />
VclAbstractDialog,<br />
<br />
VclAbstractTerminateDialog, <br />
<br />
VclAbstractRefreshableDialog,<br />
<br />
VclAbstractDialogFactory, <br />
<br />
<br />
uses <tools/solar.h> , <tools/string.hxx> + <br />
<br />
"dllapi.h"<br />
<br />
Note : dllapi.h is very interesting because when we have to find (for example) a library suffix, SAL_DLLEXTENSSION can replace all suffixes (every OS's and archs). Just including sal/config.h does it ! <br />
<br />
<br />
Classes:<br />
<br />
Window -> what? [FIXME]<br />
ResId -> what?<br />
<br />
Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC<br />
<br />
<br />
file: dllapi.h [ dll for dynamic linked library ]<br />
Uses: <sal/config.h> and >sal/types/h><br />
includes: VCL_DLLPUBLIC macro<br />
<br />
<br />
file: accel.h [ means accelerator ]<br />
<br />
Classes:<br />
<br />
Accelerator <br />
{<br />
}<br />
ImplAccelEntry <br />
{<br />
public members: <br />
<br />
Names<br />
<br />
mnId<br />
maKeyCode<br />
mpAccel<br />
mpAutoAccel<br />
mbEnabled<br />
}<br />
<br />
function / returns / parameters<br />
<br />
ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3<br />
<br />
file: accel.hxx <br />
<br />
Uses: <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx><br />
<br />
<br />
Classes:<br />
<br />
ImplAccelData;<br />
ImplAccelEntry;<br />
<br />
<br />
== Important Links ==<br />
'''[[Progressive implementation]]'''<br />
<br />
'''Native Font server Implementation''' '''[[Fonts starting point and documentation]]'''<br />
<br />
'''Native Sound Implementation''': [[Mac OS X Porting - Native Audio and Video]]<br />
<br />
'''Native Printing Implementation''': [[Mac OS X Porting - Native_Printing]]<br />
<br />
'''Drag and Drop implementation''': [[Mac OS X Porting - Native Drag and drop]]<br />
<br />
This work is part of http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s<br />
<br />
[to be continued:-) ]<br />
<br />
<br />
--[[User:Ericb|Ericb]] 15:00, 22 Jul 2005 (EDT)<br />
<br />
[[Category:Porting]]<br />
[[Category:MacOSX]]<br />
[[Category:Aqua]]</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13094Category:Specification2006-06-29T13:48:27Z<p>Tra: /* Exiting Specification Process */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
<br />
<br />
{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; width: 55%"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 20%" | '''Application''' <br />
| style="background-color: #efefef; width: 30%" | '''Project Lead'''<br />
| style="background-color: #efefef; width: 40%" | '''E-Mail'''<br />
|-<br />
| Writer || '''Andreas Martens''' || mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' || mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' || mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' || mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' || mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' || mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' || mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' || mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' || mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
OpenOffice.org specifications will be written based on the official '''[[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]'''. This template assists you in the process of creating your specification quickly and helps you to avoid common errors and pitfalls.<br><br />
<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews the specification with regards to the three essential rules for OpenOffice.org specifications mentioned above<br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
'''Note:''' the [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template] requires OpenOffice.org 2.0.2 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Exiting Specification Process ==<br />
<br />
If the i-Team can agree on the following items<br />
<br />
* The '''specification reflects the implementation''' in the ''child workspace'' (CWS) and has been set to ''standard'' status<br />
* Also all '''required documents''' (i.e. test case specification) exist, are available, and have ''standard'' status<br />
* [http://tools.openoffice.org/dev_docs/child_workspace_policies.html CWS Policies] have been fulfilled<br />
* [http://qa.openoffice.org/issue_handling/ Issue Handling] rules have been fulfilled<br />
* All additional automated an manual '''tests have been run''' successfully and the '''results have been logged'''<br />
<br />
the CWS can be set to '''Approved by QA''' and the ''Release Engineering'' will integrate the CWS which makes the new implementation available in the MASTER workspace (MWS).<br />
<br />
''Recommendation'': To be sure that the transfer from CWS to MWS was also successfull it makes sense that the i-Team and not only the QA mmember (see: [http://qa.openoffice.org/issue_handling/workflowcharts/taskhandling_workflow_feature_QA.html Issue Handling QA]) compares the implementation with the specification.<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a competitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13077Category:Specification2006-06-29T12:22:30Z<p>Tra: /* Writing a Specification - How to Start? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
OpenOffice.org specifications will be written based on the official '''[[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]'''. This template assists you in the process of creating your specification quickly and helps you to avoid common errors and pitfalls.<br><br />
<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews the specification with regards to the three essential rules for OpenOffice.org specifications mentioned above<br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
'''Note:''' the [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template] requires OpenOffice.org 2.0.2 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a competitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13075Category:Specification2006-06-29T12:17:29Z<p>Tra: /* OpenOffice.org Specifications */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews the specification with regards to the three essential rules for OpenOffice.org specifications mentioned above<br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications will be written based on the official '''[[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]'''. This template assists you in the process of creating your specification quickly and helps you to avoid common errors and pitfalls.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.0.2 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a competitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13069Category:Specification2006-06-29T12:11:42Z<p>Tra: /* What Else do I Have to Follow? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews the specification with regards to the three essential rules for OpenOffice.org specifications mentioned above<br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications will be written based on the official '''[[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]'''. This template assists you in the process of creating your specification quickly and helps you to avoid common errors and pitfalls.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.0.2 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a competitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13066Category:Specification2006-06-29T12:10:42Z<p>Tra: /* Writing a Specification - How to Start? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews the specification with regards to the three essential rules for OpenOffice.org specifications mentioned above<br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications will be written based on the official '''[[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]'''. This template assists you in the process of creating your specification quickly and helps you to avoid common errors and pitfalls.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.0.2 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13064Category:Specification2006-06-29T12:08:55Z<p>Tra: /* Writing a Specification - How to Start? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews the specification with regards to the three essential rules for OpenOffice.org specifications mentioned above<br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications will be written based on the official '''[[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]'''. This template it assists you and helps you to avoid common errors and pitfalls.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.0.2 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13062Category:Specification2006-06-29T12:08:07Z<p>Tra: /* OpenOffice.org Specifications */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews the specification with regards to the three essential rules for OpenOffice.org specifications mentioned above<br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications will be written based on the official '''[[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]'''. This template it assists you and helps you to avoid common errors and pitfalls.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.02 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13056Category:Specification2006-06-29T12:04:16Z<p>Tra: /* Writing a Specification - How to Start? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews the specification with regards to the three essential rules for OpenOffice.org specifications mentioned above<br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications are bases on a template. <br />
'''Use this official [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]''', it assists you writing a specification.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.02 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13055Category:Specification2006-06-29T12:02:13Z<p>Tra: /* Writing a Specification - How to Start? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br />
<br />
<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews the specification with regards to the three essential rules for OpenOffice.org specifications mentioned above<br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications are bases on a template. <br />
'''Use this official [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]''', it assists you writing a specification.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.02 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13051Category:Specification2006-06-29T11:59:11Z<p>Tra: /* Write a Specification, Tell me How Can I Start? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Writing a Specification - How to Start? ==<br />
<br />
The following iterative process has been proven most suiteable when developing specifications for OpenOffice.org:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification according to the three essential rules for OpenOffice.org specifications<br><br />
<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br><br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews specification based on three essential rules<br><br />
<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br><br />
<br />
<br />
* '''Improve'''<br><br />
** Remove defects in your specification<br />
** Remove defects in your implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications are bases on a template. <br />
'''Use this official [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]''', it assists you writing a specification.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.02 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13046Category:Specification2006-06-29T11:44:16Z<p>Tra: /* Before Writing a Specification -- What Else Do I have to Do? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member (required only if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Write a Specification, Tell me How Can I Start? ==<br />
<br />
OpenOffice.org specifications are being developed on the following iterative process:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews specification based on three essential rules<br><br />
<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br><br />
<br />
<br />
* '''Improve'''<br><br />
** Reduction of defects in specification<br />
** Reduction of defects in implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications are bases on a template. <br />
'''Use this official [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]''', it assists you writing a specification.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.02 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13044Category:Specification2006-06-29T11:41:57Z<p>Tra: /* I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the application or area you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member ('''optional, but required''' if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Write a Specification, Tell me How Can I Start? ==<br />
<br />
OpenOffice.org specifications are being developed on the following iterative process:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews specification based on three essential rules<br><br />
<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br><br />
<br />
<br />
* '''Improve'''<br><br />
** Reduction of defects in specification<br />
** Reduction of defects in implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications are bases on a template. <br />
'''Use this official [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]''', it assists you writing a specification.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.02 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13041Category:Specification2006-06-29T11:41:20Z<p>Tra: /* I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the corresponding application you are intending to change (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member ('''optional, but required''' if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Write a Specification, Tell me How Can I Start? ==<br />
<br />
OpenOffice.org specifications are being developed on the following iterative process:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews specification based on three essential rules<br><br />
<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br><br />
<br />
<br />
* '''Improve'''<br><br />
** Reduction of defects in specification<br />
** Reduction of defects in implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications are bases on a template. <br />
'''Use this official [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]''', it assists you writing a specification.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.02 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13040Category:Specification2006-06-29T11:38:22Z<p>Tra: /* OpenOffice.org Specifications */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps you to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the corresponding application (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member ('''optional, but required''' if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Write a Specification, Tell me How Can I Start? ==<br />
<br />
OpenOffice.org specifications are being developed on the following iterative process:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews specification based on three essential rules<br><br />
<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br><br />
<br />
<br />
* '''Improve'''<br><br />
** Reduction of defects in specification<br />
** Reduction of defects in implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications are bases on a template. <br />
'''Use this official [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]''', it assists you writing a specification.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.02 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Category:Specification&diff=13039Category:Specification2006-06-29T11:37:08Z<p>Tra: /* OpenOffice.org Specifications */</p>
<hr />
<div><br />
= OpenOffice.org Specifications =<br />
Welcome to the web based collaboration area of the [http://specs.openoffice.org OpenOffice.org Specification Project].<br />
<br />
<br />
Specifications are an essential part of the OpenOffice.org development process. Changes to OpenOffice.org be it adding new feature or enhancing existing ones will be done based on written specifications. This is absolutely neccessary as there are always multiple persons or groups involved in a change to OpeOffice.org. <br />
Specifically specifications serve as working base for:<br />
<br />
<br />
'''Development (DEV)<br />
DEV implements features based on the technical information covered in specifications.<br />
<br />
'''[[User Experience]] (UX)<br />
UX uses specifications to define the user interface (UI) and its interaction model.<br />
<br />
'''[http://qa.openoffice.org/ Quality Assurance] (QA)<br />
QA derives Test Case Specifications based on specifications. They test implemented features against the specifications.<br />
<br />
'''Documentation (DOCU)<br />
DOCU writes the end-user documentation based on specifications.<br />
<br />
<br><br />
There is a [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott '''Specification Template'''] which greatly simplifies the process of writing specifications and which helps to avoid the common errors usually leading to rework, regressions and delays. <br />
<br><br />
<br />
<br />
<br />
== I Want to Change Something in OpenOffice.org - Do I Have to Write a Specification? ==<br />
<br />
<br />
'''In general the answer is YES. This applies to:'''<br />
<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Features]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Enhancements]<br />
* [http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#issuetype Defects] requiring the following type of changes:<br />
** Behavioral changes of the UI (e.g. changing a dialog from modal to modeless)<br />
** Visual changes of the UI (e.g. changing the icon size, the splash screen, the about box)<br />
** Configuration changes (e.g. changing application defaults such as Spellchecking ON/OFF)<br />
* Features, enhancements, defects which are already covered by an [http://specs.openoffice.org/ existing specification].<br />
<br />
<br />
'''A specification needs NOT to be written if:'''<br />
<br />
You do the following kind of changes:<br />
* Fixing a typo in the UI.<br />
* Rearranging UI controls without changing functionality.<br />
* The changes are not going to be integrated into the OpenOffice.org master.<br />
** The change is an Extension which is distributed separately to OpenOffice.org<br />
<br />
<br />
'''If you are in doubt''', whether you need a specification or not ask the responsible project lead of the corresponding application (see table below).<br />
<br />
{| border="0" cellpadding="3" width="50%" valign="top"<br />
<br />
|- align="left"<br />
| style="background-color: #efefef; width: 30%" | '''Application''' <br />
| style="background-color: #efefef; width: 70%" | '''Project Lead'''<br />
|-<br />
| Writer || '''Andreas Martens''' mailto:Andreas.Martens@sun.com<br />
|-<br />
| Calc|| '''Niklas Nebel''' mailto:Niklas.Nebel@sun.com<br />
|-<br />
| Drawing|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Impress|| '''Christian Lippka''' mailto:Christian.Lippka@sun.com<br />
|-<br />
| Database|| '''Frank Schoenheit''' mailto:Frank.Schoenheit@Sun.com<br />
|-<br />
| Math|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Chart|| '''Kai Ahrens''' mailto:Kai.Ahrens@sun.com<br />
|-<br />
| Framework|| '''Mathias Bauer''' mailto:Mathias.Bauer@sun.com<br />
|-<br />
| Other|| '''Martin Hollmichel''' mailto:Martin.Hollmichel@sun.com<br />
|}<br />
<br><br />
<br><br />
<br><br />
<br />
== Before Writing a Specification -- What Else Do I have to Do? ==<br />
You should be able to answer each of the following questions marked with the letter Q with '''YES''':<br />
<br />
<br />
'''Q1 [Feature/Enhancement]:'''<br><br />
Does an unambiguously clear feature or enhancement request exists?<br />
<br />
<br />
'''Q2 [Concept]:'''<br><br />
For changes requiring modifications in more than one application: Is there a product concept available, which is understandable to the intended readership?<br />
<br />
<br />
'''Q3 [Project-Resources]:'''<br><br />
Do you have a project team?<br />
An OpenOffice.org feature is always being devoloped by an Implementation Team (i-Team). An i-Team consists at least of two distinct persons:<br />
* A developer '''(required)'''<br />
* A QA representative '''(required)'''<br>Ask for a QA representative in the mailto:dev@qa.openoffice.org mailing list.<br />
* An [http://wiki.services.openoffice.org/wiki/OpenOffice.org_User_Experience_Community User Experience] member ('''optional, but required''' if the feature or bug fix affects the user interface or the behavior of the application)<br />
<br />
<br />
'''Q4 [i-Team Agreement]:'''<br><br />
Do all i-Team members agree on Q1 - Q3?<br />
<br />
<br />
'''What happens if I can't answer all questions mentioned above, with Yes?'''<br><br />
The consequence could be that your valuable work won't be integrated into OpenOffice.org.<br />
<br><br />
<br><br />
<br />
== Write a Specification, Tell me How Can I Start? ==<br />
<br />
OpenOffice.org specifications are being developed on the following iterative process:<br />
<br />
* '''Plan'''<br><br />
** I-Team Kickoff<br />
** Detailed feature / sub-feature planning<br />
** First design sessions<br />
<br />
<br />
* '''Do'''<br><br />
** Create prototypes/first implementation<br />
** Write specification<br />
<br />
<br />
* '''Review'''<br><br />
** i-Team reviews specification based on three essential rules<br><br />
<br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Complete]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Clear]<br><br />
R1:[http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications Simple]<br><br />
<br />
<br />
* '''Improve'''<br><br />
** Reduction of defects in specification<br />
** Reduction of defects in implementation<br />
<br />
<br />
More details on the process can be found [http://specs.openoffice.org/collaterals/presentations/Specification-Template-Presentation.odp here]<br />
<br />
<br />
OpenOffice.org specifications are bases on a template. <br />
'''Use this official [[Image:ott.png]] [http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott OpenOffice.org Specification Template]''', it assists you writing a specification.<br><br />
<br />
'''Note:''' the template requires OpenOffice.org 2.02 or newer, make sure that the OpenOffice.org proxy settings are configured correctly. The proxy settings can be changed under Tools/Options/Internet/Proxy.<br />
<br />
== Process Exit here ==<br />
<br />
== What Else do I Have to Follow? ==<br />
* It is strongly recommended to follow the [[The Three Golden Rules for Writing OpenOffice.org Specifications]]<br />
<br />
* If need to do a compatitive analyses please follow the [[Guidelines for Accomplishing a Competitive Analysis on Feature Level]]<br />
<br />
* Specifications for OpenOffice.org 2.0.x can be found on the [http://specs.openoffice.org UI Specifications for OpenOffice.org 2.0.x] site<br />
<br />
* Older Specifications can be found in the section [http://ui.openoffice.org/proposals/index.html UI Specifications for OpenOffice.org 1.1.x]<br />
<br><br />
<br />
== Feedback and comments ==<br />
Feedback or comments are welcome please feel free to submit them to "dev at specs dot openoffice dot org"</div>Trahttps://wiki.openoffice.org/w/index.php?title=Mac_OS_X_Porting_-_Work_Areas/Todo%27s&diff=7832Mac OS X Porting - Work Areas/Todo's2006-04-13T08:29:12Z<p>Tra: </p>
<hr />
<div>This page is intended to serve as a living ToDo's list for the OpenOffice.org Mac OS X port. To keep things simple it contains the ToDo's for both the X11 version and the upcoming Aqua version of OpenOffice.org for Mac OS X. The page is divided into different work areas which either assigned to a person in charge or are unassigned yet. Below each area there is a detailed list of todo's which has to be maintained by the respective people himself.<br />
Persons who are in charge of a certain area are responsible for keeping their respective part of the page up-to-date.<br />
<br />
If you're interested in contributing to the project please coordinate with Eric Bachard [mailto:ericb@openoffice.org]<br />
<br />
== Areas and ToDo's X11 Version ==<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Packaging <br>Packaging related tasks || Oliver Braun [mailto:obr@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Improved packaging for OOo || New || Oliver Braun<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Installation <br>Installation related tasks || Oliver Braun [mailto:obr@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Provide an improved installer for OOo || New || Unassigned<br />
|-<br />
| Error messages during installation when no X11 is installed || New || Unassigned<br />
|-<br />
| Support language pack instalation || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| System Integration <br>System integration related tasks || Oliver Braun [mailto:obr@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Save documents in ~/Documents by default || New || Unassigned<br />
|-<br />
| Use the Mac OS X key chain for document signing || New || Unassigned<br />
|-<br />
| Read proxy settings and user information from the system settings || New || Unassgined<br />
|- <br />
| Mac OS X address book integration || New || Unassigned <br />
|- <br />
| Make use of the Mac OS X spell checker || New || Unassigned<br />
|-<br />
| Improved clipboard support || New || Unassigned<br />
|-<br />
| Support for standard Mac OS X shortcuts according to HI guideline || New || Unassigned<br />
|- <br />
| Integrate native FileOpen/FileSave dialog into OOo || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Printing || Unassigned [mailto: Name [??@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Improved printing support || New || Unassgined<br />
|-<br />
| Use the native print dialog in OOo || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Native sound support || Unassigned [mailto: Name [??@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement native sound support || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Ease of use || Unassigned [mailto: Name [??@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Reduce visible toolbars || New || Unassgined<br />
|-<br />
| Suppress icons in OOo menus by default || New || Unassigned<br />
|-<br />
| Suppress xterm window when launching OOo || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
== Areas and ToDo's Aqua Version ==<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Messaging || Tino Rachui [mailto: [tra@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement messaging infrastructure || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Windowing || Tino Rachui [mailto: [tra@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement salframe.cxx || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Drawing || Stephan Schaefer [mailto: [ssa@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement drawing support || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Key input || Unassigned [mailto: [???@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| ??? || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Native font support || Unassigned [mailto: [???@openoffice.org]<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| ATSUI || New || Unassgined<br />
|}</div>Trahttps://wiki.openoffice.org/w/index.php?title=Mac_OS_X_Porting_-_Work_Areas/Todo%27s&diff=7831Mac OS X Porting - Work Areas/Todo's2006-04-13T08:26:33Z<p>Tra: </p>
<hr />
<div>This page is intended to serve as a living ToDo's list for the OpenOffice.org Mac OS X port. To keep things simple it contains the ToDo's for both the X11 version and the upcoming Aqua version of OpenOffice.org for Mac OS X. The page is divided into different work areas which either assigned to a person in charge or are unassigned yet. Below each area there is a detailed list of todo's which has to be maintained by the respective people himself.<br />
Persons who are in charge of a certain area are responsible for keeping their respective part of the page up-to-date.<br />
<br />
If you're interested in contributing to the project please coordinate with Eric Bachard [mailto:ericb@openoffice.org]<br />
<br />
== Areas and ToDo's X11 Version ==<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Packaging <br>Packaging related tasks || Oliver Braun [mailto:obr@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Improved packaging for OOo || New || Oliver Braun<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Installation <br>Installation related tasks || Oliver Braun [mailto:obr@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Provide an improved installer for OOo || New || Unassigned<br />
|-<br />
| Error messages during installation when no X11 is installed || New || Unassigned<br />
|-<br />
| Support language pack instalation || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| System Integration <br>System integration related tasks || Oliver Braun [mailto:obr@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Save documents in ~/Documents by default || New || Unassigned<br />
|-<br />
| Use the Mac OS X key chain for document signing || New || Unassigned<br />
|-<br />
| Read proxy settings and user information from the system settings || New || Unassgined<br />
|- <br />
| Mac OS X address book integration || New || Unassigned <br />
|- <br />
| Make use of the Mac OS X spell checker || New || Unassigned<br />
|-<br />
| Improved clipboard support || New || Unassigned<br />
|-<br />
| Support for standard Mac OS X shortcuts according to HI guideline || New || Unassigned<br />
|- <br />
| Integrate native FileOpen/FileSave dialog into OOo || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Printing || Unassigned [mailto: Name [??@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Improved printing support || New || Unassgined<br />
|-<br />
| Use the native print dialog in OOo || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Native sound support || Unassigned [mailto: Name [??@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement native sound support || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Ease of use || Unassigned [mailto: Name [??@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Reduce visible toolbars || New || Unassgined<br />
|-<br />
| Suppress icons in OOo menus by default || New || Unassigned<br />
|-<br />
| Suppress xterm window when launching OOo || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
== Areas and ToDo's Aqua Version ==<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Messaging || Tino Rachui [mailto: [tra@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement messaging infrastructure || New || Unassgined<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Windowing || Tino Rachui [mailto: [tra@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement salframe.cxx || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Drawing || Stephan Schaefer [mailto: [ssa@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement drawing support || New || Unassgined<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Key input || Unassigned [mailto: [???@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| ??? || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Native font support || Unassigned [mailto: [???@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| ATSUI || New || Unassgined<br />
|}</div>Trahttps://wiki.openoffice.org/w/index.php?title=Mac_OS_X_Porting_-_Work_Areas/Todo%27s&diff=7830Mac OS X Porting - Work Areas/Todo's2006-04-13T08:23:06Z<p>Tra: </p>
<hr />
<div>This page is intended to serve as a living ToDo's list for the OpenOffice.org Mac OS X port. To keep things simple it contains the ToDo's for both the X11 version and the upcoming Aqua version of OpenOffice.org for Mac OS X. The page is divided into different work areas which either have an assigned person in charge or are unassigned yet. <br />
Persons who are in charge of a certain area are responsible for keeping their respective part of the page up-to-date.<br />
<br />
If you're interested in contributing to the project please coordinate with Eric Bachard [mailto:ericb@openoffice.org]<br />
<br />
== Areas and ToDo's X11 Version ==<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Packaging <br>Packaging related tasks || Oliver Braun [mailto:obr@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Improved packaging for OOo || New || Oliver Braun<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Installation <br>Installation related tasks || Oliver Braun [mailto:obr@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Provide an improved installer for OOo || New || Unassigned<br />
|-<br />
| Error messages during installation when no X11 is installed || New || Unassigned<br />
|-<br />
| Support language pack instalation || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| System Integration <br>System integration related tasks || Oliver Braun [mailto:obr@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Save documents in ~/Documents by default || New || Unassigned<br />
|-<br />
| Use the Mac OS X key chain for document signing || New || Unassigned<br />
|-<br />
| Read proxy settings and user information from the system settings || New || Unassgined<br />
|- <br />
| Mac OS X address book integration || New || Unassigned <br />
|- <br />
| Make use of the Mac OS X spell checker || New || Unassigned<br />
|-<br />
| Improved clipboard support || New || Unassigned<br />
|-<br />
| Support for standard Mac OS X shortcuts according to HI guideline || New || Unassigned<br />
|- <br />
| Integrate native FileOpen/FileSave dialog into OOo || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Printing || Unassigned [mailto: Name [??@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Improved printing support || New || Unassgined<br />
|-<br />
| Use the native print dialog in OOo || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Native sound support || Unassigned [mailto: Name [??@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement native sound support || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Ease of use || Unassigned [mailto: Name [??@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Reduce visible toolbars || New || Unassgined<br />
|-<br />
| Suppress icons in OOo menus by default || New || Unassigned<br />
|-<br />
| Suppress xterm window when launching OOo || New || Unassigned<br />
|}<br />
<br />
<br><br />
<br />
== Areas and ToDo's Aqua Version ==<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Messaging || Tino Rachui [mailto: [tra@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement messaging infrastructure || New || Unassgined<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Windowing || Tino Rachui [mailto: [tra@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement salframe.cxx || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Drawing || Stephan Schaefer [mailto: [ssa@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| Implement drawing support || New || Unassgined<br />
|}<br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Key input || Unassigned [mailto: [???@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| ??? || New || Unassgined<br />
|}<br />
<br />
<br><br />
<br />
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"<br />
|- style="background-color:#99CCFF; font-weight:bold;" <br />
| Native font support || Unassigned [mailto: [???@openoffice.org]<br />
|}<br />
<br><br />
{| style="vertical-align:top; text-align:left; background-color:#efefef;"<br />
|- style="background-color:#d6d6d6;font-weight:bold;" <br />
| Todo || Status || Assigned to<br />
|-<br />
| ATSUI || New || Unassgined<br />
|}</div>Trahttps://wiki.openoffice.org/w/index.php?title=Writer/ToDo/Writer_Refactoring/Writer_Refactoring&diff=4833Writer/ToDo/Writer Refactoring/Writer Refactoring2006-02-10T09:02:20Z<p>Tra: </p>
<hr />
<div>== Caution ==<br />
This page is still under construction hence the content is still very tentative.<br />
<br />
== Problem statement ==<br />
<br />
As Bertrand Meyer [1] describes external software qualities (experienced by the user of the software) like <br />
* Correctness - The ability of software products to perform their exact tasks, as defined by their specification.<br />
* Robustness - The ability of software systems to react appropriately to abnormal conditions.<br />
* Efficiency - The ability of a software system to place as few as possible demands on hardware resources, such as processor time, space occupied etc.<br />
for instances are in direct relation to internal software qualities (experienced only by computer professionals with access to the source code of the <br />
software) like modularity, testability, maintainability.<br />
<br />
The current Writer code base has some serious quality problems with regards to these internal software qualities what consequently leads to external quality problems like crash reports, malfunctions, performance problems, memory leaks. See [2] for some concrete examples otherwise use [http://www.openoffice.org/issues/query.cgi IssueZilla] and search for defects in OOo Writer.<br />
<br />
Some facts and numbers about the writer code and and the code quality (still) in random order<br />
<br />
* Build time - to build the Writer from scratch takes <br />
* Link time dependencies - linking the Writer roughly takes x minutes on a <br />
* Code not testable because of cyclic dependencies <br />
* No unit tests available - Until milestone SRC680m147 there exist not a single unti test for the Writer code<br />
* Code optimized for legacy computer systems e.g. Win16 - Example: BigPtrArray (see sw/source/core/bastyp/bparr.cxx)<br />
* Redundant code<br />
* Big and complex classes with multiple responsibilities - Example: SwDoc <br />
* No clearly designed and documented interfaces and abstractions <br />
* Hand crafted data structures (no STL)<br />
* Unwanted dependencies between UI, Core, Layout<br />
* Fragile code (Undo, Redlining, ...) <br />
* Base classes without virtual destructor<br />
* Single argument constructors are not declared 'explicit'<br />
* Wrong initialization sequence of class members<br />
* Lack of documentation<br />
* Duplicate code - Using CPD [3] with a minimum token count of 100 on SRC680m156 'sw/source' leads to the following results: 11324 duplicate lines of roughly 739620 overall lines of code which nearly amounts to ~1.53% duplicate code.<br />
<br />
== Goal statement ==<br />
<br />
* Prioritize problems <br />
* Break problems into pieces <= 3 man months<br />
<br />
== Steps ==<br />
On cws [http://eis.services.openoffice.org/EIS2/servlet/cws.ShowCWS?Id=3189&Path=SRC680%2Fmacosx20xfixes01 writercorerefactoring] the<br />
following steps are planned:<br />
* Removal of unused files <br />
'''Status:''' done '''Details:''' 19 files which were not build anymore have been removed<br />
* Removal of unnecessary includes of headers<br />
'''Status:'' done '''Details:'' 850 unnecessary includes of header files have been removed in the Writer code base<br />
* Removal of unused/inactive code (how many lines?)<br />
'''Status:''' in progress '''Details:''' There is a lot of code commented out via #if 0 ... #endif, /* */, or no longer used defines e.g. 'JAVASCRIPT'.<br />
'''Reason:''' Inactive code is a unnecessary burden and often confuses potential maintainer of the code. <br />
* Minimize code duplication<br />
'''Status:''' new '''Details:''' Using CPD [3] with a minimum token count of 100 on SRC680m156 'sw/source' leads <br />
to the following results: 11324 duplicate lines of code of roughly 739620 overall lines of code which nearly amounts to <br />
~1.53% duplicate code. '''Reason''' Less duplicate code means less code to maintain. Bugs in duplicated code need <br />
to be fixed in all duplicate places which are hard to detect without the help of tools, so less duplicate code means <br />
fewer redundant sources of bugs.<br />
* Write unit test <br />
'''Status:''' in progress '''Details:''' 1 unit test for BigPtrArray has been introduced<br />
* Make SwDoc interface based, changes clients of SwDoc to just include the header files for these interfaces instead of the whole doc.hxx<br />
'''Goal:''' Reduce unnecessary build time dependencies, first step to break SwDoc into managable and testable pieces<br />
'''Status:''' in progress <br />
'''Details:''' SwDoc (see sw/inc/doc.hxx) is a huge class with more than 130 data members and hundreds of member functions. This class <br />
has mutliple responsibilities this implies that SwDoc has a lot of different clients. Each of these clients usually requires just a small part <br />
of the SwDoc interface. With SRC680m146 434 of 763 source code files directly or indirectly include doc.hxx in which the interface of <br />
SwDoc is declared. This results in undesirable build times when changing doc.hxx. <br />
X Interfaces for SwDoc have been introduced related code has been changed to use these interfaces instead of the whole doc.hxx<br />
<br />
* Replace Writer only OLE objects with Draw OLE objects <br />
* Replace hand-made bulk data types with STL means (e.g. BigPtrArray, SvPtrArr)<br />
<br />
== References ==<br />
[1] Betrand Meyer, [http://www.amazon.com/gp/product/0136291554/qid=1135936830/sr=8-1/ref=pd_bbs_1/002-2294048-8616869?n=507846&s=books&v=glance Object Oriented Software Construction], ISBN: 0-13-629155-4<br />
<br />
[2] Long existing, hard to fix quality problems in OOo Writer (to be extended)<br />
* Cannot select whole document when table is at beginning<br />
* Backspace may take several seconds in documents with many hidden redlines<br />
* Undo-delete still doesn't work in all circumstances (section-to-section)<br />
<br />
[3] Copy Past Detector (CPD) http://pmd.sourceforge.net/cpd.html</div>Trahttps://wiki.openoffice.org/w/index.php?title=Writer/ToDo/Writer_Refactoring/Writer_Refactoring&diff=4830Writer/ToDo/Writer Refactoring/Writer Refactoring2006-02-10T07:58:57Z<p>Tra: </p>
<hr />
<div>== Caution ==<br />
This page is still under construction hence the content is still very tentative.<br />
<br />
== Problem statement ==<br />
<br />
As Bertrand Meyer [1] describes external software qualities (experienced by the user of the software) like <br />
* Correctness - The ability of software products to perform their exact tasks, as defined by their specification.<br />
* Robustness - The ability of software systems to react appropriately to abnormal conditions.<br />
* Efficiency - The ability of a software system to place as few as possible demands on hardware resources, such as processor time, space occupied etc.<br />
for instances are in direct relation to internal software qualities (experienced only by computer professionals with access to the source code of the <br />
software) like modularity, testability, maintainability.<br />
<br />
The current Writer code base has some serious quality problems with regards to these internal software qualities what consequently leads to external quality problems like crash reports, malfunctions, performance problems, memory leaks. See [2] for some concrete examples otherwise use [http://www.openoffice.org/issues/query.cgi IssueZilla] and search for defects in OOo Writer.<br />
<br />
Some facts and numbers about the writer code and and the code quality (still) in random order<br />
<br />
* Build time - to build the Writer from scratch takes <br />
* Link time dependencies - linking the Writer roughly takes x minutes on a <br />
* Code not testable because of cyclic dependencies <br />
* No unit tests available - Until milestone SRC680m147 there exist not a single unti test for the Writer code<br />
* Code optimized for legacy computer systems e.g. Win16 - Example: BigPtrArray (see sw/source/core/bastyp/bparr.cxx)<br />
* Redundant code<br />
* Big and complex classes with multiple responsibilities - Example: SwDoc <br />
* No clearly designed and documented interfaces and abstractions <br />
* Hand crafted data structures (no STL)<br />
* Unwanted dependencies between UI, Core, Layout<br />
* Fragile code (Undo, Redlining, ...) <br />
* Base classes without virtual destructor<br />
* Single argument constructors are not declared 'explicit'<br />
* Wrong initialization sequence of class members<br />
* Lack of documentation<br />
* Duplicate code - Using CPD [3] with a minimum token count of 100 on SRC680m156 'sw/source' leads to the following results: 11324 duplicate lines of roughly 739620 overall lines of code which nearly amounts to ~1.53% duplicate code.<br />
<br />
== Goal statement ==<br />
<br />
* Prioritize problems <br />
* Break problems into pieces <= 3 man months<br />
<br />
== Steps ==<br />
On cws [http://eis.services.openoffice.org/EIS2/servlet/cws.ShowCWS?Id=3189&Path=SRC680%2Fmacosx20xfixes01 writercorerefactoring] the<br />
following steps are planned:<br />
* Removal of unused files <br />
'''Status:''' done '''Details:''' 19 files which were not build anymore have been removed<br />
* Removal of unnecessary includes of headers<br />
'''Status:'' done '''Details:'' 850 unnecessary includes of header files have been removed in the Writer code base<br />
* Removal of unused/inactive code (how many lines?)<br />
'''Status:''' in progress '''Details:''' There is a lot of code commented out via #if 0 ... #endif, /* */, or no longer used defines e.g. 'JAVASCRIPT'.<br />
'''Reason:''' Inactive code is a unnecessary burden and often confuses potential maintainer of the code. <br />
* Minimize code duplication<br />
'''Status:''' new '''Details:''' Using CPD [3] with a minimum token count of 100 on SRC680m156 'sw/source' leads <br />
to the following results: 11324 duplicate lines of code of roughly 739620 overall lines of code which nearly amounts to <br />
~1.53% duplicate code. '''Reason''' Less duplicate code means less code to maintain. Bugs in duplicated code need <br />
to be fixed in all duplicate places which are hard to detect without the help of tools, so less duplicate code means <br />
fewer redundant sources of bugs.<br />
* Write unit test <br />
'''Status:''' in progress '''Details:''' 1 unit test for BigPtrArray has been introduced<br />
* Make SwDoc interface based, changes clients of SwDoc to just include the header files for these interfaces instead of the whole doc.hxx<br />
'''Goal:''' Reduce unnecessary build time dependencies, first step to break SwDoc into managable and testable pieces<br />
'''Status:''' in progress <br />
'''Details:''' SwDoc (see sw/inc/doc.hxx) is a huge class with more than 130 data members and hundreds of member functions. This class <br />
has mutliple responsibilities this implies that SwDoc has a lot of different clients. Each of these clients usually requires just a small part <br />
of the SwDoc interface. With SRC680m146 434 of 763 source code files directly or indirectly include doc.hxx in which the interface of <br />
SwDoc is declared. This results in undesirable build times when changing doc.hxx. <br />
X Interfaces for SwDoc have been introduced related code has been changed to use these interfaces instead of the whole doc.hxx<br />
<br />
== References ==<br />
[1] Betrand Meyer, [http://www.amazon.com/gp/product/0136291554/qid=1135936830/sr=8-1/ref=pd_bbs_1/002-2294048-8616869?n=507846&s=books&v=glance Object Oriented Software Construction], ISBN: 0-13-629155-4<br />
<br />
[2] Long existing, hard to fix quality problems in OOo Writer (to be extended)<br />
* Cannot select whole document when table is at beginning<br />
* Backspace may take several seconds in documents with many hidden redlines<br />
* Undo-delete still doesn't work in all circumstances (section-to-section)<br />
<br />
[3] Copy Past Detector (CPD) http://pmd.sourceforge.net/cpd.html</div>Trahttps://wiki.openoffice.org/w/index.php?title=Writer/ToDo/Writer_Refactoring/Writer_Refactoring&diff=4284Writer/ToDo/Writer Refactoring/Writer Refactoring2006-01-20T06:48:04Z<p>Tra: /* Steps */</p>
<hr />
<div>== Caution ==<br />
This page is still under construction hence the content is still very tentative.<br />
<br />
== Problem statement ==<br />
<br />
As Bertrand Meyer [1] describes external software qualities (experienced by the user of the software) like <br />
* Correctness - The ability of software products to perform their exact tasks, as defined by their specification.<br />
* Robustness - The ability of software systems to react appropriately to abnormal conditions.<br />
* Efficiency - The ability of a software system to place as few as possible demands on hardware resources, such as processor time, space occupied etc.<br />
for instances are in direct relation to internal software qualities (experienced only by computer professionals with access to the source code of the <br />
software) like modularity, testability, maintainability.<br />
<br />
The current Writer code base has some serious quality problems with regards to these internal software qualities what consequently leads to external quality problems like crash reports, malfunctions, performance problems, memory leaks. See [2] for some concrete examples otherwise use [http://www.openoffice.org/issues/query.cgi IssueZilla] and search for defects in OOo Writer.<br />
<br />
Some facts and numbers about the writer code and and the code quality (still) in random order<br />
<br />
* Build time - to build the Writer from scratch takes <br />
* Link time dependencies - linking the Writer roughly takes x minutes on a <br />
* Code not testable because of cyclic dependencies <br />
* No unit tests available - Until milestone SRC680m147 there exist not a single unti test for the Writer code<br />
* Code optimized for legacy computer systems e.g. Win16 - Example: BigPtrArray (see sw/source/core/bastyp/bparr.cxx)<br />
* Redundant code<br />
* Big and complex classes with multiple responsibilities - Example: SwDoc <br />
* No clearly designed and documented interfaces and abstractions <br />
* Hand crafted data structures (no STL)<br />
* Unwanted dependencies between UI, Core, Layout<br />
* Fragile code (Undo, Redlining, ...) <br />
* Base classes without virtual destructor<br />
* Single argument constructors are not declared 'explicit'<br />
* Wrong initialization sequence of class members<br />
* Lack of documentation<br />
<br />
== Goal statement ==<br />
<br />
* Prioritize problems <br />
* Break problems into pieces <= 3 man months<br />
<br />
== Steps ==<br />
On cws [http://eis.services.openoffice.org/EIS2/servlet/cws.ShowCWS?Id=3189&Path=SRC680%2Fmacosx20xfixes01 writercorerefactoring] the<br />
following steps are planned:<br />
* Removal of unused files <br />
'''Status:''' done '''Details:''' 19 files which were not build anymore have been removed<br />
* Removal of unnecessary includes of headers<br />
'''Status:'' done '''Details:'' 850 unnecessary includes of header files have been removed in the Writer code base<br />
* Removal of unused/inactive code (how many lines?)<br />
'''Status:''' in progress '''Details:''' There is a lot of code commented out via #if 0 ... #endif, /* */, or no longer used defines e.g. 'JAVASCRIPT'.<br />
'''Reason:''' Inactive code is a unnecessary burden and often confuses potential maintainer of the code. <br />
* Write unit test <br />
'''Status:''' in progress '''Details:''' 1 unit test for BigPtrArray has been introduced<br />
* Make SwDoc interface based, changes clients of SwDoc to just include the header files for these interfaces instead of the whole doc.hxx<br />
'''Goal:''' Reduce unnecessary build time dependencies, first step to break SwDoc into managable and testable pieces<br />
'''Status:''' in progress <br />
'''Details:''' SwDoc (see sw/inc/doc.hxx) is a huge class with more than 130 data members and hundreds of member functions. This class <br />
has mutliple responsibilities this implies that SwDoc has a lot of different clients. Each of these clients usually requires just a small part <br />
of the SwDoc interface. With SRC680m146 434 of 763 source code files directly or indirectly include doc.hxx in which the interface of <br />
SwDoc is declared. This results in undesirable build times when changing doc.hxx. <br />
X Interfaces for SwDoc have been introduced related code has been changed to use these interfaces instead of the whole doc.hxx<br />
<br />
== References ==<br />
[1] Betrand Meyer, [http://www.amazon.com/gp/product/0136291554/qid=1135936830/sr=8-1/ref=pd_bbs_1/002-2294048-8616869?n=507846&s=books&v=glance Object Oriented Software Construction], ISBN: 0-13-629155-4<br />
<br />
[2] Long existing, hard to fix quality problems in OOo Writer (to be extended)<br />
* Cannot select whole document when table is at beginning<br />
* Backspace may take several seconds in documents with many hidden redlines<br />
* Undo-delete still doesn't work in all circumstances (section-to-section)</div>Trahttps://wiki.openoffice.org/w/index.php?title=Writer/ToDo/Writer_Refactoring/Writer_Refactoring&diff=3545Writer/ToDo/Writer Refactoring/Writer Refactoring2005-12-30T13:28:24Z<p>Tra: </p>
<hr />
<div>== Caution ==<br />
This page is still under construction hence the content is still very tentative.<br />
<br />
== Problem statement ==<br />
<br />
As Bertrand Meyer [1] describes external software qualities (experienced by the user of the software) like <br />
* Correctness - The ability of software products to perform their exact tasks, as defined by their specification.<br />
* Robustness - The ability of software systems to react appropriately to abnormal conditions.<br />
* Efficiency - The ability of a software system to place as few as possible demands on hardware resources, such as processor time, space occupied etc.<br />
for instances are in direct relation to internal software qualities (experienced only by computer professionals with access to the source code of the <br />
software) like modularity, testability, maintainability.<br />
<br />
The current Writer code base has some serious quality problems with regards to these internal software qualities what consequently leads to external quality problems like crash reports, malfunctions, performance problems, memory leaks. See [2] for some concrete examples otherwise use [http://www.openoffice.org/issues/query.cgi IssueZilla] and search for defects in OOo Writer.<br />
<br />
Some facts and numbers about the writer code and and the code quality (still) in random order<br />
<br />
* Build time - to build the Writer from scratch takes <br />
* Link time dependencies - linking the Writer roughly takes x minutes on a <br />
* Code not testable because of cyclic dependencies <br />
* No unit tests available - Until milestone SRC680m147 there exist not a single unti test for the Writer code<br />
* Code optimized for legacy computer systems e.g. Win16 - Example: BigPtrArray (see sw/source/core/bastyp/bparr.cxx)<br />
* Redundant code<br />
* Big and complex classes with multiple responsibilities - Example: SwDoc <br />
* No clearly designed and documented interfaces and abstractions <br />
* Hand crafted data structures (no STL)<br />
* Unwanted dependencies between UI, Core, Layout<br />
* Fragile code (Undo, Redlining, ...) <br />
* Base classes without virtual destructor<br />
* Single argument constructors are not declared 'explicit'<br />
* Wrong initialization sequence of class members<br />
* Lack of documentation<br />
<br />
== Goal statement ==<br />
<br />
* Prioritize problems <br />
* Break problems into pieces <= 3 man months<br />
<br />
== Steps ==<br />
On cws [http://eis.services.openoffice.org/EIS2/servlet/cws.ShowCWS?Id=3189&Path=SRC680%2Fmacosx20xfixes01 writercorerefactoring] the<br />
following steps are planned:<br />
* Removal of unused files <br />
'''Status:''' done '''Details:''' 19 files which were not build anymore have been removed<br />
* Removal of unnecessary includes of headers<br />
'''Status:''' done '''Details:'' 850 unnecessary includes of header files have been removed in the Writer code base<br />
* Removal of unused code (how many lines?)<br />
'''Status:'' in progress '''Details:'' <br />
* Write unit test <br />
'''Status:'' in progress '''Details:'' 1 unit test for BigPtrArray has been introduced<br />
* Make SwDoc interface based, changes clients of SwDoc to just include the header files for these interfaces instead of the whole doc.hxx<br />
'''Goal:'' Reduce unnecessary build time dependencies, first step to break SwDoc into managable and testable pieces<br />
'''Status:'' in progress <br />
'''Details:'' SwDoc (see sw/inc/doc.hxx) is a huge class with more than 130 data members and hundreds of member functions. This class <br />
has mutliple responsibilities this implies that SwDoc has a lot of different clients. Each of these clients usually requires just a small part <br />
of the SwDoc interface. With SRC680m146 434 of 763 source code files directly or indirectly include doc.hxx in which the interface of <br />
SwDoc is declared. This results in undesirable build times when changing doc.hxx. <br />
X Interfaces for SwDoc have been introduced related code has been changed to use these interfaces instead of the whole doc.hxx <br />
<br />
== References ==<br />
[1] Betrand Meyer, [http://www.amazon.com/gp/product/0136291554/qid=1135936830/sr=8-1/ref=pd_bbs_1/002-2294048-8616869?n=507846&s=books&v=glance Object Oriented Software Construction], ISBN: 0-13-629155-4<br />
<br />
[2] Long existing, hard to fix quality problems in OOo Writer (to be extended)<br />
* Cannot select whole document when table is at beginning<br />
* Backspace may take several seconds in documents with many hidden redlines<br />
* Undo-delete still doesn't work in all circumstances (section-to-section)</div>Trahttps://wiki.openoffice.org/w/index.php?title=Writer/ToDo/Writer_Refactoring/Writer_Refactoring&diff=3544Writer/ToDo/Writer Refactoring/Writer Refactoring2005-12-30T13:24:50Z<p>Tra: </p>
<hr />
<div>== Caution ==<br />
This page is still under construction hence the content is still very tentative.<br />
<br />
== Problem statement ==<br />
<br />
As Bertrand Meyer [1] describes external software qualities (experienced by the user of the software) like <br />
* Correctness - The ability of software products to perform their exact tasks, as defined by their specification.<br />
* Robustness - The ability of software systems to react appropriately to abnormal conditions.<br />
* Efficiency - The ability of a software system to place as few as possible demands on hardware resources, such as processor time, space occupied etc.<br />
for instances are in direct relation to internal software qualities (experienced only by computer professionals with access to the source code of the <br />
software) like modularity, testability, maintainability.<br />
<br />
The current Writer code base has some serious quality problems with regards to these internal software qualities what consequently leads to external quality problems like crash reports, malfunctions, performance problems, memory leaks. See [2] for some concrete examples otherwise use [http://www.openoffice.org/issues/query.cgi IssueZilla] and search for defects in OOo Writer.<br />
<br />
Some facts and numbers about the writer code and and the code quality (still) in random order<br />
<br />
* Build time - to build the Writer from scratch takes <br />
* Link time dependencies - linking the Writer roughly takes x minutes on a <br />
* Code not testable because of cyclic dependencies <br />
* No unit tests available - Until milestone SRC680m147 there exist not a single unti test for the Writer code<br />
* Code optimized for legacy computer systems e.g. Win16 - Example: BigPtrArray (see sw/source/core/bastyp/bparr.cxx)<br />
* Redundant code<br />
* Big and complex classes with multiple responsibilities - Example: SwDoc <br />
* No clearly designed and documented interfaces and abstractions <br />
* Hand crafted data structures (no STL)<br />
* Unwanted dependencies between UI, Core, Layout<br />
* Fragile code (Undo, Redlining, ...) <br />
* Base classes without virtual destructor<br />
* Single argument constructors are not declared 'explicit'<br />
* Wrong initialization sequence of class members<br />
* Lack of documentation<br />
<br />
== Goal statement ==<br />
<br />
* Prioritize problems <br />
* Break problems into pieces <= 3 man months<br />
<br />
== Steps ==<br />
On cws [http://eis.services.openoffice.org/EIS2/servlet/cws.ShowCWS?Id=3189&Path=SRC680%2Fmacosx20xfixes01 writercorerefactoring] the<br />
following steps are planned:<br />
* Removal of unused files <br />
'''Status:''' done '''Details:''' 19 files which were not build anymore have been removed<br />
* Removal of unnecessary includes of headers<br />
'''Status:''' done '''Details:'' 850 unnecessary includes of header files have been removed in the Writer code base<br />
* Removal of unused code (how many lines?)<br />
'''Status:'' in progress '''Details:'' <br />
* Write unit test <br />
'''Status:'' in progress '''Details:'' 1 unit test for BigPtrArray has been introduced<br />
* Make SwDoc interface based, changes clients of SwDoc to just include the header files for these interfaces instead of the whole doc.hxx<br />
in order to reduce unnecessary build time dependencies<br />
'''Status:'' in progress <br />
'''Details:'' SwDoc (see sw/inc/doc.hxx) is a huge class with more than 130 data members and hundreds of member functions. This class <br />
has mutliple responsibilities this implies that SwDoc has a lot of different clients. Each of these clients usually requires just a small part <br />
of the SwDoc interface. With SRC680m146 434 of 763 source code files directly or indirectly include doc.hxx in which the interface of <br />
SwDoc is declared. This results in undesirable build times when changing doc.hxx. <br />
X Interfaces for SwDoc have been introduced related code has been changed to use these interfaces instead of the whole doc.hxx <br />
<br />
== References ==<br />
[1] Betrand Meyer, [http://www.amazon.com/gp/product/0136291554/qid=1135936830/sr=8-1/ref=pd_bbs_1/002-2294048-8616869?n=507846&s=books&v=glance Object Oriented Software Construction], ISBN: 0-13-629155-4<br />
<br />
[2] Long existing, hard to fix quality problems in OOo Writer (to be extended)<br />
* Cannot select whole document when table is at beginning<br />
* Backspace may take several seconds in documents with many hidden redlines<br />
* Undo-delete still doesn't work in all circumstances (section-to-section)</div>Trahttps://wiki.openoffice.org/w/index.php?title=Writer/ToDo/Writer_Refactoring/Writer_Refactoring&diff=3543Writer/ToDo/Writer Refactoring/Writer Refactoring2005-12-30T10:49:12Z<p>Tra: </p>
<hr />
<div>== Problem statement ==<br />
<br />
As Bertrand Meyer [1] describes external software qualities (experienced by the user of the software) like <br />
* Correctness - The ability of software products to perform their exact tasks, as defined by their specification.<br />
* Robustness - The ability of software systems to react appropriately to abnormal conditions.<br />
* Efficiency - The ability of a software system to place as few as possible demands on hardware resources, such as processor time, space occupied etc.<br />
for instances are in direct relation to internal software qualities (experienced only by computer professionals with access to the source code of the <br />
software) like modularity, testability, maintainability.<br />
<br />
The current Writer code base has some serious quality problems with regards to these internal software qualities what consequently leads to external quality problems like crash reports, malfunctions, performance problems, memory leaks. See [2] for some concrete examples otherwise use [http://www.openoffice.org/issues/query.cgi IssueZilla] and search for defects in OOo Writer.<br />
<br />
Some facts and numbers about the writer code and and the code quality (still) in random order<br />
<br />
* Build time - to build the Writer from scratch takes <br />
* Link time dependencies - linking the Writer roughly takes x minutes on a <br />
* Code not testable because of cyclic dependencies <br />
* No unit tests available - Until milestone SRC680m147 there exist not a single unti test for the Writer code<br />
* Code optimized for legacy computer systems e.g. Win16 - Example: BigPtrArray (see sw/source/core/bastyp/bparr.cxx)<br />
* Redundant code<br />
* Big and complex classes with multiple responsibilities - Example: SwDoc <br />
* No clearly designed and documented interfaces and abstractions <br />
* Hand crafted data structures (no STL)<br />
* Unwanted dependencies between UI, Core, Layout<br />
* Fragile code (Undo, Redlining, ...) <br />
* Base classes without virtual destructor<br />
* Single argument constructors are not declared 'explicit'<br />
* Wrong initialization sequence of class members<br />
* Lack of documentation<br />
<br />
== Goal statement ==<br />
<br />
* Prioritize problems <br />
* Break problems into pieces <= 3 man months<br />
<br />
== Steps ==<br />
On cws [http://eis.services.openoffice.org/EIS2/servlet/cws.ShowCWS?Id=3189&Path=SRC680%2Fmacosx20xfixes01 writercorerefactoring] the<br />
following steps are planned:<br />
* Removal of unused files <br />
'''Status:''' done '''Details:''' 19 files which were not build anymore have been removed<br />
* Removal of unnecessary includes of headers<br />
'''Status:''' done '''Details:'' 850 unnecessary includes of header files have been removed in the Writer code base<br />
* Removal of unused code (how many lines?)<br />
'''Status:'' in progress '''Details:'' <br />
* Write unit test <br />
'''Status:'' in progress '''Details:'' 1 unit test for BigPtrArray has been introduced<br />
* Make SwDoc interface based, changes clients of SwDoc to use these interfaces <br />
'''Status:'' in progress '''Details:'' X Interfaces for SwDoc have been introduced related code has been changed to use these interfaces instead of the whole doc.hxx <br />
<br />
== Rough ideas ==<br />
<br />
== References ==<br />
[1] Betrand Meyer, [http://www.amazon.com/gp/product/0136291554/qid=1135936830/sr=8-1/ref=pd_bbs_1/002-2294048-8616869?n=507846&s=books&v=glance Object Oriented Software Construction], ISBN: 0-13-629155-4<br />
<br />
[2] Long existing, hard to fix quality problems in OOo Writer (to be extended)<br />
* Cannot select whole document when table is at beginning<br />
* Backspace may take several seconds in documents with many hidden redlines<br />
* Undo-delete still doesn't work in all circumstances (section-to-section)</div>Trahttps://wiki.openoffice.org/w/index.php?title=LD_LIBRARY_PATH&diff=3320LD LIBRARY PATH2005-12-22T14:12:55Z<p>Tra: Arguments against the use of LD_LIBRARY_PATH</p>
<hr />
<div>Some arguments, links, etc. why the use of LD_LIBRARY_PATH is bad in general.<br><br />
[http://daemons.net/~matty/articles/linkers.badldlibrary.html LD_LIBRARY_PATH is not the solution]<br><br />
[http://www.visi.com/~barr/ldpath.html Why LD_LIBRARY_PATH is bad]</div>Tra