On Sun, Nov 02, 2014 at 11:58:34PM +0100, Tavmjong Bah wrote:
On Fri, 2014-10-31 at 01:00 -0700, Bryce Harrington wrote:
Thanks all, here's our final votes:
Box Blur rm g*list svg2 fl.txt
bryce +1 +1 tav +1 +1 tgould +1 +1 josh +2 johan +1 +1 joncruz +1 +1 mental(?)
I know I said ">50% of the vote", but I just realized that literally interpreted that'd mean only items getting 7 or more votes would pass muster, which is ridiculous. I didn't think that through too well. What I really meant was items that half of us were favorable towards... so items with 6 voters +3 or better. All three voted projects meet that test, and if no one objects I'd like to declare all three as passing our vote and make them officially pre-approved.
Before we make any public announcements, I'd like to make sure we have the three projects defined, with deliverables explained.
I can take care of fleshing out Box Blur (help welcomed tho). Tav and Johan would you two be willing to tackle defining the GList refactoring project? That would leave the SVG2 features for Josh, Ted, and Jon to elaborate on, if you're up for it?
Yes, I can tackle the GList refactoring project... but not for about a week (I've already got a list of tasks for when I return to France in a couple of days).
Here's the project description we have so far:
------------------------------------------------------------------------ These GLib data structures are poorly designed (they are simple lists without sentinels, leading to blunders such as O(N) performance when appending to a doubly-linked list) and not type-safe. Replace all uses with standard C++ containers or suitable Boost containers. ------------------------------------------------------------------------ View: http://staging.inkscape.org/en/project/remove-all-use-of-glist-and-gslist/ Edit: http://staging.inkscape.org/en/admin/projects/project/2/
I think this is straightforward enough; most experienced C++ programmers should know what you're talking about. But perhaps provide a few examples of particular GLib structures to be changed, and the corresponding STL or Boost ones to use.
Also, I know certain STL containers are disliked, so if there's any we're trying to avoid for Inkscape, this should list them.
Thinking of questions a programmer might ask... do you want the patches to be like one patch that changes all the hash maps, and a second that does double-linked lists, and so on. Or do you want patches organized by subsystem, or per-file?
Should only higher order data structures be changed, or also strings/quarks/gvariants?
See my other email for suggestions regarding customizing the deliverables and the need for a banner and logo. Probably no need to get super fancy with the graphics for this one, but we'll need something better than my mysterious green circle. ;-)
Bryce