- Inkscape Devel - Inkscape Mailman

The Website is Down
by Shlomi Fish 29 Aug '16

29 Aug '16

Hi all, as reported on Freenode, https://inkscape.org/en/ gives a "502 Bad Gateway" error. Please look into fixing it. Regards, Shlomi -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ “Talk Like a Pirate Day” is the only day of the year when Chuck Norris only talks like a pirate, and does not actually act like one. — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ Please reply to list if it's a mailing list post

4 3

Doc scaling compatibility issue (Bug 1389723)
by Bryce Harrington 26 Aug '16

26 Aug '16

What do you think we should do about the release-critical DPI bug? We need a decision on a course of action. One of the changes we're bringing in this release is changing the definition of px from 90 dpi to 96 dpi, but a consequence of this is that documents created in 0.91 or earlier will become mis-scaled if used in 0.92. This is tracked in the following bug report: https://bugs.launchpad.net/inkscape/+bug/1389723 This is a release-critical bug, the sort that is likely to become a thorn in our side in the near to mid term as users start running into it more and more. Longer term it will diminish as our users move to newer versions, but I imagine it'll take multiple years before it goes away completely. I don't think we should consider reverting the change; it was introduced pretty early on this development cycle so backing it out could cause secondary bugs to crop up. Also, it's a change that has to be done, so if we don't do it this release we'll have to go through all the trouble again next release anyway. One proposed approach is to detect the affected files on load and display a warning with a recommendation to convert the file manually. Javier has posted a conversion tool that could be made use of; it's received a fair bit of testing but there may be some remaining corner cases to sort out; on the plus side with it being a discrete utility fixes could be rolled out for it without needing full Inkscape releases. The other proposed approach would be for Inkscape to internally convert files, so that no warning is needed. In theory this would provide a better user experience, but is going to require a lot more developer effort and thorough testing. I'm doubtful that all of this can be done adequately within the timeframe we're looking at for the release. Both approaches also require a mechanism to detect affected files, which sounds like it may be the tricky part here, as our SVG documents haven't had versioning information we could rely on for this case. Do you have thoughts on other ways to address this issue? Do you have a strong opinion on whether for this release we should use the expedient approach or else postpone the release until the more user-friendly approach can be developed? Or should we reconsider a revert of the DPI switch so we can get the release out and re-enable it post-release in hopes the issues can be worked out? Bryce

8 18

GitLab
by Martin Owens 26 Aug '16

26 Aug '16

Hi Developers, I've just been looking over GitLab, since they've put together a new issues board feature and it's in the open source version of their code, could we have a look and see if it's suitable for our needs? We'd need to check the CI build system is what we need My reasoning is that I have great misgivings about github, proprietary, large almost monopoly, project authority issues. If we can avoid having our code go there, I really think we should try hard not to go that route unless all other avenues are exhausted. Best Regards, Martin Owens

2 1

InkJar support
by Alex Valavanis 24 Aug '16

24 Aug '16

Hi All, Is there still any sense in keeping our support for SVG JAR files? As I understand it, this is an obsolete StarOffice file archive format that has since been removed from LibreOffice/OpenOffice. In fact, as far as I can tell Inkscape itself does not support these archives... only Inkview does. We no longer even provide an explicit option in our build system to support InkJar. Is it OK for me to go ahead and remove support, or does anyone know of a reason we still need this? Best wishes, Alex

4 5

Modeless Extension‏
by A B 24 Aug '16

24 Aug '16

Hi guys, I'm quite new with Inkscape so forgive me if the question is trivial.I'm developing an extension using Tkinter,it works well but the dialog is modal and I cannot do anything else with Inkscape while the extension is open. Is there a way to avoid this problem?Thanks a lot.

2 3

Rendering regressions in 0.92
by Bryce Harrington 24 Aug '16

24 Aug '16

Following up on the revert of the Gtk3 canvas refactoring to resolve the performance regression, it looks like this may have caused a few side effects: Canvas drawing errors: https://bugs.launchpad.net/inkscape/+bug/1608152 Crash on file open: https://bugs.launchpad.net/inkscape/+bug/1607698 Crash resizing application windows: https://bugs.launchpad.net/inkscape/+bug/1608216 Unfortunately these are all deemed blockers. :-/ Anyone have ideas on what might be the problem on these? Any chance there are fixes in trunk which need ported? Bryce

4 6

--query-all command line option
by Jordan Henderson 23 Aug '16

23 Aug '16

Hello, i am new to the source code, although I have worked with C++ before. I am trying to understand why --query-all does not return all objects that show a visible box when the SVG document is viewed using Inkscape. Specifically, a flowRoot will have a box for it when that element is clicked on in the XML editor, showing an x,y,w,h but it does not appear in the output from a --query-all. thank you for your time and patience, Jordan -- Jordan Henderson

1 0

C++11 Best Practices
by Tavmjong Bah 18 Aug '16

18 Aug '16

Hi all, Now that we can use C++11 in trunk (yeah!), what are the best practices? Are there parts of C++11 we still want to avoid? I started to think about this as I noticed in the code some places with perhaps over aggressive use of 'auto'. It seems to me that 'auto' should be reserved to places where it replaces a long, already unreadable iterator type. But it should not be used to replace simple types as this reduces the readability of the code, especially to someone not familiar with the code. For example, I don't see any benefit of replacing: GtkWidget* mywidget = someFunction(); by auto* mywidget = someFunction() Tav

5 5

Bugs, ,bugs, and more bugs: PVS Studio
by Tavmjong Bah 17 Aug '16

17 Aug '16

Hi, Alexandre Prokoudine has pointed out to me an interesting (embarrassing?) article about our code base. Have a look at: http://www.viva64.com/en/b/0419/ Tav

5 8

Bugs, ,bugs, and more bugs: PVS Studio
by Michael Soegtrop 16 Aug '16

16 Aug '16

Dear Inkscape Developers, I would be careful with the this!=NULL statement for bool SPLPEItem::performPathEffect as far as I can tell, this is not a virtual function, and there is no reason why the this pointer of a non virtual function should not be NULL. One can call a non virtual member function on a NULL pointer. Not very nice, but some people put such checks into the code as extra safety check on purpose and some even use tricks like calling a function on NULL pointers on purpose, e.g. for saving a lot of checks when the function is called. Best regards, Michael

1 0