as the problem is still there I would propose following intermediate solution:
currently in the codebasis there is also an pdf import via
poppler-cairo. This one is disabled.
I would like to enable this as an additional pdf import possibility.
We have to decide later when it comes to the release which one to
integrate into the release.
so we can test in parallel the two options.
we have a big tester basis (compared to separate launchpad branch)
we get the possibility to switch to an tested poppler-internals
independent solution (while using poppler)
I there is no big NONO I will go forward and enable this within the next days.
attached the patch that is needed for this (tested on windows, should
work on Linux)
So I have been doing a lot of work on the Import from OCAL dialog and I
have finally finished! I was wondering whether I could get some testing,
especially on some different platforms with different internet connections.
All you need to do is get my branch using:
bzr branch lp:~and471/inkscape/ocal-dialog-improvements
And then compile as usual. You will find the dialog in File > Import
So yeah, basically I want a lot of testing, to iron out any errors that
I have missed and also feedback on the stuff I have done. Then once that
is all done, I shall propose for merging into trunk.
A list of changes is below, as well as a link to screenshots of the new
== Changes ==
* UI Redesign (which includes)
- Altered the padding and packing of all widgets
- Added search entry with clear and search icons
- Added OCAL Logo overlay
- Put descriptions inline in list
- New preview widget that shows extra metadata
- New status widget to notify on errors/success etc.
- Dialog is now persistent (retains state)
- Better messages for the user
- Changed title/menuitem to 'Import Clip Art'
* Backend stuff (which includes)
- Use new GFile API instead of depreciated GNOMEVFS
- Use async methods so the UI isn't blocked
- Use smaller, thumbnail images in the preview widget (save on
bandwidth and increase speed)
- Implement cancelling of operations
- Put downloaded resources into one directory, from which we can
- Big cleanup in terms of code
Are there any larger features people are planning on still for this
cycle that aren't well known? If you want to get something in that is
unknown, please speak up soon because we want to help you test it. :)
I know of the following items which we're looking to get in:
*All of the current GSoC projects. :) *fingers crossed*
*What will also probably be more work towards GTK3 compatibility.
On the refactoring front I can report good news that Abhishek Sharma
has gotten all proper libcroco stuff submitted upstream. If lucky, we
may be just a few distribution releases away from being able to take
libcroco out of trunk!
Additionally, Alex Valavanis has brought our in-trunk copy of libgdl
up-to-par with the 2.X (whatever is "current") branch of libgdl. I'm
unsure if patch submissions have been made in that direction for the
couple of custom features that we have in our copy. Either way,
hopefully we'll be able to get our copy out of trunk around the same
Campbell Barton has been plugging away on cmake related stuff. I'm not
sure of the status of it, especially cross-platform-wise.
Obviously, Krzysztof Konsinski's GSoC work from last year has been
merged and all I can say is... please stress test this the best you
can. Pretend you don't know how to use Inkscape and break it like a
Are there any big refactoring goals we're still missing out on that
people think we should shoot for? (please be reasonable)
I'm planning on looking to look into a couple Windows things, but will
save that for a different email.
All of that aside, here is a VERY loose and preliminary proposed release plan:
Mid-August for Chill
Beginning of September for Frost (Bug Hunt begins)
End of September for Feature Freeze
End of October for Hard Freeze
Sometime in November for Branch & Release
I'd like feedback on the bug hunt goal. I think we've actually gotten
a lot accomplished for a release just with the cairo renderer alone.
Newly created bugs aside (as in, if you introduce bugs during this
cycle, they don't count toward the total), 250 points seems like a
reasonable goal. Do note, we will be releasing an uber-stable 0.48.3
more likely than not, so if we release "0.49" to a wider audience to
get more testing, it's not so bad.
For those new to the process, our bug hunt will begin at Feature
Freeze. Traditionally, we specify a point target for us to reach, and
award us points based on the severity of the bug: 3, 6, 9, or 12
points for low, medium, high, and critical.
Lastly... version numbering... we have way too many opinions about
this. I do want to reiterate, Inkscape deserves a more "grown-up"
version numbering scheme for users. I very much think Mental's comment
about we should have a public version number and then stick with our
current numbering scheme for development purposes. It's akin to
code-names internally and solid numbers publicly. So, are date formats
appealing? YY.MM or YYYY, some arbitrary number we just agree on
starting with, bump the decimal place from with the current numbering,
or what? If we get too many opinions again, I'll propose handing it
over to the board...
Thoughts or comments?
I don't have time to post a proper status update with more details of what
needs doing and I'm away for the next two days, but if there's anyone
inclined to help with the inkscape-web project, please take a look at
http://dev.inkscape.org/ and see where you can help. Content migration
(English and other languages) is the main thing which needs to be done; many
things which need to be done will be quite obvious. Code and content etc.
is in lp:inkscape-web.
Can the relevant person please update MediaWiki to 1.17 and change the
default theme to Vector? Our custom theme is seriously broken and
makes the wiki look like a mess.
Also, I am rather tired of excuses like "we are going to put all wiki
content in a new awesome system Real Soon Now(tm)". This will surely
take much more time than this simple update.
I've made tarballs of the 0.48.2 release of Inkscape. Please, as per
usual don't announce these generally until packages have a chance to
make binary packages for users.
I'd really like to thank those that worked on backporting all of the
patches, it's tireless and unforgiving work. But I'm sure this will
delight a bunch of people.
== MD5 Sums ==
== SHA1 Sums ==
The branch at lp:~tweenk/inkscape/gsoc-caching contains the first
testable features of my performance improvement project. The SVG
drawing is rendered to a separate surface, so it doesn't need to be
redrawn every time there is an editing control drawn over it. The
responsiveness of path highlighting in complex documents is improved
dramatically. If you turn off real-time updates of paths and leave
only real-time updates of outlines on in node editor preferences,
there is also a significant improvement in responsiveness when editing
complex filtered paths.
To fix some breakage with clipped groups (appears to be a Cairo
problem, but I couldn't isolate it) I have substantially changed the
rendering pipeline. Clipping paths are now rasterized and the drawing
is composited with them using the IN operator. This allows us to
handle nested clipping paths and clip-rule correctly. As an unrelated
improvement, text objects can now be used as clipping paths.
tried building with clang again and now there is an error in:
Any ideas on how to fix? (ignoring non-POD element type's, I know about those)
A while back I was told I had to commit changes to 2geom elsewhere,
what repository does this use?
We'll be discussing Advanced Gradients in today's SVG Working Group
meeting. As an experiment, I've made a modified version of Inkscape that
can read in the proposed syntax for Mesh Gradients and display the
meshes. You can look at the results at:
I have a couple things I'm going to look into for 0.49. One thing is
offering msi installers. The other is potentially providing a native
64bit version as well.
There was recently a discussion, I believe on the gtk list, about
using OpenSuse's build service to compile windows binaries. I checked,
and indeed there is a 64bit version of Inkscape compiled for Windows
as well as all necessary 64bit libs (I have yet to test them, but it's
planned for this weekend). It's a little different since they're
packed in RPMs and use an "interesting" directory structure. However,
I bet with a little bit of scripting we could automate all aspects of
this and possibly add in re-packaging it and pushing automated nightly
builds to modevia.