Roadmapping for 0.39-0.50
Hi all,
This weekend we're going to try to flesh out the roadmap for the next dozen releases or so. Not to cast anything in stone but simply to identify what we'll need to implement when, and to outline priorities.
In the old roadmap we had identified 0.39 for implementing Extensions, however that presupposed we'd be further along in terms of identifying an internal API to hook them to, and having some conceptual/design documentation.
Instead, we're thinking of pushing that forward, and let the focus of 0.39 be the incorporation of the AST and ECMA work, that has been going on in two branches. As well, we'll finally pull in GtkMM and start work on converting code to use that, including a layers dialog. We also need to determine the internal API for hooking extensions, etc. to, since that's a major dependency for Extensions.
So in general 0.39 would be a much more development focused release, and we'll encourage deep work on internals that we've discouraged previously due to stability concerns. We will advertise 0.39 as more of an experimental release and encourage users needing a high level of stability to stick with 0.38.
How does this approach sound?
Bryce
P.S. If you're interested in giving feedback to the roadmap including longer term goals, join us on Jabber as we continue revising it. We'll update the high level roadmap on the main website as we go this weekend, and flesh out the detailed roadmap in wiki later on.
On Sat, 2004-04-03 at 15:07 -0800, Bryce Harrington wrote:
So in general 0.39 would be a much more development focused release, and we'll encourage deep work on internals that we've discouraged previously due to stability concerns. We will advertise 0.39 as more of an experimental release and encourage users needing a high level of stability to stick with 0.38.
How does this approach sound?
That sounds like an excellent plan. Perhaps you should designate alternate releases as feature focused (odd) and bugfix (even) to create a nice balance between forward development and a well tested, stable application.
I could see Inkscape having a lot of success with such a model.
On Sun, 4 Apr 2004, Charles Goodwin wrote:
On Sat, 2004-04-03 at 15:07 -0800, Bryce Harrington wrote:
So in general 0.39 would be a much more development focused release, and we'll encourage deep work on internals that we've discouraged previously due to stability concerns. We will advertise 0.39 as more of an experimental release and encourage users needing a high level of stability to stick with 0.38.
How does this approach sound?
That sounds like an excellent plan. Perhaps you should designate alternate releases as feature focused (odd) and bugfix (even) to create a nice balance between forward development and a well tested, stable application.
I could see Inkscape having a lot of success with such a model.
Yup, not a bad idea. I figured having them every few releases may be sufficient, since the team seems to do pretty well at getting bug reports closed already. Guess we can keep this alternating approach in mind, and see how it goes, and adjust as we find ncessary.
Btw, in discussing the roadmap with bulia and mental, we decided to make the Pango adoption be the focus of the next release. Bulia pointed out that we have a number of still-open bugs and several RFE's that are dependent on having that.
bryce
Bryce Harrington wrote:
Btw, in discussing the roadmap with bulia and mental, we decided to make the Pango adoption be the focus of the next release. Bulia pointed out that we have a number of still-open bugs and several RFE's that are dependent on having that.
Yaay! ;-) After looking at several of the last bugs in libnrtype, and the unicode problems, it seems clear that Pango is the way to go. We are already using Pango indirectly, so why not use it in our code? It seems pointless to write more code for libnrtype when it is apparent that the code is redundant and will be discarded later.
Bob
On Sun, 4 Apr 2004, Bob Jamison wrote:
Btw, in discussing the roadmap with bulia and mental, we decided to make the Pango adoption be the focus of the next release. Bulia pointed out that we have a number of still-open bugs and several RFE's that are dependent on having that.
Yaay! ;-) After looking at several of the last bugs in libnrtype, and the unicode problems, it seems clear that Pango is the way to go. We are already using Pango indirectly, so why not use it in our code? It seems pointless to write more code for libnrtype when it is apparent that the code is redundant and will be discarded later.
Right, it sounds like the time is ripe for this improvement. :-)
Are we using Pango through some of the other libraries?
What sort of approach do we want to take for doing this changeover? Is the Pango API parallel enough to libnrtype that we could just do function exchanges, or will it require more significant wrapperizing or rewriting? Is this the sort of work we could divide up amongst us all, or is it more of a 1-2 person tiger team type change?
Bryce
On Sun, 2004-04-04 at 15:42, Bryce Harrington wrote:
Are we using Pango through some of the other libraries?
Well, Gtk obviously. I don't think it's really even relevent to any of the other libraries we use.
What sort of approach do we want to take for doing this changeover?
Is the Pango API parallel enough to libnrtype that we could just do function exchanges, or will it require more significant wrapperizing or rewriting? Is this the sort of work we could divide up amongst us all, or is it more of a 1-2 person tiger team type change?
Not entirely sure yet. I know it's different enough from libnrtype to do simple replacements, and we will need to provide some equivalent of the current libnrtype <-> libnr interface ourselves (notably, the mechanism for getting glyph outlines into the renderer).
Probably the best sequence to attack this in might be:
- write a new libnrtype backend using pango
- remove all the other libnrtype backends
- remove the extra level of abstraction for the pluggable libnrtype backends
- peel away the libnrtype facade from Pango where we can and start using the Pango APIs directly
- refactor the remaining libnrtype bits into a few adaptor objects/functions to get glyph outlines and text attributes to and from Pango
- start emplying Pango to perform text layout for e.g. SPText and friends
If someone is feeling particularly motivated, we could probably short-circuit a couple of these steps.
-mental
Hi,
I like to see some type of simplification in inkscape.
In icons.svg in the style attribute of rect elements there is ie font-size. This makes no sense and can deleted. Also unused gradients etc.
Adib. PS: I have no glue what this Path-cleanup is doing
participants (5)
-
Adib Taraben -
Bob Jamison -
Bryce Harrington -
Charles Goodwin -
MenTaLguY