Rendering cache committed
by Krzysztof Kosiński
Hello
I committed the rendering cache work in revision 10579 of trunk.
If you encounter serious problems, you can turn off caching completely
by defining the environment variable _INKSCAPE_DISABLE_CACHE. For
example, run inkscape as:
$ _INKSCAPE_DISABLE_CACHE=1 inkscape
By default, each drawing will use up to 64 MB of memory for rendering
data. It can be set in the "Rendering" page of the preferences
(renamed from "Filters").
As usual, problem reports are welcome.
Regards, Krzysztof
10 years, 11 months
Complete removal of libnr
by Krzysztof Kosiński
Hello all.
Revision 10589 removes all trace of libnr from Inkscape's code, which
was a major refactoring goal. This is a rather big change and might
break various things. Here is a short summary of the changes:
1. NRRect was replaced by Geom:Rect and Geom::OptRect as appropriate.
2. NRRectL was replaced by Geom::IntRect and Geom::OptIntRect as
appropriate. Note that the semantics of Geom::IntRect's contains()
function for points are slightly incorrect at this time, as max() will
be considered part of the rectangle even though it should not be. This
doesn't cause any obvious problems for now.
3. SPItem bounding box methods were rewritten. There are now methods
for bounding boxes in 3 different coordinate systems:
- visualBounds(), geometricBounds(), bounds() - bounds in the item's
own coord system
- desktopVisualBounds(), desktopGeometricBounds(), desktopBounds() -
bounds in desktop coordinate system (origin in bottom left, but
user-editable in the future)
- documentVisualBounds(), documentGeometricBounds(), documentBounds()
- bounds in SVG coordinate system
The "geometric" version returns the object bounding box as defined by
SVG (does not consider stroke, filters, clipping paths, masks, etc.).
The "visual" version considers all of this to return the bounds of the
area affected by the object. The legacy "approximate bbox" was
removed.
4. NRActiveObject was used only by SPAction. SPAction was converted to
GObject and NRActiveObject listeners were replaced by signals. Some
changes to verbs were made along the way.
5. nr-point-fns.h was used by some things in the gradient editor and
was replaced with code using Geom::LineSegment.
Regards, Krzysztof
11 years
pdf import again: poppler native vs. poppler cairo
by the Adib
Hello All,
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)
regards,
Adib.
11 years, 2 months
Re: [Inkscape-devel] OCAL Dialog Redesign
by Andrew
Hi Guys,
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
Clip Art
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
dialog.
Thanks!
--
Andrew
Screenshots:
http://wiki.inkscape.org/wiki/index.php/OCAL_Dialog_Re-Design
== 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
use later
- Big cleanup in terms of code
11 years, 8 months
Re: [Inkscape-devel] Inkscape 0.48.2
by jbc.engelen＠swissonline.ch
Great news that the Windows release of 0.48.2 is finally available for download!
Thanks a lot Uwe!
Ciao,
Johan
----- Reply message -----
Van: "Uwe Schöler" <mail@...2227...>
Datum: ma, aug. 15, 2011 00:03
Onderwerp: [Inkscape-devel] Inkscape 0.48.2
Aan: "Krzysztof Kosiński" <tweenk.pl@...400...>
CC: <inkscape-devel(a)lists.sourceforge.net>, <suv-sf@...58...>
Everything OKAY!
I had problems with my paths... sorry.
0.48.2 is fine now.
I'll upload it to SF
Sincerely,
UweSch
Am 14.08.2011 23:49, schrieb Krzysztof Kosiński:
> 2011/8/14 Uwe Schöler<mail@...2227...>:
>> I've some problems creating 0.48.2 for windows. I get a couple of error
>> messages during building.
> I just checked out 0.48.2 from Bazaar in my Windows XP VM, and I
> encounter no problems when building from a source checkout with
> TDM-GCC 4.4.1. It looks like the warning emitted when compiling btool
> is irrelevant (and I don't even get the warning).
>
> I'm 90% sure the first error is caused by building from a tarball (you
> just need to create the required inkscape-version.cpp file manually),
> the second looks like a problem with permissions (maybe UAC is getting
> in the way?)
>
> Regards, Krzysztof
------------------------------------------------------------------------------
FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
Subversion made easy with a complete admin console. Easy
to use, easy to manage, easy to install, easy to extend.
Get a Free download of the new open ALM Subversion platform now.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
11 years, 11 months
Inkscape 0.49 status update & discussion of a proposed release plan
by Josh Andler
Hey All!
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
time.
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
newb. ;)
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?
Cheers,
Josh
12 years
Brief inkscape-web project update: need help with content migration
by Chris Morgan
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.
-- Chris
12 years
Re: [Inkscape-devel] linked offsets
by Jasper van de Gronde
On 25-08-11 21:51, Adonis Papaderos wrote:
> It apears that the work I have done with linked offsets to make them
> behave as linked offsets have the side-effect of breaking compatibility
> with old drawings that rely on the old behavior. (see bug #817907
> https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit
> 10109 should be revoked and the attached bugs marked as won't fix (since
> I don't see any other way of fixing these).
>
> What do you think?
It might be better to discuss this on the developers mailing list
(instead of sending it to everyone in the inkscape developers group).
As for your question, as far as I can tell it's choosing between
sticking to old behaviour that doesn't make much sense and causes
problems for at least some people and new behaviour that makes a lot
more sense but might cause some problems for existing drawings. This is
not an easy choice, but I would be inclined to go with the new
behaviour, as that's probably the better choice in the long run.
Obviously going with the "new and improved" behaviour will cause some
problems with existing material, but I'm afraid it's impossible to
always avoid this. Now, if you want to be really friendly towards people
with existing material there are a couple of possible courses of action:
1. Detect version of Inkscape that file was saved with and automatically
convert linked offsets.
2. Supply an extension that can "fix" linked offsets from older versions.
3. Provide details for manual migration (what's the easiest way to get
people's linked offsets to behave like they used to).
4. Make the behaviour optional (per file), possibly in combination with
version detection.
5. Create a new way to achieve linked offsets so that it does not affect
old linked offsets.
Personally I'm not a big fan of 4 (extra code, extra complication).
Option 1 is kind of nice in some cases, but in this particular setting
it could prove to be a hassle if files move between people with
different versions. All in all I would recommend option 2 or 3, and
possibly 5, if you're feeling adventurous :)
Option 5 is probably a bit more involved, but would be cool. In
particular, I was thinking that it might be cool to be able to use LPEs
on "clones", and a linked offset would then just be a certain kind of
LPE. Currently this isn't possible as clones are not paths, so it would
probably require creating a new kind of "linked path" and making sure
that LPEs work with that. Then we would need to create an LPE that does
an offset and make sure that the offset can be edited on canvas.
With option 5 we could choose to keep the old linked offsets code around
or to remove it. The latter has the advantage that existing files will
still render correctly, any old-style linked offsets simply aren't
editable as linked offsets anymore.
12 years
MediaWiki theme
by Krzysztof Kosiński
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.
Regards, Krzysztof
12 years
SVG on web.
by john Culleton
I came across an example of svg used as a "wireframe" or mockup of
the appearance of a web page here:
http://www.w3.org/Graphics/SVG/IG/wiki/images/e/ed/Planet.svg
The interesting thing to me is that this svg renders the same in
Inkscape and in Firefox. And it is editable in Inkscape. So it appears
that svg could be added to a web page design.
Given that facility, can the svg portion be used for dynamic purposes.
For example could an anchor be added to point to another url? Or is svg
a graphics-only format?
Thoughts, anyone?
--
John Culleton
Wexford Press
"Create Book Covers with Scribus"
http://www.booklocker.com/books/4055.html
12 years
