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
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Inkscape-board mailing list
Inkscape-board@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-board
