September 2013 - Inkscape Devel

Notes for r12550 (Status Bar Text)
by Martin Owens 20 Sep '13

20 Sep '13

Hey Devs, In r12550 I had to do more changes then I expected fixing bug lp:1199192 and I want to FYI them here. At first I thought the broken collection status was from my previous work. But it turned out the functionality had been gutted by refactoring work from elsewhere. (C++ification I think) So I decided to continue the work and re-factored this too. Each object now has a new display_name() method which returns a translated const char* for use in the status bar. description() now returns everything but the display_name (some fixes in consistency here too) and getDetailedDescription returns the whole lot plus mask/clip info. This getDetailedDescription is used in the single item status bar and replaces the vanilla description(). This should improve information about clip/mask and give more consistency for single items. display_name() is used to get a list of types. That code was shorted too, made more dynamic. -200 Lines +171 Lines Best regards, Martin Owens

2 1

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

20 Sep '13

That's the same problem as with the clipboard, but thistime, Krzysztofs return-solution won't work ;) . The patch is essentially the same I appended in this bugreport, I attached the version adjusted for grids. Regards, Markus -----Ursprüngliche Nachricht----- Von: suv@...2204... [mailto:suv@...2204...] Im Auftragvon su_v Gesendet: Freitag, 20. September 2013 13:56 An: Krzysztof Kosiński Cc: Markus Engel; inkscape-devel Betreff: Re: [Inkscape-devel] Cppify Branch Review On 2013-09-19 04:09 +0200, Krzysztof Kosiński wrote: > There are basically two issues which stand out: > > 1. Inconsistent whitespace > 2. Use of explicit this-> instead of markingmember variables with a > leading underscore. > > However, I think these two stylistic problems can befixed later and > it's better to commit now than to wait and let thisimportant work get > out of sync with trunk. > > I committed the merge as revision 12532. After the merge in r12532 'File > Document Properties> Grids' no longer display the settings for defined grids (works withr12531, fails with r12532). Steps to reproduce: 1) launch Inkscape (default prefs, default new doc) 2) toggle on grid (menu 'View > Grid') to create adefault grid 3) open 'File > Document Properties > Grids' toedit the settings Expected result: The settings for the new grid are accessible on the'Grids' page Actual result: The 'Defined grids' section is empty. Warning on the console: ** (inkscape-12532:13355): WARNING **: TypeNotRegisteredexception: inkscape:grid (tested and confirmed on Ubuntu 12.10 and OS X 10.7.5)

3 2

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

20 Sep '13

>> It seems that the changes in r12532 cause testcompilation failures. >>Markus, can you provide a patch which would fixrunning "make check"? > I'll have a look. > By the way, are you sure that the change you made inr12543 is correct? >https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-Image-Data-in-Memor > y.html#gdk-pixbuf-copy > This page tells me that g_object_unref would havebeen perfectly fine. > Anyway, the pixbuf is allocated using"malloc", so I think "delete" is not the right solution, isit? Your change actually looks right, I seem to have mixedsomething up here. Never mind. I attached a little patch that makes "makecheck" work again. Note that this linker flag it not ideal, the error iscaused by the removal of the static library. The problem is just the oppositeof the one I mentioned in the merging proposal discussion: The linker doesn'tomit things, it tries to link in things twice. Regards, Markus

3 2

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