August 2011 - Inkscape Devel - Inkscape Mailman

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

Rendering cache committed
by Krzysztof Kosiński 25 Oct '12

25 Oct '12

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

2 14

Complete removal of libnr
by Krzysztof Kosiński 15 Sep '12

15 Sep '12

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 38

pdf import again: poppler native vs. poppler cairo
by the Adib 24 Jun '12

24 Jun '12

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.

3 6

Re: [Inkscape-devel] OCAL Dialog Redesign
by Andrew 28 Dec '11

28 Dec '11

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

5 5

Re: [Inkscape-devel] Inkscape 0.48.2
by jbc.engelen＠swissonline.ch 01 Oct '11

01 Oct '11

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

8 19

Inkscape 0.49 status update & discussion of a proposed release plan
by Josh Andler 19 Sep '11

19 Sep '11

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

8 16

Brief inkscape-web project update: need help with content migration
by Chris Morgan 09 Sep '11

09 Sep '11

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

7 8

Re: [Inkscape-devel] linked offsets
by Jasper van de Gronde 31 Aug '11

31 Aug '11

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.

13 19

MediaWiki theme
by Krzysztof Kosiński 30 Aug '11

30 Aug '11

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

4 6