Quantcast

Minutes of the Inkscape team IRC meeting, 25/02

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Minutes of the Inkscape team IRC meeting, 25/02

Krzysztof Kosiński
This is a rough record of the main subjects of discussion. Copied with
slight changes from http://piratepad.net/inkscape
The agenda turned out to be too long for a single meeting, and several
points were left untouched.

1. Inkscape 0.48.3.1 packaging
Need people (2 or 3) to create an installer on win32 and OSX.
    How about UweSch ?
    Tweenk is making a package on a VM (for win). Quite slow need 1h.
Discussion about tool (btool, MSYS..) "we have 2 ways forward, fix our
autotools scripts to work with MSYS (should be doable since they have
recently updated their Perl port) or move to a different build system"
    Resume: ScislaC and Tweenk will see about building  the Win32
packages. They need to figure out if the project could invest in
virtualized OS copies so they can knock specific builds out (like
OSX).
    If Michael W. doesn't have time/resources, su_v could provide
32bit Intel (Leopard) and 64bit Intel (Lion) packages (no Universal
packages)
    Unit testing:
    we need to get our unit tests cleaned up and all passing. Then a
continuous build system can take care of that whole
one-os-breaks-the-others issue.
    Breaking OS often stems from #ifdef or package issues, so is not
solved by unit testing.
    Unit testing + continuous build systems on multiple OS's catches
#ifdef breakage, etc.

2. Inkscape 0.49
2.1 - Remaining refactoring goals
Cairo and render caching : still some bugs to fix
Gradient rendering: kuribas offers to chip in to help fix the banding.
Idea is to add it as an option in exporting. Needs to be implemented
in Cairo.
    disadvantages: speed, filesize, consistency between outputs,
shouldn't be done partially (only on gradients f.e.)
    proposal (Tweenk): implement a GEGL renderer as an alternative to
the Cairo renderer for use in export (running 16 bit engine under the
hood)

2.1.1 - Handling of svg:switch not as a kind of group, but as a
"transparent" element that is effectively replaced by the best choice
in the SP tree
    (ScislaC): we need to be a solid test ground for SVG2 ... switch
helps make it happen.
    (Tweenk):  there is an asymmetry between the "base path" and "path
parameters": the "base path" is stored in the svg:path that represents
the result, while all other path parameters are stored in, IIRC,
inkscape:liveeffect
    (Tweenk): the primary use case for switch in Inkscape would be to
put 2 elements in it where the first is an inkscape-specific XML
element while the second is an SVG fallback
    browser implementation is not at par yet - this isn't usable on
the web for now.
    Some playing/testing with Firefox:
    (Tweenk): looks like FF works as I intended only if I put the SVG
element first, and the Inkscape-specific XML second
    link: https://developer.mozilla.org/en/SVG/Element/switch
    (Tweenk): if I put Inkscape XML in a foreignObject it works properly
    (MenTaLguY): foreignObject is probably the technically correct thing anyway
    (Tweenk): there would be two elements in the <switch>, a
<inkscape:something> inside <foreignObject> that would contain
flowframe info and a <g> that would contain SVG 1.1 text (...and
ScislaC nods)

2.1.2 - SVG 1.1 fallback for flowtext (probably depends on the above)
    see above - 2.1.1

2.1.3 - UI & Document coordinates
    the problem in short: where do you set the (0,0) point and what direction?
    Currently: (Inkscape standard): bottom left corner = (0,0) and up
is positive versus (SVG standard): top left corner = (0,0) and down is
positive.
    Current fix breaks a few things stored in desktop coordinates:
grids, 3D boxes and guides, rows and columns, view coordinates, ...
    (JonCruz): "I'd say we need to have a wiki page to start listing
what can be affected, and the use cases we care about"
    Changes shouldn't alter the SVG, but be purely interface
(preferrably the document origin should be configurable on a per
document basis)
    3D box: fix or remove and then rewrite, if a new one is written,
keep in mind http://dev.w3.org/csswg/css3-transforms/
    wiki page to summarize broken areas, general use cases, etc. for
guiding the coord fixes:
http://wiki.inkscape.org/wiki/index.php/UI_and_Document_coordinates
2.1.4 - Markers matching stroke by default (user preference vs current
default behavior)
See SVG2 below.
2.1.5 - Better architecture for Live Path Eeffects (LPE; similar to
SVG 2.0 vector effects)
2.1.6 - User visible version numbering
    suggestion of switching to a different scheme after 0.49 is released
    1.0 conditions: fix most annoying problems: flowtext, coords,
marker coloring
    discussion background:
http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31650 and
take 2: http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/36540
2.2 - Status
    0.49 should contain the coords fix (but it should be forward
compatible with origin being placed in another spot)
    Flowtext fallback is too complicated and there's already too much
new stuff in 0.49
    Lack of mipmapping / downscaling in Cairo: critical bug
        WIKI page is needed to work on this:
http://wiki.inkscape.org/wiki/index.php/Mipmapping
2.3 - Release Plan
3. - GSOC 2012
3.1 - Focus / Goals
    Pick coders who have better chances of sticking around and
delivering instead of those who promise super-features
    Focus on completing all selected projects successfully with
benefit to the project rather than on adding flashy new stuff
    Preference on structural type projects over features
3.3 - Mentoring
    Available mentors: Johan E. (dutch, english, german), Tweenk
(english, polish) (can also be a student), Tav (English, W. African
Pidgin), JonCruz (english)
    Available mentors should be pinged: JazzyNico, pygmee, steren. i
guess we can manage some "french team"
    Not available: Jasper vd G.
    Available as admin: simmie
3.4 - Getting new students
    JonCruz mentioned something about African students - African
countries have a lot of open source activity, but most of it is in
French-speaking countries (language barrier) -> JazzyNico, pygmee and
(Steren -if available) can speak French : need to find available
african too but we can have help from some organization for this :)
    For GSoC purposes, 2Geom should be part of Inkscape - interesting
potential projects with concrete deliverables; relates to point 8 (to
be discussed in the future)
    Strictly enforce two patches rule
    Have IRC meetings with mentors/students as part of our process
(Johan: I meant this as part of our *selection* process)

4. SVG2 and CSS3 - not discussed thoroughly due to lack of time.
4.1 - Implementation strategies
4.1 .1 - Fallback support for older versions of the spec and inkscape
4.1 .2 - Specific features (markers inheriting properties for example)
4.2 - Low hanging fruit
  Marker color matching stroke.
  Named colors.
  CSS3 2d transforms (duplicates current attributes)
4.3 - Most important features to our userbase
4.3.1 - Helping Tavmjong with the Mesh branch
4.4 - Initial Vector Effects support (non-destructive boolean ops might be
a good target)
    - relates to Live Path Effects
4.5 Pushing for wanted features in SVG2.
    - multipage support

8. What we need in upstream libraries (including 2geom)
2geom:
    coders
    better documentation of mathematics behind path operations
    more unit tests
    port existing tests to Google Test Framework?
    provide skeleton test example
libgdl:
    named icons in dock item labels
    there's a bug in the code that we currently have imported into our
codebase that makes 64 bit architectures crash:
https://bugs.launchpad.net/inkscape/+bug/933058/comments/10
cairo:
    bitmap downscaling / mipmapping
libcroco:
    ability to work with other XML tree implementations
    this is provided by our in-tree cr-sel-eng (selection engine) modification

11. Platform specific issues (and responsibilities)
    - see point 1
12. Regular IRC Meetings (monthly is ideal, quarterly would be as a
good minimum)
    general consensus on 1 or 2 times per month.
    suggestion to let timeslots alternate (f.e. 8AM and 8PM UTC) to
accomodate ppl worldwide

Various points:
* do we need more focus on 'polish' instead of new features? see Bruce
Perens' keynote on Linux.conf.au
http://www.youtube.com/watch?v=Uoum-DHO7S8
* long-winded discussion about preferences system
* this discussion then spilled over into the embed/link debate

Participants (list might be incomplete):
jazzynico, Johan Engelen (johan_e), Jon A. Cruz, Jurgentje, Kris,
Nikita Kitaev, parasidasaeidae,  pygmee, ScislaC, simarilius, su_v,
Tavmjong, Tweenk, yemanjalisa

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Minutes of the Inkscape team IRC meeting, 25/02

Josh Andler
2012/2/25 Krzysztof Kosiński <[hidden email]>:
> This is a rough record of the main subjects of discussion. Copied with
> slight changes from http://piratepad.net/inkscape
> The agenda turned out to be too long for a single meeting, and several
> points were left untouched.

Thanks for taking care of this!

Sorry I had to bail mid-meeting but I am glad to see how much got
touched on. I like the more frequent meetings suggestions and think it
would be great to keeping meeting short sweet and fair to everyone so
they didn't have to commit as much time as this one required.

I will follow up in the next few days regarding calendaring the next
meeting (and also to start discussion on a few issues that weren't
touched on).

Cheers,
Josh

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Loading...