- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Cppify Branch Review
by Markus Engel 20 Sep '13

20 Sep '13

Hi there, > SP_TYPE() macros should be reimplemented as dynamic_castso that they generate compile-time errors when something not derived fromSPObject is passed. I checked that and it is currently impossible withoutchanging a huge amount of code. Some parts use these GSLists and they storevoid-pointers. Thousands of SP_TYPE-lines would fail compilation. I'd suggestdoing this change later. > cppify/src/widgets/rect-toolbar.cpp:117:52: error:cannot dynamic_cast 'items->_GSList::data' (of type 'const gpointer {akavoid* const}') to type 'class SPRect*' (source is not a pointer to class) Regards, Markus

5 14

Re: [Inkscape-devel] Release and Website
by Bryce Harrington 20 Sep '13

20 Sep '13

On Tue, Sep 10, 2013 at 10:40:01PM +0200, Alex Valavanis wrote: > I'd be very reluctant to see cairo & pixman brought in tree. My > experience with "unforking" GDL suggest that this could cause major > maintenance headaches down the line. I think that something like the > following approach would be a nicer solution: > > == develpment/testing == > > 1. Bump dependency versions in configure.ac etc to the required > (unstable) versions of Cairo/pixman. Mark bugs as "Fix committed" > 2. Create a devlibs branch with a suitable (unstable) Cairo/pixman versions > 3. Create a dependency on a daily build of Cairo/pixman in the PPA > > ...it's then up to individual developers to install their own unstable > development libs rather than it being our problem to keep it in trunk. > Early adopters and beta testers will be able to continue using the > PPA without having to compile from source (or know/understand what has > changed). > > == pre-release == > > 4. Wait for suitable *stable* versions of Cairo/pixman to be released > 5. Bump devlibs trunk versions of libraries > 6. Kill the unstable devlibs fork > 7. Bump PPA Build-Depends version in debian/control and drop > dependency on daily Cairo builds > 8. Test thoroughly > > In any case, I don't think we should go ahead with the 0.49 release > until all the dependencies are stable. If that means a longer wait, > I'm fine with that! For Ubuntu users, PPAs seem to be a commonly used solution to this type of problem. This would be straightforward to implement and I shouldn't think it would cause that much surprise to users. For non-technical users I can see how the process might be a bit inconvenient; is that what folks are worried about? If we're really just concerned here with developers being able to build Inkscape on 12.04, I'm sure they could handle installing junk from a PPA. Another option is to get the dependencies added through backports. As a general rule they never backport libraries, so this seems like a non-option for cairo / pixman, however it might be worth checking into if people feel the PPA solution is insufficient. Pixman and Cairo are both well maintained, so you never no. I've seen crazier things accepted. If the need for newer cairo/pixman is narrow enough (i.e. just the downscaling fix), rather than put the libs in-tree, what about just adding an autoconf check for the cairo version, and then just #ifdef the appropriate code, so inkscape will build and work with old cairo/pixman (with the bug) as well as newer cairo/pixman (with the fix). This seems like it would give the most flexibility for everyone, without being terribly messy. Carrying an #ifdef to 2017 might be more palatable than two entire source trees... Bryce

1 0

Windows XP. Cannot compile rev 12544 or rev 12547
by alvinpenner 20 Sep '13

20 Sep '13

messages are as follows: Make error line 298: problem compiling: In file included from src/test-src.cpp:27:0: ./src/color-profile-test.h: In static member function 'static void ColorProfileTest::createSuiteSubclass(ColorProfileTest*&)': ./src/color-profile-test.h:34:91: error: 'COLORPROFILE_TYPE' was not declared in this scope ./src/color-profile-test.h: In member function 'void ColorProfileTest::testSetRenderingIntent()': ./src/color-profile-test.h:77:91: error: 'COLORPROFILE_TYPE' was not declared in this scope ./src/color-profile-test.h: In member function 'void ColorProfileTest::testSetLocal()': ./src/color-profile-test.h:97:91: error: 'COLORPROFILE_TYPE' was not declared in this scope ./src/color-profile-test.h: In member function 'void ColorProfileTest::testSetName()': ./src/color-profile-test.h:121:91: error: 'COLORPROFILE_TYPE' was not declared in this scope In file included from src/test-src.cpp:184:0: ./src/sp-style-elem-test.h: In static member function 'static void SPStyleElemTest::createSuiteSubclass(SPStyleElemTest*&)': ./src/sp-style-elem-test.h:31:75: error: 'SP_TYPE_STYLE_ELEM' was not declared in this scope ./src/sp-style-elem-test.h: In member function 'void SPStyleElemTest::testSetType()': ./src/sp-style-elem-test.h:55:75: error: 'SP_TYPE_STYLE_ELEM' was not declared in this scope ./src/sp-style-elem-test.h: In member function 'void SPStyleElemTest::testWrite()': ./src/sp-style-elem-test.h:81:35: error: 'SP_TYPE_STYLE_ELEM' was not declared in this scope ./src/sp-style-elem-test.h: In member function 'void SPStyleElemTest::testBuild()': ./src/sp-style-elem-test.h:107:36: error: 'SP_TYPE_STYLE_ELEM' was not declaredin this scope ./src/sp-style-elem-test.h: In member function 'void SPStyleElemTest::testReadContent()': ./src/sp-style-elem-test.h:135:36: error: 'SP_TYPE_STYLE_ELEM' was not declared in this scope -- View this message in context: http://inkscape.13.x6.nabble.com/Windows-XP-Cannot-compile-rev-12544-or-rev… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 2

Fix for Bug 1227827 (clipboard)
by Markus Engel 19 Sep '13

19 Sep '13

Hello Krzysztof, regarding your fix for this bug: https://bugs.launchpad.net/inkscape/+bug/1227827 I already posted a solution that I thinks addresses the actual problem better. With that it's easier later when a clipboard class will be added. Currently the clipboard code directly manipulates the xml tree which is undesireable. Regards, Markus

1 0

[Tracing] Report #8: Inkscape integration
by Vinícius dos Santos Oliveira 19 Sep '13

19 Sep '13

I proposed a merge: https://code.launchpad.net/~vinipsmaker/inkscape/libdepixelize/+merge/185237 The code is based on current practice, I think (grep is my friend). The changes between my choices and the code that inspired me was favoring C ++ish interfaces when available. I have to say that Inkscape is pretty huge and took me some time to finish this integration. The whole libdepixelize was developed with Inkscape in mind and integration was very straigh forward. There are options to generate voronoi diagrams, B-Splines and optimized B-Splines. I'm still working on B-Splines optimization and it's not possible to get a optimized output right now, but the interface is done and after I implement this step the only update required will be a "libdepixelize release bumping", with no code changes required to Inkscape itself. I went beyond Kopf-Lischinski to preserve more color information and the result is quite nice, but when you have a really evil gradient the result will be worse. The "worse" result is caused by a small bug (can and will be fixed) and have small artifacts (no crash, don't worry). Also, I made a major refactor on a large part of the project that will make it 4 times more maintainable and greatly abstracts memory layout access. The memory layout access abstraction is important to implement the suggested improvement (cache oblivious algorithm) by Nathan Hurst. I improved the "depixelize" binary, so it can be packed by distros. This is what I remember so far, but there were a lot of changes and I'm sure I'm missing some one. Now that I finished the Inkscape integration I'll be working on the B-Splines optimization. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

8 17

Cppify Branch Review
by Markus Engel 19 Sep '13

19 Sep '13

Hi everyone, have you worked your way through my changes yet? Any comments? :) Krzysztof, you wanted to do the review? Regards, Markus

5 13

[ Recolor ] Status Report
by Arshdeep Singh 19 Sep '13

19 Sep '13

Hi all, Sorry for not being able to give a report for the past two weeks. I was in regular touch with my mentor though, as well as Josh. The project stands as such: 1.) The nodes are added to the wheel when a new object is added to the active selection. 2.) Removal of nodes is a tricky issue. We are working on that currently. 3.) Updating of objects on the canvas was achieved earlier on. That snippet has to be used for active editing after the removal issue is solved. >From discussions with my mentor and Josh, we all concur that the project can only achieve its first half into completion in the given time frame. Namely, the part of the tool where we could save color schemes does not seem feasible to implement in the remaining time frame. -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

1 0

Please don't neglect the release notes
by Josh Andler 19 Sep '13

19 Sep '13

If you've committed any noteworthy changes please make sure everything is reflected there. This goes for GSoC projects as well. Here's the link http://wiki.inkscape.org/wiki/index.php/Release_notes/0.49 , it's preferred if the people who created the features/changes are the ones to describe them. Cheers, Josh

4 3

Mac OS X 0.48.4 RC5
by Valerio Aimale 19 Sep '13

19 Sep '13

For Mtn Lion: http://rapidshare.com/files/1406366642/Inkscape-r0.48.4-r9943-10.8%2B-x86_6… For Lion: http://rapidshare.com/files/2591591009/Inkscape-r-10.7%2B-x86_64_RC5.dmg fixed: - restored drag&drop, it was a problem with the pasteboard fix, not the menu integration. - further editing of the keymapping for menu accelerators. Hopefully it will cover most of the cases. Regarding pasting into text fields, that is something we might learn to live with for the time being. Valerio

7 13

Pixbuf vs Cairo Surface
by Martin Owens 19 Sep '13

19 Sep '13

https://bugs.launchpad.net/inkscape/+bug/871563/comments/12 Hey KK, Your message above in that bug report is a little cryptic because the current code and the patches previous suggested use pixbufs, while you talk about cairo surfaces. Are you saying that the pixbuf code should be removed and replaced with dealing directly in cairo surfaces? I'm a little confused because the bug is about pasting objects, and I can only assume that we get a pointer to a block of data when someone pastes things in and we stuff that into an image object of some kind. Could you explain what you mean? Martin,

3 10