Difference between revisions of "Announcement to Sodipodi"
m (link fix) |
|||
| (6 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
=== Announcement to Sodipodi Project of the Inkscape Project === | === Announcement to Sodipodi Project of the Inkscape Project === | ||
Wed, 5 Nov 2003 23:16:25 -0800 (PST) | |||
Subject: [Sodipodi-list] Announcing new project | |||
Nathan, mental, Ted and myself have decided to embark on our own direction | Nathan, mental, Ted and myself have decided to embark on our own direction | ||
| Line 12: | Line 16: | ||
Our goal is the creation of a fully SVG-compliant 2D graphics editor: | Our goal is the creation of a fully SVG-compliant 2D graphics editor: | ||
* Full SVG (plus XML, CSS2) compliance | |||
* Core written in C++ | |||
* Gtk-based user interface following the standards set out in the GNOME HIG | |||
* Emphasis on a small core plus modular extensions for features (a la Mozilla Firebird) | |||
* Open, community-oriented development processes that welcomes experimentation | |||
* Baseline is the Sodipodi-Hydra codebase | |||
* Removal of dead code | |||
We are aiming specifically for a general purpose XML | We are aiming specifically for a general purpose XML/SVG graphics editor, and as a consequence will emphasize features that tend to fall outside the Sodipodi target userbase. We would like to welcome anyone who'd like to | ||
do some experimentation to participate with us. Subscribe at | do some experimentation to participate with us. Subscribe at | ||
http://lists.sourceforge.net/lists/listinfo/inkscape-devel | http://lists.sourceforge.net/lists/listinfo/inkscape-devel | ||
We also intend to seek use of third-party libraries in preference to custom code (where reasonable); specifically, we are exploring Cairo (formerly Xr), libcroco, Pango, the core Gtk widgets, but also other existing and widespread facilities. The extension architecture is partly intended to minimize library dependencies in the core. | We also intend to seek use of third-party libraries in preference to custom code (where reasonable); specifically, we are exploring Cairo (formerly Xr), libcroco, Pango, the core Gtk widgets, but also other existing and widespread facilities. The extension architecture is partly intended to minimize library dependencies in the core. | ||
-- [[User:BryceHarrington|Bryce]] | |||
[[Category:Wiki Attic]] | |||
Latest revision as of 18:27, 17 November 2018
Announcement to Sodipodi Project of the Inkscape Project
Wed, 5 Nov 2003 23:16:25 -0800 (PST)
Subject: [Sodipodi-list] Announcing new project
Nathan, mental, Ted and myself have decided to embark on our own direction with the Sodipodi codebase. We have attempted to do this as part of the Sodipodi project, but we believe we need to try out a new project structure to have the freedom to be able to explore some approaches radically different from Sodipodi.
We have recently reworked the Sodipodi codebase to build with a C++ compiler and renamed it 'Inkscape'. We have also set up a project on Sourceforge and established a new website at http://www.inkscape.org.
Our goal is the creation of a fully SVG-compliant 2D graphics editor:
- Full SVG (plus XML, CSS2) compliance
- Core written in C++
- Gtk-based user interface following the standards set out in the GNOME HIG
- Emphasis on a small core plus modular extensions for features (a la Mozilla Firebird)
- Open, community-oriented development processes that welcomes experimentation
- Baseline is the Sodipodi-Hydra codebase
- Removal of dead code
We are aiming specifically for a general purpose XML/SVG graphics editor, and as a consequence will emphasize features that tend to fall outside the Sodipodi target userbase. We would like to welcome anyone who'd like to do some experimentation to participate with us. Subscribe at http://lists.sourceforge.net/lists/listinfo/inkscape-devel
We also intend to seek use of third-party libraries in preference to custom code (where reasonable); specifically, we are exploring Cairo (formerly Xr), libcroco, Pango, the core Gtk widgets, but also other existing and widespread facilities. The extension architecture is partly intended to minimize library dependencies in the core.
-- Bryce