Strange crash on startup?
by Jasper van de Gronde
After a break of a few months I tried to get inkscape to compile again
over the weekend but ran into a strange issue. Inkscape compiles just
fine, but if I try to run it it crashes immediately (and yes, I've done
several clean builds by now). Unfortunately I'm not at my laptop right
now, so I can't give you the exact error, but I'm wondering whether
anyone has had a similar issue and/or knows something else I could try.
I'm using TDM's GCC 4.5.1 (sjlj, and I have also tried the 64 bit
version, but that fails to build inkscape at some point) on Vista, and
there are no other mingw installations present (anymore). The source is
unmodified, I have updated devlibs and I have done a clean build. I have
also downloaded a "nightly" build for a slightly older revision (the
latest I could find), and although that worked fine, updating my source
to the same revision and doing a clean build of that did not. I've even
tried moving my inkscape.exe into the folder of the downloaded nightly
build, without success.
Interestingly just running inkscape(.com) seems to do nothing... (No
crash, no output, no Inkscape, nothing.)
The crash is pretty much immediately after startup and seems to come
from loading(?) lcms, but according to gdb's backtrace it crashes from
some function having to do something with (stack?) frames (sorry, don't
have the details with me at the moment). I googled it, and it appears
this function is somehow associated with relocation of dll's.
So, sound familiar to anyone? Any ideas for what else to try?
BTW, I think it could be related to this bug:
https://bugs.launchpad.net/inkscape/+bug/453931
12 years, 2 months
^-, I miss you
by Johan Engelen
Hi all,
I miss our IRC/Jabber bridging bot. Hope whoever managed it, can get it
back online in our chat!
Many thanks,
Johan
12 years, 2 months
Re: [Inkscape-devel] plans on 0.49
by Valerie
I also think the "sprint" idea is a really good one, while donators vote for "top wanted features" to be coded during the sprint. It could also be helpful to do the following for each feature:
1. Note what needs to be done (what needs to be implemented). This is to give donators an idea of what they're "paying" for (they deserve to know when the feature isn't That simple to code), but also so that potential developers who don't know how to contribute could see the top listed features easily and know where to start.
2. Estimate roughly how much work it'd take (at least try to note if it'd take a long time or just a couple of hours). If you organise a sprint, this means donators will better understand why Feature X hasn't been completed yet (because it takes "1000 man-hours" to finish all the dependencies).
3. Also describe clearly what the feature does and how the user benefits. Inkscape features can be pretty technical (Cairo), but users will understand if you say "You can use it to accomplish [cool effects]/[serious office work]/[compatibility with other software]/etc., or "It will speed up parts of Inkscape by 20%." Or even "doing this will allow us to then implement Feature Y that all of you want."
4. Progress should be documented clearly, like on a blog or such.
5. As an alternative to sprints, some or all developers could agree to all commit to working on the top feature (without meeting up), either periodically or when total donations reach a certain milestone.
I'll also mention as a side note that although bounties never worked for Gimp and Inkscape, paid development did work for Krita last year. What they did was get a developer (Lukáš Tvrdý) to develop for Krita full-time during several months thanks to donations. Krita has a blog, so every week work on Krita development, including Lukáš', was documented (when money is involved, transparency is important). You can read the log on krita.org (start from the last page). Lukáš coded and improved several brushes engines, improved speed, fixed lots of bugs, etc. I think anybody who observed the progress will agree that Huge progress was made thanks to that, it was very exciting to read week after week.
Of course, it's not an arrangement for everyone, it just happened that a capable developer could be made to work full time on Krita thanks to donations, so it can't necessarily be reproduced for Inkscape. It's just an example of donations that can work, in case you decide not to go for a sprint.
12 years, 2 months
Changing path libgomp in build.xml
by Jasper van de Gronde
I noticed that with the latest TDM MingW libgomp-1.dll isn't in the
location where build.xml expects it. But I'm not sure in what version
this change (I assume it changed) was made, nor which versions of MingW
other developers are using. Assuming that most developers will
eventually update their MingW (if they haven't already), I think it
would make sense to change it in BZR, or am I missing something? (If no
one starts protesting I'll make the change in a day or so.)
For reference, the old location was:
${mingw}/lib/gcc/mingw32/bin/libgomp-1.dll
The new location is:
${mingw_bin}/libgomp-1.dll
12 years, 2 months
Re: [Inkscape-devel] plans on 0.49
by gespertino＠...400...
> From: Jasper van de Gronde <th.v.d.gronde@...528...>
> Subject: Re: [Inkscape-devel] plans on 0.49
>
> I do have a few questions though. I love the idea to bring developers
> together, as I think this could indeed help increase and maintain
> motivation, as well as providing a moment to simply "get things done".
> However, what kind of numbers and funding are we talking about? If we
> want to meet physically the costs could be quite high. (And if we don't
> meet physically, then what is the funding for?)
That's where linux vendors come in. It's unlikely to fund a sprint
with individual donations, but if we can get companies like Google,
Canonical, Novell, Red Hat, etc. to get involved, things seem more
feasible. Of course we have to do it first, but I'm sure that we have
interesting things to offer to those companies: better, more
integrated software for something as important as design is
undoubtedly something their platforms (and their business) could
benefit of.
Another option is to organize regional sprints. For instance, it's
considerably cheaper (for the physical meeting) if the participants
are all europeans, or all north-americans, etc.
Of course people from other regions could follow the sprint and
collaborate on-line.
One sprint could be europe-based, the next in north-america, and so on.
I guess that doing it this way costs would be reduced considerably,
and people from other areas would still be able to join to the event
on-line.
I can't talk about numbers because I don't know them. Probably LGM
organization could give us some estimations about how much is involved
so we can do some calculations and see what's possible and what not.
> Also, what you describe still requires quite a bit of organization, how
> would you propose to deal with that? (Are you proposing to head up
> the operation?)
Not being a programmer and living in south america (where a pretty
small amount of developers are) makes me a bad candidate for that, I
guess.
I commit myself to help in whatever is needed to materialize this
project, but I'm sure there is a lot of people better prepared for the
task than me.
I think we should all discuss the organization details. I know it's
not something easy to co-ordinate and I didn't think about all the
details, but I'm sure that we as community can manage to make it work.
> And how do we deal with disgruntled donors?
> If we define groups of features/fixes as targets, that's cool for helping
> focus donations and such, but afterward I am sure that some things
> won't have been addressed and people won't like that if they donated
> because of that specific item.
> This is of course not "fair", in the sense that we would be (and should
> be) clear about how this process works, but human psychology is hardly
> ever fair.
Well, first we have to define achievable goals. Being too ambitious
and making a very interesting list of goals would of course get more
funding but it would also increase the chance of disgruntled donors at
the end.
If the goals of the sprint are manageable and the resources and time
are planned correctly, the outcome should be enough to make donors
happy.
Of course, s**t happens. Things can turn more difficult than expected
and some goals could end up unfinished.
I guess that commitment from the coders to give those unfinished goals
exclusive priority for the next days/weeks after the event should be
enough to make donors know that their money wasn't given in vain.
I mean, if coders say "I commit myself to make my best to finish these
tasks in the defined timeframe or, if it's not possible, in the
following weeks" no donors should feel deceived if things don't turn
out as expected after the sprint.
I think it's just matter of good communication. First of all we should
avoid the wrong conception that donors are paying for X feature.
Donors would be contributing to make a sprint with specific goals
happen and developers involved should commit to complete those goals.
Sounds fair enough. :-)
Thanks for your comments, Jasper.
12 years, 2 months
SVG Compositing Specification
by Tavmjong Bah
Hi,
The SVG Compositing Specification has been published:
http://www.w3.org/TR/SVGCompositing/
This specification adds quite a few new compositing modes. Note, this is
not yet an approved standard but is in the process of "last call" which
is a period of time interested persons can comment on the specification.
Comments can be submitted until April 12th 2011.
Tav
12 years, 2 months
Re: [Inkscape-devel] plans on 0.49
by gespertino＠...400...
A couple of days ago I mentioned to Prokoudine an idea that probably
is worth to discuss.
It's a known fact that bounties never worked for Inkscape and GIMP,
but that doesn't mean necessarily that money wouldn't help. What is
needed is to find a different way to use the money that comes from
donations and could come from companies (like linux vendors, for
instance).
This isn't a new idea. It's just a mix of some ideas that already work
(crowd funding, GSoC, hacking sprints, etc).
Instead of picking individual feature requests, developers could make
a list of targets, following project's roadmap. In that point
community (and companies interested) could express their needs and
wishes, and project active developers could decide if some of those
requests fit with the existing plans.
Once a targets lists is created and cleaned up, developers should make
an estimation of time and people needed to reach those targets. The
idea is to group those targets in small "packs" so it's not too
ambitious to expect their completion in a limited period of time.
Also in that stage would be good to define if more people than the
available is needed, and what upstream projects are connected to the
planned goals in order to contact their mantainers and communicate
what would be needed and in what timeframe.
Once that information is ready and available publicly, then money
comes into play. People can start to donate and companies could be
contacted to get sponsoring.
That money wouldn't be used to pay for features. The idea is to
organize a hacking sprint, giving developers a chance to meet and more
importantly, companies could lend developers who could benefit from
having core and active developers in a common physical space to ask
them about project particularities. This would be also a good
opportunity to document code and details that could be useful for
other developers in the future.
I think this could refresh the motivation of existing developers and
attract new people, while at the same time it could make companies
commit to the development of graphic applications. After all, having
quality applications is what free operative systems need to reach more
people and be more interesting to users, so this could be a good
opportunity for linux vendors.
I know this is just an idea and it making it work it won't be as easy
as talking, but at least I'm interested to know what developers and
the rest of the community thinks about it.
Is it possible? Could it work for projects like Inkscape, GIMP or Scribus?
12 years, 2 months
[Fwd: [Merge] lp:~ado-papas/inkscape/bug_167419 into lp:inkscape]
by ~suv
Anyone willing to help with testing/reviewing? IMHO this would fix an
annoying issue with linked offsets.
It would be great to have it merged into trunk before another pending
merge (gsoc-cairo) possibly requires yet again a rewrite, as well as
backporting the fix to the 0.48.x branch for 0.48.2 (if doable).
~suv
-------- Original Message --------
Subject: [Merge] lp:~ado-papas/inkscape/bug_167419 into lp:inkscape
Date: Thu, 10 Mar 2011 18:26:38 -0000
From: Adonis Papaderos <ado.papas@...1244...>
Reply-To: mp+52899@...2499...
To: mp+52899@...2499...
Adonis Papaderos has proposed merging lp:~ado-papas/inkscape/bug_167419
into lp:inkscape.
Requested reviews:
Adonis Papaderos (ado-papas)
~suv (suv-lp)
Related bugs:
Bug #167419 in Inkscape: "square/circle/polygon/spiral and linked
offset misbehaviours"
https://bugs.launchpad.net/inkscape/+bug/167419
Bug #184341 in Inkscape: "Linked offsets ignore clone movement
preferences"
https://bugs.launchpad.net/inkscape/+bug/184341
Bug #239430 in Inkscape: "linked offset ungroup issue"
https://bugs.launchpad.net/inkscape/+bug/239430
For more details, see:
https://code.launchpad.net/~ado-papas/inkscape/bug_167419/+merge/52899
Fix some issues with linked offsets. Changed the rendering of the offset
to take into account the transformation of the source object, as is the
case with the use element, and copied the move compensation logic from
uses to offsets. There is a speed penalty though because of this, since
I cannot find a reliable method to predict whether there is a change to
the source object data or a transformation applied to it.
The second patch removes an optimization I implemented using the
transform event, since this event is not emitted on undo and redo actions.
--
https://code.launchpad.net/~ado-papas/inkscape/bug_167419/+merge/52899
You are requested to review the proposed merge of
lp:~ado-papas/inkscape/bug_167419 into lp:inkscape.
12 years, 2 months
