- Inkscape Devel - Inkscape Mailman

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

Text and Font Panel
by Thangalin 13 Aug '16

13 Aug '16

Hi, There are a number of issues with the Text and Font (Ctrl+Shift+T) panel, including: * Loading. Loading all system fonts can, in some cases, significantly reduce application launch time. * Memory. Loading fonts eats through memory. * Performance. It can be sluggish to scroll through hundreds of fonts. * Panel width. Long font names can cause the Text and Font panel (when docked) to take up half of the drawing area. The issues include: * https://bugs.launchpad.net/inkscape/+bug/1400273 * https://bugs.launchpad.net/inkscape/+bug/1612985 (https://launchpadlibrarian.net/278803244/wide-font-panel.png) * https://bugs.launchpad.net/inkscape/+bug/488247 * https://bugs.launchpad.net/inkscape/+bug/418726 * https://bugs.launchpad.net/inkscape/+bug/430328 * https://bugs.launchpad.net/inkscape/+bug/322113 I'd like to propose some cosmetic changes to the Text and Font pane that could, perhaps, resolve all of these issues. See attached (http://i.imgur.com/Jx9Suy2.png). 1. Remove the word "font" (the tab menu gives context). 2. Add horizontal scrollbars to account for long names. 3. Add a Preview list box that shows the fonts in the view port for the Family list box. This means that fonts don't have to be loaded until the Family list box view port displays them. Rather than load the fonts at startup, load them at runtime as needed. It's probably reasonable to apply a micro delay (say 50ms) so that scrolling through the Family list box is smooth and fonts are only loaded/rendered when the user stops scrolling for 50ms. Remove the preview from the Family list box. 4. Allow the user to provide custom preview text. Preview list box should present this text. Put a reasonable limit (e.g., 30 characters) on this. Perhaps this could be a select drop-down with various phrases that show all the letters (e.g., "Grumpy wizards...", "...lazy dog", "Cwm fjord...", "0123456789", plus a short history past user-defined phrases). 5. Allow the user to toggle the Preview list box. This could have a significant performance increase for people who don't need to preview all the fonts all the time. It could also save lots of memory. Additionally, it would free up screen real estate as the panel width would decrease by the Preview list box width. 6. Allow user to change font size and units. The size is shown as a drop-down in the mock-up, but the user should also be able to type in a specific size (e.g., 9.5) as per existing functionality. 7. Maybe allow the user to disable the scroll lock between the Family and Preview list box areas so that they can vary independently. Activating the lock automatically updates the Preview list box to reflect the Family list box view port. 8. Provide beefier handles to resize the pane. Resizing it should increase the height of the Family/Style/Preview list boxes, pushing the options (justification, size, space, etc.) down. Clicking on three tiny dots can be a daunting task for people with shaky hands... 9. Never disable the Set as Default / Apply buttons. If pressing the buttons won't do anything, then fail silently. Otherwise, always let the user click them and try to perform the appropriate action. Currently there's a bug where, in some cases, if the user changes the font size (but not the font), the Apply button remains disabled. Removing the code for disabling these buttons should simplify the source code and possibly force the developer to address the font size changing bug. Thoughts?

1 0