SpecSpec
|
Size: 2975
Comment: create it
|
Size: 3018
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| * '''Launchpad Entry''': UbuntuSpec:foo * '''Created''': [[Date(2005-10-25T15:45:54Z)]] * '''Contributors''': * '''Packages affected''': * '''See also''': SpecTemplate |
|
| Line 2: | Line 7: |
| = How to Write an Ubuntu Specification = | == Summary == |
| Line 4: | Line 9: |
| This is an example Ubuntu specification, with comments on how to write a good Ubuntu specification. The better your spec, the better the chances that your ideas will be implemented in Ubuntu, and accepted by the distro team. |
Gnome is completely lacking a font installer. If you double click a ttf font, you can preview it, but no indication is given to the user for how to get the font into applications. KDE already does this out of the the box. On the wiki there are some instructions explaining to create a .fonts folder and stick your fonts in there, but this has issues: |
| Line 8: | Line 11: |
| == Status == People: MarkShuttleworthLead, MattZimmermanSecond[[BR]] Created: 19/04/05[[BR]] Author: MarkShuttleworth[[BR]] Contributors: [[BR]] Status: BrainDump, UduBof, UbuntuSpecification[[BR]] Priority: LowPriority[[BR]] Branch: n/a[[BR]] Bug #: n/a == Introduction == This specification decribes the way we would like Ubuntu specifications to be written. It takes the form of a specification itself. You can see the SpecificationTemplate, which it is recommended you use for your own specifications in this system. |
1) Shouldn't be necessary in the first place 2) Isn't system wide, and to do so system wide requires using the terminal 3) Doesn't work for joe blow user because when he tries to create the .fonts folder Nautilus tells him it already exists, he looks for it but doesn't see it, and gives up using Ubuntu out of frustration (he doesn't see it because it's hidden, nautilus doesn't explain this either). |
| Line 28: | Line 17: |
| As we develop new ideas for features in Ubuntu it's important to have a clear idea of the exact status of each idea. Putting this content in the wiki gives our community a chance to participate in the discussion and design of a feature, and increases the chance that community members will feel confident enough to start work on the implementation of the feature. A good specification allows community members who were not physically present at meetings discussing a topic to participate in the implementation of the spec. |
As we develop new ideas for features in Ubuntu, it's important to be able to communicate them clearly. This serves the purpose of making it clear what the feature is about, and allowing people to evolve an implementation strategy for it. |
| Line 37: | Line 19: |
| == Specification Structure == | Publishing this content gives our community a chance to participate in the discussion and design of a feature, and increases the chance that community members will feel confident enough to start work on the implementation of the feature. |
| Line 39: | Line 21: |
| The spec is broken into a number of sections and sub-sections. We describe each of these in turn: |
A good specification also allows community members who were not physically present at meetings discussing a topic to participate in the implementation of the spec. |
| Line 42: | Line 23: |
| 1. '''The title'''. A short heading for the spec, no more than 12 words. | Bottom line: the better your spec, the better the chances that your ideas will be clearly understood by the review team. |
| Line 44: | Line 25: |
| 1. '''The status metadata'''. This section contains some well-defined metadata for the spec. It's important to put in as may flags and tags as possible that accurately describe the state and scope of the specification. These flags are used to generate reporting pages automatically. Please use as many flags as make sense for this spec from the following list: HighPriority, LowPriority, MediumPriority, UduBof, BrainDump, DraftSpecification, ApprovedSpecification, ImplementedSpecification, DistroSpecification, LaunchpadSpecification, CommunitySpecification. |
== Use Cases == |
| Line 54: | Line 27: |
| 1. '''Introduction'''. A brief introduction to the topic or spec. This should not attempt to tell '''why''' the spec is being defined, just '''what''' is being specified. |
* Joe the graphics designer wants to install a font just for himself, so that he can make cool-looking documents in AbiWord |
| Line 58: | Line 29: |
| 1. '''Rationale''': a summary of '''why''' this spec is being defined. 1. '''Scope and Use Cases'''. The use cases are not always required, but in many cases they bring much better clarity to the scope and scale of the specification than could be obtained by talking in abstract terms. |
* Alice the SysOp finds a nice font, and wants all the people on her system to be able to use it. |
| Line 64: | Line 31: |
| 1. '''Implementation Plan'''. This section is usually broken down into subsections, such as the packages being affected, data and system migration where necessary, user interface requirements and pictures (photographs of drawings on paper work ell). |
== Scope == This specification covers a simple way to add fonts to Ubuntu using a simple GUI. == Design == The following considerations should be kept in mind: * The user should not have to open a terminal * PolicyKit should be used to add system fonts * Separation should be kept between user and system fonts. === Summary === The summary should not attempt to say '''why''' the spec is being defined, just '''what''' is being specified. === Rationale === Currently the only way to add a font as a user is to create (if not already in existence ) a ~/.fonts folder and to put your fonts in there. This is not immediately obvious, and such a directory is hidden by default. Adding a system font is very difficult without terminal usage. ==== Use Cases ==== === Implementation Plan === Ideally, this will appear in System>Preferences>Appereance under "Fonts", where a "add new" button would exist to add a font simply. (Mockup to be created shortly) ---- CategorySpec |
Launchpad Entry: foo
Created: Date(2005-10-25T15:45:54Z)
Contributors:
Packages affected:
See also: SpecTemplate
Summary
- Gnome is completely lacking a font installer. If you double click a ttf font, you can preview it, but no indication is given to the user for how to get the font into applications. KDE already does this out of the the box. On the wiki there are some instructions explaining to create a .fonts folder and stick your fonts in there, but this has issues:
1) Shouldn't be necessary in the first place 2) Isn't system wide, and to do so system wide requires using the terminal 3) Doesn't work for joe blow user because when he tries to create the .fonts folder Nautilus tells him it already exists, he looks for it but doesn't see it, and gives up using Ubuntu out of frustration (he doesn't see it because it's hidden, nautilus doesn't explain this either).
Rationale
As we develop new ideas for features in Ubuntu, it's important to be able to communicate them clearly. This serves the purpose of making it clear what the feature is about, and allowing people to evolve an implementation strategy for it.
Publishing this content gives our community a chance to participate in the discussion and design of a feature, and increases the chance that community members will feel confident enough to start work on the implementation of the feature.
A good specification also allows community members who were not physically present at meetings discussing a topic to participate in the implementation of the spec.
Bottom line: the better your spec, the better the chances that your ideas will be clearly understood by the review team.
Use Cases
Joe the graphics designer wants to install a font just for himself, so that he can make cool-looking documents in AbiWord
Alice the SysOp finds a nice font, and wants all the people on her system to be able to use it.
Scope
This specification covers a simple way to add fonts to Ubuntu using a simple GUI.
Design
The following considerations should be kept in mind:
* The user should not have to open a terminal * PolicyKit should be used to add system fonts * Separation should be kept between user and system fonts.
Summary
The summary should not attempt to say why the spec is being defined, just what is being specified.
Rationale
Currently the only way to add a font as a user is to create (if not already in existence ) a ~/.fonts folder and to put your fonts in there. This is not immediately obvious, and such a directory is hidden by default.
Adding a system font is very difficult without terminal usage.
Use Cases
Implementation Plan
Ideally, this will appear in System>Preferences>Appereance under "Fonts", where a "add new" button would exist to add a font simply. (Mockup to be created shortly)
SpecSpec (last edited 2010-05-30 17:13:07 by dsl-185-83-10)