Google Summer of Code Reunion 2014
by Josh Andler
Hey All,
This email concerns current and past participants of Summer of Code who
have worked with Inkscape. If you have been or currently are a mentor,
admin, or student with the Inkscape project for GSoC (and did not "fail")
you are eligible to attend this year's Google Summer of Code Reunion at
Google HQ in Mountain View, CA, USA this October.
If you have successfully participated with us for GSoC in any of those
three roles and you have an interest in attending, please read more here:
https://sites.google.com/site/gsocmentorsummitstudentreunion/home
As usual, Google will be providing funding (up to $1100 per person) for two
people from our project to attend. They will also be having a lottery for
other people to be able to attend (no guarantees that anyone who enters
from our project will be selected), however, they will not be providing any
funding for those attendees. The board is currently working on figuring out
to what extent we would be interested in funding this ourselves, if any.
If you are interested in attending, please respond right away as we need to
solidify plans much earlier this year than in the past. If you have any
questions, please don't hesitate to ask.
Cheers,
Josh
8 years, 11 months
VALS Semester of Code
by Alexandre Prokoudine
Hi,
Someone on #krita brought this to my attention yetserday:
http://osswatch.jiscinvolve.org/wp/2014/05/23/vals-semester-of-code-foss-...
"The VALS Semester of Code is an upcoming project that will work with
universities andFOSS communities to give students real-world
experience working in software projects. Unlike Google Summer of
Code, Semester of Code students will be participating for academic
credit as part of their degree courses, and we hope that after
completion of their project will go on to be effective contributors to
the FOSS community.
The VALS initiative is a partership of European universities and SMEs
who have been working for several months to plan the pilot of Semester
of Code, which will run during the next academic year. We have now
reached the stage where we are signing up FOSS projects who are
willing to provide mentored projects of students. We have already seen
interest from smaller, single-company projects to larger software
foundations, and would like to see more.
If you are part of a FOSS project, large or small, that would be
willing to provide one or more mentored projects, we’d love to talk to
you about joining Semester of Code. In return, you’ll get an
enthusiastic student providing a valuable contribution to your
project. The VALS team will be on hand throughout the project to
answer any questions and help unblock communication issues between
mentors, students and academic supervisors."
Opinions?
Alex
8 years, 11 months
Notes from LGM Inkscape Meeting
by unknown＠example.com
Hi all,
We had a very good meeting this morning. Nine (9!) Inkscapers were present (partially thanks to the Inkscape development fund). Here is a list of those present:
Martin Owen/doctormo (barcode extension, Python, C++)
Joakim Verona (artwork, Inkscape with emacs, d-bus, interest in embedded Inkscape)
Krzysztof Kosiński (Clipboard, Cairo renderer, boolean path operations)
Gémy Cédric/pygmee (extensions, Python, documentations)
Sirko Kemter (LGM Host, Inkscape trainer)
Elisa de Castro Guerra (documentation, translations)
Ryan Lerch (Redhat user)
the Adib (translation, Cairo, interest in PDF output)
Myself
Here are some notes I took from the session merged with some notes from Elisa (thanks!). We covered a lot of stuff. Let me appoligize to those present if I get some details mixed up.
1. Community Development
The Inkscape community appears to be quite weak compared to other projects. We discussed a variety of reasons for this and possible solutions.
* The community appears to be quite fragmented due to multiple websites for code, bug-tracker, mailing lists, forums, etc. We should consolidate where possible. There could be better linkage between sites. The Inkscape website still needs to be expanded. For example, there is no page for translators (already fixed since our meeting, thanks Elisa and Martin!). Also, we need make sure that feature requests in the Inkscape forums get aggregated to the developers email list. Martin will try to find someone to volunteer to act as liaison.
* There appears to be a lack of direction. The Inkscape board is, by design, limited to controlling Inkscape's donations and trademark. Having some kind of steering committee might be beneficial.
* There is a lack of visible momentum in the project, exasperated by the long time between current releases. (We desperately NEED to get 0.91 out - as well as 0.48.5. People need to see progress.) More news articles are needed (with rapid translation).
* Paid developer: Synfig hired a developer who is now paid month-to-month by crowd-funding. This has actually stimulated additional developer contributions. People see progress being made and are more likely to make their own code contributions. There are weekly updates by the developer where people see the progress being made. (This is in contrast to the prevailing view inside the Inkscape community where paid development might threaten further contributions by non-paid developers.) Blender uses a subscription system. Many communities use a voting process to select the direction of paid development. We do need to be careful, as Scribus had a bad experience with a paid developer disappearing without delivering promised code.
http://libregraphicsworld.org/blog/entry/crowdfunding-for-sustainability-...
* Extensions is a place where people can easily make contributions. We need a web page with links to contributed extensions (or host them ourselves). (BTW, Blender had 8 part-time developers but still has a very active community of people contributing extensions.)
2. Paid developer
We discussed what we would want a developer to do if one were hired. Ideas were:
* Animation (high profile, improve sense of forward momentum).
* PDF Export (same as above).
* Plug-in structure (make it easier to contribute).
* Code clean-up and documentation (make it easier to contribute).
* Release (get timely releases out).
* Testing
3. Website Translations
Several problems were identified with translating the website. Translated news is being shown twice, once in the translated language and once in English. Martin and Adib will look into fixing this (some python coding). Also, translators are not notified of news updates. Martin will assemble a list of translators and set up a "cron" job to monitor changes to the website and then notify translators when changes are detected.
4. Technical discussions:
* 0.91 release: We need to get this out, even if there are a few remaining bugs. Adib will help with Windows builds. There is great demand for a GTK3 OSX build. It seems that the only hold-up is redoing the rulers as GTK3 dropped the ruler widget. Gimp has the same problem.
* Testing: We need better automated testing in both rendering and in unit-tests. cxxtests is awkward to use (and nobody seems to look at it, their are many tests failing now).
* Patch reviews: We need to be quicker in reviewing patches or we risk losing new devolopers. We might need to revisit our very easy access to code check-in rights. A person writing Python extensions might not be as proficient with C++.
* PDF Export: We discussed various strategies for improving our export to PDF, especially focusing on CMYK. Krzysztof has some ideas for achieving this. After our meeting, we had further discussions with people from Scribus on this topic. This topic is also coupled into possibly supporting other rendering methods (e.g. GEGL).
There are a couple possible solutions. One is to extend Cairo to handle color profiles. This might not be so hard as we could write out RGB but include a color profile to hand RGB to CMYK conversion. One problem is that Cairo doesn't support the color-depth we would like. The second is to write our own PDF exporter. While Scibus's PDF export code is tightly coupled to the rest of Scribus, it can serve as a good model of what we need to do.
The current "recommended" way of getting good PDF CMYK files is to pass Inkscape's SVG through Scribus. This is problematic as SVG support in Scribus is behind Inkscape's. Filters are not supported in Scribus. Adib will look in to possible filter support in Scribus.
* Export: Our export mechanisms needs to be unified, probably with a "visitor's" model.
* Filters: Needs to be reworked to follow the model of other objects. (There are hacks needed now to get the rendering done correctly.)
* Multipage SVG: We discussed ways to use groups (layers) to handle multipage SVGs. The layer dialog might be modified with some added Inkscape name-space attributes to have groups of layers of which selecting one will hide the others in the group. (This would make editing JessyInk presentations much easier!) Martin has volunteered to put a plan together.
* Remove need for "id" attributes. (Krzysztofv has an idea on this.)
* Excessive signaling. Why does dragging a gradient handle cause closed dialogs to call style handling code?
* Redhat/Gnome/Fedora had a series of requests already forwarded to the mailing list.
* BZR migration: BZR is no longer under development.
8 years, 11 months
GSOC status report - Better support for SVG paints
by Tomasz Boczkowski
Hi!
GSOC 2014 program started a week ago. I would like to describe, what I have
done since then in my project.
The branch, I'm doing my development in is lp:inkscape/~penginsbacon/
inkscape/svg-paints-support.
Week 1:
1) The main objective was to refactor c-style UI widgets to c++ and gtkmm.
I managed to fully port SPColorSlider. It is now called
Inkscape::UI::Widget::ColorSlider. The class works with both GTK2 and GTK3
libraries. Sadly, this partial task took me longer than I expected.
Understanding gobject object model was quite difficult.
2) The topic of refactoring ColorSelector and related classes is being
actively discussed with Jon A. Cruz at the mailing list. He mentioned
possible problems with Gtkmm widgets that I was not aware of before.
3) Simple changes to SPPattern class are in progress. They consist in:
a) moving c-like functions to class methods
b) getting rid of GSList
c) replacing gchar* by Glib::ustring
d) converting *_set fields from guint to bool
e) converting giuint fields to enums.
Tomasz
8 years, 11 months
FYI - revision 13417 eliminates routine duplication of gradients in list
by mathog
For a while now we have been working on eliminating duplications of
swatches and gradients when these are imported or copy/pasted from
window to window. While working on bug #1318657 I put in a change that
also eliminates duplications of most gradients shown in fill/stroke when
they are cut and paste in the same window. These changes were committed
to trunk at revision 13417. I think the new behavior make sense but it
is certainly going to look strange if you are accustomed to a huge
number of gradients piling up in that list. For a better description
see
https://bugs.launchpad.net/inkscape/+bug/1318657/comments/12
and also post 14 there.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
8 years, 11 months
Re: [Inkscape-devel] Some memory leaks in replaceArgs function ( main.cpp )
by Krzysztof Kosiński
There is no point in rewriting this code; it should be ported to
GOption, which recently added functions required to properly support
Windows.
Regards, Krzysztof
From: Johan Engelen
Sent: 2014-06-10 19:51
To: inkscape-devel(a)lists.sourceforge.net; neandertalspeople@...400...
Subject: Re: [Inkscape-devel] Some memory leaks in replaceArgs function
( main.cpp )
Actually, all your changes are incorrect. Your patch is deleting memory
which the code still holds pointers to. The code is quite bad indeed,
but should be fixed differently. At the end of the method, all memory
that the parser array has pointers to should be freed. The problem is
that these pointers point to memory blocks that have been allocated
differently, or point to memory locations within an allocated array.
It's a mess. The whole function should be rewritten.
Please create a bug report for it.
regards,
Johan
On 10-6-2014 19:35, Johan Engelen wrote:
> On 10-6-2014 17:29, Guiu Rocafort wrote:
>> Hi !
>>
>> Making a simple check to see if all the new operators are freed using
>> delete i found that there are some memory leaks in main.cpp, in the
>> function replaceArgs ( which only affects the windows version of
>> inkscape ).
>>
>> I've added the missing delete operators and those memory leaks should
>> be fixed.
>> I attach the .patch file, if you want me to fill a bug report and then
>> submit the patch instead please tell me.
> Did you test your patch? While you are right that there are some
> memleaks, there are less than you think there are :) (e.g. your
> "delete[] block;" on line 1984 is wrong)
>
> I'll rework and commit it.
>
> regards,
> Johan
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
8 years, 11 months
Somebody please test patch for bug 1318657
by mathog
If one of you gets a chance, please test the patch for
bug 1318657 (in post 10)
https://bugs.launchpad.net/inkscape/+bug/1318657
and see if you can break it. I didn't want to commit that change
until another developer had a look at it. (Because this section of code
is easy to break, and we keep running into cases that are not handled,
like the
present bug, which is the result of an incoming document containing
two copies of a gradient/swatch with different names.)
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
8 years, 11 months
Last call for 0.48.5
by Josh Andler
Hey all,
We have some license compliance issues which have been fixed in the 0.48.x
branch which is overdue for should release anyway. I don't recall seeing
objections the last time releasing 0.48.5 was brought up (but could have
missed something).
If there are no issues left unmentioned or unresolved prior to next Sunday,
May 25, we will move forward with releasing it. Given that our focus is
really on moving forward with 0.91, please speak up as this is likely to be
the last release in the 0.48 series.
Cheers,
Josh
8 years, 11 months
