- Inkscape Devel - Inkscape Mailman

Two Week Status
by Martin Owens 23 Sep '13

23 Sep '13

Hey Devs, Two weeks ago I sent a message asking about a new Inkscape release. Over the past two weeks, we've managed to close the vast majority of blocking bugs and of the last 3, 2 are in progress: In Progress #850992 Top layer, Blend mode is multipy, Pattern disappear In Progress #953992 Imported pattern fill disappers while transforming Triaged #1005892 Patterns applied to text objects are blurred The other blocker is our cairo render issue, which I'm counting on the fix being delivered to our build system and making sure we have the library in our ppa/trunk ready to go. I'm wondering if I can get someone to work on this? We have 16 regressions currently reported: http://tinyurl.com/o9lq44w and I think about 2 or 3 floating in the mailing list which people are working on already. We have 56 bugs targeted to 0.49 reported: http://tinyurl.com/l3glywq and these will probably include the above bugs. It looks like our GSoC projects will take a week or three to settle and clear. Although it looks like the majority of work is in already. I think we're in great shape for a release target. I'm going to continue to work on my blocker for this week, which is #850992 and a couple of regressions. Thanks everyone, you guys are awesome. Best Regards, Martin Owens

2 1

[CAD] Re: Status?
by Sebastian Götte 23 Sep '13

23 Sep '13

On 09/19/2013 03:29 PM, Tavmjong Bah wrote: > > Hi, > > There are only a few more days until the end of GSOC. Can you provide a > status report? A list of action items would be good, including a list of > known bugs. > > Things to finish up: > > 1. Documentation (nothing fancy... could be on the Inkscape Wiki or some > other web page). I have documented the changes and UI here: http://wiki.inkscape.org/wiki/index.php/Connectors > 2. A comparison of functionality to the existing code. I tried to do this in the above wiki page. The only removal I did was the code finding shape's centers and intersecting connectors with shape outlines. > 3. Update to latest trunk. I am currently doing that, but I have a SEGFAULT left. The porting to the new C++ SPObject tree was pretty straightforward and mostly consisted of adding "virtual" keywords and removing shim code. > 4. Bugs, particularly any segfaults. > > Here is one bug I just found: > > 1. Select and move a connector (the path, not the ends). > 2. Undo. > 3. Move one of the objects the connector is attached to. > > The path reverts to the moved position. I will look into that. Sebastian

3 4

program logo (Windows)
by Johan Engelen 23 Sep '13

23 Sep '13

Hi all, Inkscape lost its logo somehow (now displays GTK standard app logo, is what I think it is). Any other Windows devs see this? Cheers, Johan

2 1

[CAD] Status report
by Sebastian Götte 23 Sep '13

23 Sep '13

Hi, I made the code more useable and fixed some selection issues. Also, points can now be in groups. A point is added to a group by selecting the group (and nothing else) and shift-clicking to create the point. I am working on a UI to add one or more existing points to a group. Undo/redo does not yet work properly together with the connector context, I had one crash and the point handles do not yet get updated when undoing/redoing. I am working on this. The current code can be found at [0]. Sebastian [0] https://code.launchpad.net/~h-e-6/inkscape/connector-wip

3 9

Scalar nimeric and bar widget
by Jabiertxo Arraiza Cenoz 23 Sep '13

23 Sep '13

Hi to all, i have in my linux box a problem with scalar numeric and bar widget. It dont respond fluid, i think because it redraws in each step instead at the end. How do we think about, for example, detect interaction and dont redraw till the end or with biger steps? Is posibol? Its a low level work for a starter developer? Hi, Jabier.

1 1

[Recolor]
by Arshdeep Singh 23 Sep '13

23 Sep '13

Hi all, I just wanted to shed some light on the present scenario: + Snippet to update the color changes is up and running. [ It has to be hooked to "released" signal of RecolorWheelNode ] + Handling removal of objects: This is the problem area right now. My mentor replied this morning (my time) with an approach to handle removing objects. I am going to try working with that. If this goes downhill, I'll try Sebastian idea. Either way, I plan to stick around and am determined to finish what I intended when starting with GSoC. I will gladly be an active contributor till my school-work is not intimidating and I am mostly free till February (March-April see the final submissions and exams). Regards, Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

1 0

Rending Multiple Times?
by Martin Owens 22 Sep '13

22 Sep '13

Hey Devs, I'm investigating bug lp:850992 (very hard to track down), and I notice something odd. Each time I group or ungroup two objects, the render code on DrawingItem is called many times. I want to know if this is expected and typical behavior since we could be wasting lots of resources re-rendering the same item ever time we click on it or move it. This is my output, some simple couts at the top of calls: Updating DrawingItem: 0xb76e338 Updating DrawingItem: 0xb77a628 Updating DrawingItem: 0xb77a6f8 Updating DrawingItem: 0xb77b000 Updating DrawingItem: 0xe49ea08 Updating DrawingItem: 0xc93c470 Updating DrawingItem: 0xb76e338 Render DrawingItem: 0xb76e338 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render DrawingItem: 0xb77b000 Render DrawingItem: 0xe49ea08 Render DrawingItem: 0xc93c470 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render Drawing: 0xb77b000 Updating DrawingItem: 0xb76e338 Render DrawingItem: 0xb76e338 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render DrawingItem: 0xb77b000 Render DrawingItem: 0xe49ea08 Render DrawingItem: 0xc93c470 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render Drawing: 0xb77b000 Updating DrawingItem: 0xb76e338 Render DrawingItem: 0xb76e338 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render DrawingItem: 0xb77b000 Render DrawingItem: 0xe49ea08 Render DrawingItem: 0xc93c470 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render Drawing: 0xb77b000 Updating DrawingItem: 0xb76e338 Render DrawingItem: 0xb76e338 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render DrawingItem: 0xb77b000 Render DrawingItem: 0xe49ea08 Render DrawingItem: 0xc93c470 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render Drawing: 0xb77b000 Updating DrawingItem: 0xb76e338 Render DrawingItem: 0xb76e338 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render DrawingItem: 0xb77b000 Render DrawingItem: 0xe49ea08 Render DrawingItem: 0xc93c470 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render Drawing: 0xb77b000 Updating DrawingItem: 0xb76e338 Render DrawingItem: 0xb76e338 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render DrawingItem: 0xb77b000 Render DrawingItem: 0xe49ea08 Render DrawingItem: 0xc93c470 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render Drawing: 0xb77b000 Updating DrawingItem: 0xb76e338 Render DrawingItem: 0xb76e338 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render DrawingItem: 0xb77b000 Render DrawingItem: 0xe49ea08 Render DrawingItem: 0xc93c470 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render Drawing: 0xb77b000 Updating DrawingItem: 0xb76e338 Render DrawingItem: 0xb76e338 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render DrawingItem: 0xb77b000 Render DrawingItem: 0xe49ea08 Render DrawingItem: 0xc93c470 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render Drawing: 0xb77b000 Updating DrawingItem: 0xb76e338 Render DrawingItem: 0xb76e338 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render DrawingItem: 0xb77b000 Render DrawingItem: 0xe49ea08 Render DrawingItem: 0xc93c470 Render DrawingItem: 0xb77a628 Render DrawingItem: 0xb77a6f8 Render Drawing: 0xb77b000 This is from /One/ group action. your thoughts? Martin,

5 7

Re: [Inkscape-devel] Removal Of Objects from Selection
by Sebastian Götte 22 Sep '13

22 Sep '13

On 09/22/2013 06:51 PM, Arshdeep Singh wrote: > Hi, > Will pulling the changes of selection.h and selection.cpp suffice to use > for my project ? > Does _notifySelected notify signals for both selection and un-selection ? the signal has three arguments: The object, the selection and a bool that indicates whether the object is now selected (true) or unselected (false). You will also need the few lines in sp-object.h containing the signal logic. Sebastian

2 1

Non-Blockers
by Martin Owens 22 Sep '13

22 Sep '13

Hey SUV, I'm interested in a list of bugs which /should/ be fixed for release, but don't block. Do we have one of those? I couldn't find an existing tag, should we make one? Basically we want to prioritize the next round of bug fixes so we can get Inkscape more ready for a good 0.49 release. Thanks for all your work with testing, it's amazing. Martin,

5 10

[Units] Finishing Up
by Matthew Petroff 21 Sep '13

21 Sep '13

I've now merged phase two of my GSoC project, unit support improvements, with the trunk. I've enjoyed my work this summer and would like to thank the Inkscape community for the opportunity. I plan on staying involved with the project for the foreseeable future. http://www.mpetroff.net/archives/2013/09/20/finishing-google-summer-of-code/ -Matthew

5 4

Admin action required
by Krzysztof Kosiński 21 Sep '13

21 Sep '13

Hello If there's an admin in the room (as in, a member of the Inkscape Administrators team on Launchpad), please do the following: 1. Give commit access to Markus Engel so he can fix further issues with the C++ification himself. 2. Approve me as administrator. Regards, Krzysztof

8 9

Weird fallback mechanism for input data in python scripts
by Alex Valavanis 21 Sep '13

21 Sep '13

Hi All, I found some unexpected behaviour with inkex-based extensions if a non-existent SVG filename is specified. To reproduce: cd share/extensions ./gimp_xcf.py non-existent-file.svg Expected behaviour: * Script exits with an error message "Unable to open non-existent-file.svg" Actual behaviour: * Script silently falls back to reading from standard input, and appears to freeze. This appears to be caused by the fallback mechanism for obtaining data streams in the Effect.parse() function in inkex.py. At the moment, it does this: 1. Try to read file specified as a function argument e.g., my_effect.parse("this-file.svg) 2. If that file can't be opened, try to read the file specified in self.svg_file 3. If that file can't be opened, read from stdin This could lead to some weirdness e.g., e = ProcessImportantData() # Specify the wrong file name somewhere e.svg_file = "wrong-input-data.svg" # Later, try to read from the correct file, but with a typo e.parse("correct-input-data-with-typo.svg_BORK") # When we apply the effect, the "correct-input-data-with-typo.svg_BORK" file doesn't exist, and the script will silently fall back to using the wrong data file. e.effect() I have attached a patch that changes the behaviour so that the same order of precedence is maintained, but the script will fail if the specified file cannot be opened. I'm not the best Python programmer, and I don't know the precise intended behaviour of the extensions system, so please could someone review/comment? AV

1 0

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

21 Sep '13

On Tue, Sep 10, 2013 at 01:32:41PM -0700, Josh Andler wrote: > If we want to go the donation to fix bugs route there will need to be > a majority consensus from the developers (translators and other > community members don't get included in this vote as they fall into > different categories). The short version of this is we really wouldn't > want to upset anyone or have ill-will or tensions arise because others > get compensated while their efforts do not. > > If the developers did want to pursue this, we could then bring this to > the attention of the board. My guess is that if we really had a large > portion of the developers wanting to see this happen, the board would > not likely oppose it. After that we could then discuss with Bradley > Kuhn from Software Freedom Conservancy how to go about implementing > this. If someone wants to try and organize a vote, feel free. I happened to meet Bradley here at LinuxCon and he raised this topic with me. He said that they analyzed all of their projects and Inkscape was at the top of the list for likely success for fundraising. It sounded like they would love to partner with us to raise moneys to help improve the project, be it feature work or stabilization. > >> > Maybe a stupid idea, but here I go :) > >> > Have you ever considered to crowd-fund bugfixing? (i.e.: getting money > >> > to pay somebody to do the work nobody else wants to do) When Inkscape started there were several bug-bounty projects in operation which we watched drift into non-success. I suspect that's why many of us have been a bit skeptical about the feasibility of bug bounties generally. But it's definitely gotten a lot of discussion. By now there must be some good "best practices" identified, so maybe it's just a matter of having someone come up with a plan. > >> > If money can be obtained from a crowdfunding campaign... is there any > >> > qualified person willing to do the job? > >> > > >> > I know it's unfair to developers who already contributed for free, but > >> > as far as I know money is not the main motivation for hackers who persue > >> > the fun aspect of development (new features, challenges). > >> > > >> > Maybe getting somebody paid to take care of the ugly stuff nobody wants > >> > to do is a fair balance and takes the stress out so regular contributors > >> > can focus on the fun stuff. These questions have been on my mind as well. And I am of a similar opinion that if money is being paid for development, let's try targeting it to the stuff we need the most that volunteers don't want to bother with. That sounds very logical. If you would indulge me to blather on a bit more on this topic... I think one problem with the bug bounty programs was that they paid on a per-bug basis. But like I think someone else pointed out, often 90% of the work is just learning the codebase; then the developer could swat a dozen bugs all at once. So, we might want to organize the work as not to fix a specific bug for $, but to fix a collection of closely related bugs for $$$. As to whom to find to do the work, there are a number of options. Hiring an existing Inkscape developer seems least-risk; they will have already climbed at least part of the learning curve and demonstrated their ability and dedication. But finding one who is available and interested could be tricky. Alternatively, we could find a cheap external developer. I think this would increase the administrative workload, and likely wouldn't result in an ongoing developer. But for particularly unenjoyable work, maybe that's acceptable. And there's probably half a dozen other ideas. We've had good success with GSoC, and so something that builds on that (Winter of Bugs?) might be worth thinking about. There are also possibilities beyond just direct paying for development. For example, if we increased our presence at conventions that might pull in more ordinary volunteer developers. Training is another avenue I think could be good. Either arranging some development tutorials ourselves, to help users graduate into developers, or even sending existing active developers to developer training classes (to learn new tricks for performance optimization, debugging, etc.) I am also a big believer in the power of bug triagers to help make bugs easier to fix, such as by helping gather stack traces or document steps to reproduce. This is another tedious job (as I know from experience), but doesn't need to be thankless, and there could be some low-cost ways of stimulating these efforts. > >> > Of course, it's not as easy as it sounds: A qualified developer who > >> > knows the code enough and can meet the technical requirements is needed. > >> > And probably also a person willing to take care of the paperwork and > >> > administrative tasks. And people willing to review the patches... I'm glad you brought up the administrative side. This may seem minor, but it's a prerequisite to finding a developer and is tedious work so could be hard to find a volunteer. We would need this person to be reliable and responsive, able to talk with the lawyers, and prepared to make tough decisions. In fact this was my main counterargument to Brad's suggestion; he indicated the conservancy would love to help on the financing/legal end, but part of the management of this would have to come from us. This has been essentially the same problem the board has run into with other proposed activities - someone needs to take the coordinator role to get it organized. So that's my thinking. Before we start really talking about a paid bug fixer, we need someone to volunteer to do coordination and administration. Or lacking a volunteer, it's an important enough role we could consider making it a part-time paid role, particularly if we could raise enough money for multiple efforts. Bryce

4 8

[Tracing] Report #9
by Vinícius dos Santos Oliveira 21 Sep '13

21 Sep '13

Hi fellow devs (and users following the progress of libdepixelize), I've been coding the B-Splines optimization code for the last several few days and I was struggling to make any progress at all. I've tried SOOO many techniques, but nothing would do. Anyway, I realized that the paper states "... by optimizing the locations of their control points". I was trying to optimize the location of all points (not only control points. Sorry for the useless email, but I just wanted to share my frustration. I'll be uploading the (hopefully) working code today. I'll need to refactor a lot of the shitty code I created. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

2 2

Re: [Inkscape-devel] Code style question
by Markus Engel 20 Sep '13

20 Sep '13

> The main reason for asking if A is ok, is that I'mnot 100% if A is standard accepted practice by all C++ compilers, and will notcause trouble with some compilers. A is allowed according to the c++03 standard, so everycompiler should support this. > A name introduced by a declaration in a condition(either introduced by the type-specifier-seq or the > declarator of the condition) is in scope from itspoint of declaration until the end of the substatements controlled > by the condition. If the name is re-declared in theoutermost block of a substatement controlled by > the condition, the declaration that re-declares thename is ill-formed. [Example: > if (int x = f()) { > int x; // ill-formed, redeclaration of x > } > else { > int x; // ill-formed, redeclaration of x > } > —end example] > The value of a condition that is an initializeddeclaration in a statement other than a switch statement is > the value of the declared variable implicitlyconverted to type bool. If that conversion is ill-formed, the > program is ill-formed. The value of a condition thatis an initialized declaration in a switch statement is > the value of the declared variable if it hasintegral or enumeration type, or of that variable implicitly converted > to integral or enumeration type otherwise. The valueof a condition that is an expression is the value > of the expression, implicitly converted to bool forstatements other than switch; if that conversion is > ill-formed, the program is ill-formed. The value ofthe condition will be referred to as simply “the condition” > where the usage is unambiguous. But keep in mind that you may not use any additionalparentheses or logical operators. Regards, Markus

1 0

Inkscape and AppData
by Richard Hughes 20 Sep '13

20 Sep '13

Hi all. I'm the developer for PackageKit and gnome-software. The community has already written an AppData file for Fedora, would you be interested to including it upstream? This will allow us to "feature" Inkscape on the front page in the future. See http://people.freedesktop.org/~hughsient/appdata/ for more details about AppStream and AppData. The file is here: https://raw.github.com/hughsie/fedora-appstream/master/appdata-extra/inksca… but checking and perhaps needs some more filling in. Thanks! RIchard.

4 7

Signals Help
by Arshdeep Singh 20 Sep '13

20 Sep '13

Hi all, I have a conceptual doubt. Suppose widget A houses widget B which hereby houses widget C. Can I associate same strings "changed", "updated" etc.. with individual signals of each widget A,B,C. Also, when I emit a "changed" signal will all three widgets execute their call backs ? Because A <-- B <--- C ( A <--- B means A contains B) and so C when emits "changed" should call callbacks of A and B ? -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

2 1

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