- Inkscape Devel - Inkscape Mailman

Any progress on CMYK?
by John Culleton 02 Feb '17

02 Feb '17

My copy of the 4th edition of the Bah book says it is "under way." The absence is a pity because with the built-in perfect book layout facility Inkscape would be most useful in creating book covers. The ability to distort type faces makes for some interesting possibilities I recognize the size of the task of course. -- John Culleton Wexfordpress Book design and indexing.

2 1

Seeking Review: Inkscape Development for Users
by Martin Owens 01 Feb '17

01 Feb '17

Hi Everyone, Golden Ribbon (GR) has made this slick info graphic to explain and prompt more users to help with Inkscape development. http://grtuts.com/inkscape-development-builds/ He's asked me for advice on the details and I figure I'd throw it open to everyone. You can comment directly in the blog post if you like. Or here, since I know GR is subscribed here too. Also I think we might like to think about brining the planet back to life with some new blood. I wouldn't mind having non-coders on the planet, professionals perhaps. Or more than one if a planet is put into the website for example (they're fairly easy to write) Thoughts? Best Regards, Martin Owens

5 5

[RFC] Wiki replacement plan
by Bryce Harrington 31 Jan '17

31 Jan '17

I'd like to offer a proposal for a path forward here, merging ideas and concerns everyone's put in, particularly Maren's feedback on my initial proposal in the previous wiki thread. Apologies ahead of time for the length, as usual brevity escapes me. Wiki Replacement Plan ---------------------- #0 - No change to the current wiki until Inkscape's codebase is migrated to git. So, probably no change until March or so. Thus, people considering using the wiki for things right now, should proceed with doing those things. #1 - Application documentation and reference source files are moved to Inkscape's share directory in VCS. Extension references, output format details, tutorials, usage advice, and so on. This will be shipped with the application, and probably worth rendering in some web-viewable format as well. Nearly all of this will be worth translating. #2 - Strictly user-facing pages in the wiki are moved to the main website. High level project info, roadmaps, user-oriented FAQs, community resources, and so on. If a page requires advanced styling or layout functionality in our current mediawiki, that would be a strong indication it should be moved to our Django. This will obviously take time and effort but can be tackled bit by bit. Most of this is worth translating. Finalized release notes will become part of the releases app; this will support html and translations. #3 - Static coder-facing documentation should be moved to Inkscape's doc/ directory. This includes anything that documents implemented designs, protocols, and other assorted functionality. It also includes coder tutorials and guidelines. Generally materials that can be considered "finished" and worth keeping for reference value. This doesn't include unimplemented ideas/proposals, nor anything that is obsolete or that we're keeping simply for historical purposes. Little of this will be worth translating. #4 - Dynamic development pages are moved to the git*b wiki. This includes design mockups, development plans, todo lists, architectural brainstorming, infrastructure refactoring proposals and the like. A lot of the stuff currently registered as blueprints, that are adequately well fleshed out and that may be worth including in our official roadmap, should also move here. None of this should be translated. The release notes under development for the trunk codebase are drafted here in this wiki. Perhaps eventually we'll move editing to the releases app. This also includes organizational documentation for the Inkscape board, pages relating to fundraising, hackfest planning, and so on. #5 - Obsolete pages are left in the current wiki, but "mothballed" for historical reference. #6 - A "Community Wiki" will be established with open access for members of the wider Inkscape community, to use as a freeform collaborative editing space. There would not be rules about what can and can't go in here, but this is where folks would go to do collaborative brainstorming, flesh out raw ideas, and share random wishes and bits of information not ready or suitable for inclusion in any of the above. It should be easy to register for and easy to edit, but also robust against spam. All other pages not covered by 2-5 above, will end up here. As a general rule of thumb, if a page in the Community Wiki is important enough to be worth translating, or if we find ourselves linking to the page frequently, then that is a sign the page ought to be promoted and moved elsewhere. This could be an updated MediaWiki like we currently have, however I'd like to see thought given to alternative solutions, such as a Django wiki plugin that allows tighter integration with the website, or even using an externally maintained wiki service. It could also be a special Git*b project with really lax rules for committing. Whatever we pick, the important things are that it's widely available to all, easy to use, and very light on rules or imposed structure. #7 - Feature requests and wishlist changes, eventually will move into a future project management system on the website (I envision something that couples bug tracker style commenting with wiki like editing within a Blueprints-type tracking system). This is probably a few years out though so we'll need to keep using #4 devel wiki in the meantime. Let me know what you think, and please poke holes. If there are no red flags raised, we can proceed with this plan subsequent to our move to git. Thanks, Bryce

5 9

problems having only macports to install Inkscape on Mac
by brynn 31 Jan '17

31 Jan '17

Hi Friends, We have this message which has gone unsolved, in the User mailing list. https://sourceforge.net/p/inkscape/mailman/message/35630257/ I've seen this same problem posted 3 or 4 other times. They follow the instructions for installing using Macports. Everything seems to have worked without producing errors or other problems. But afterwards they can't find Inkscape. In one of them, I'm trying to help a newbie who posted on Inkscape Community. She has sought support from Macport support, and apparently they are either unable or unwilling to simplify the solution for a newbie. I'd like to know the solution for this, since it seems so common. Then I (or we) can help Mac users who have this problem. In my opinion, it reflects poorly on the project not to have a solution which newbies can use. Hopefully Kirk Slowe will be successful packaging a DMG version for 0.92 or 0.92.1. But meanwhile, can anyone tell me the solution for this? Thank you very much, brynn

1 0

Inkscape 0.92 via homebew on macOS
by Tim Sheridan 31 Jan '17

31 Jan '17

If you use homebrew on macOS, then you can get Inkscape 0.92 by running: brew install caskformula/caskformula/inkscape (For non homebrew people, here's a glossary: formula => package built from source, tap => repository, cask => package redistributing an upstream binary) This formula originates from the inkscape formula in the homebrew-gui tap. However, recently the homebrew-gui tap has been deprecated. In the case of Inkscape, the cask is considered the successor package. But since the inkscape cask is limited to official releases (or third party releases nominated by the Inkscape project), the cask will stay at 0.91. So for the time being, I'll be maintaining the inkscape formula in this tap. Any contributions/improvements are welcome: https://github.com/caskformula/homebrew-caskformula Cheers, Tim

5 8

Inkscape 0.92.x stable daily PPA
by Bryce Harrington 30 Jan '17

30 Jan '17

For testers on Ubuntu, I've created a new automated PPA that builds snapshots of the current stable branch, 0.92.x: https://code.launchpad.net/~inkscape.dev/+archive/ubuntu/stable-daily Note that while these snapshots are of the stable tree, the packages aren't official releases, so there is some chance of bugs, and things can change. This PPA is intended to make it more convenient for folks to test our stable tree and help us ensure the point releases are high quality. I've only tested the Trusty package, so ymmv on other ubuntu releases but I expect they should all work as well as the official point releases. Bryce

1 0

Git Rebasing
by Martin Owens 29 Jan '17

29 Jan '17

Hi Developers, Just a heads up. I rebased the inkscape-web git repository on GitLab to sort out problems with it's cherry picks. This took 2 hours of picking through the rebasing as some of it could be automated. So I had to manually merge about two hundred of the 1600 commits to get it working. Not sure if this will bite the inkscape git repository some time in the future. But being aware of the non-linear repository created by a migration from bzr. Best Regards, Martin Owens

5 13

Fw: Lack of mac installer
by brynn 29 Jan '17

29 Jan '17

I received the original message (at the bottom) through the Contact form on Inkscape Community. Forwarding along to the list. You can see I suggested to subscribe to the list. But as of now, he isn't a subscribed. I didn't know exactly what to say about the change to depending on Macports, so hopefully you all can be more helpful. brynn -----Original Message----- From: admin@...3472... Sent: Sunday, January 29, 2017 6:42 AM To: kirk@...3473... Subject: Re: Lack of mac installer Hi Kirk, Wow, that's a fantastic offer! You've actually reached a forum which is only temporarily the official Inkscape forum, while we are working on getting the new official forum working. And for some reason which I find odd, Inkscape developers don't use bb style forums. Since I'm not a Mac user, I haven't paid very close attention to why they switched to Macports. But judging by all the complaints we've had about people trying to use Macports, maybe it would be good to have the DMG version. You'll want to subscribe to the developer's mailing list (https://inkscape.org/en/community/mailing-lists/), which is where this kind of issue is discussed and handled. I could go ahead and forward this to the list, so the people who need to know will see it. You won't be able to post to the list, until you subscribe. But you'll get any replies. And you can follow any discussion which might happen after I forward this, in the archives. The link to the archives is right beside the link to subscribe, on the page above. Actually, developers are about to release 0.92.1, so this could be good timing! Thanks for your generous offer, and I'll send this right along to the people who can answer your questions. All best, brynn -----Original Message----- From: kirk@...3473... Sent: Saturday, January 28, 2017 5:40 AM To: admin@...3472... Subject: Lack of mac installer Contact Page Form for Inkscape Community Name: Kirk Email: kirk@...3473... IP: 209.131.239.35 Message: Do you lack someone to create a dmg installer of v .92? Is that why macports is being used? I'm a mac guy and so understand why so many people have issues with macports. I'm not an expert but would like to volunteer my services to get this version created into a .dmg installer.

2 1

0.92.1 plan
by Bryce Harrington 29 Jan '17

29 Jan '17

The 0.92.x stable branch is reopened for changes. Consider it as under feature freeze but not string freeze. Bugfixes are welcome to be added. Please continue to check with me before landing things, but for the next few weeks I expect to be in rubber stamp mode and approve most anything that looks sensible. We do need to be cautious about not introducing regressions at this point. Write good changelog messages explaining the fixes in good detail please. Translation updates (and entirely new translations) are fine to land directly, no need to check with me. There are already a handful on the branch already that unfortunately came in just after I had cut the tarball. Extension updates and new extensions are probably low enough regression risk that I'll try to be liberal in approving them. The ones we have to be cautious about are the highly used extensions, since we risk breaking people's workflow. A few specifics I'm aware of, that sound worth including: + Tutorials and other .svg files we ship have the dpi scaling issue, and need updated for 0.92.1 + suv mentioned an extension to provide users a workaround to some line spacing issues, iirc. + A mechanism to backup / reset prefs settings + Fixes to some strings that were found post-string freeze + A gpl3 widget needs removed (or relicensed) I'd like to avoid maintaining a bugs-needing-fixed list, but rather focus time more on patch review and testing. I figure the important thing is to get 0.92.1 out in a timely manner, and if there's still bugs needing attention we can always do a 0.92.2 some time later on. Proposed Timing: Mon Jan 2 Feature Freeze 0.92.1pre0 Mon Jan 23 Hard Freeze 0.92.1pre1 Mon Jan 30 String Freeze 0.92.1pre2 Mon Feb 6 Release Candidate 0.92.1 Fri Feb 10 Cut Release Mon Feb 13 Announcement I know we've not got a strong history of staying to schedule, but I'm going to try hard to hit these dates at least within a day or so. That means we'll have to be strict about string changes after String Freeze, and strict about any changes after the Release Candidate. This schedule allows the weekend of Feb 11-12 for prepping website changes, finalizing packages, and so on. Anything you can think of missing from this plan? Bryce

4 6

Setting extension parameter defaults from svg objects
by Trever L. Adams 27 Jan '17

27 Jan '17

I am working with an already existing extension. One of my frustrations is that it remembers the last use. The extension sets values on the svg path directly. Is there a way that the params defined in the .inx file can be loaded from those same values? Thank you. Trever

2 1

Downloads Downtime
by Martin Owens 26 Jan '17

26 Jan '17

Dear Developers, Last night at 3:22am GMT the newly fixed web server ran it's cron jobs that had not run since November. It ran the automatic updater script, which pulled in new additions to the website without migrating the database. The database table for resources was then lacking a new "owner" string field and requests to downloads failed with an Error 500. The issue was corrected with a complete database migration at 7:42am EST and the website is working within it's known parameters. Between the issue starting and the fix, there were 241 error emails sent from the web server for 44,183 actual 500 errors. (Emails are paced). Blocking 13,228 attempts to download inkscape for windows file, 6,295 attempts at an msi file and 15,937 attempts at the portable inkscape download. >From users themselves, there were 42 emails to the website administrator. 38 in English, 2 in French, 1 in Portuguese, 1 in Indonesian and 1 from Donald Duck. 40 apologetic emails were sent back to real addresses, and two emails not sent to fake reply addresses. Best regards, Martin Owens

1 0

Trunk build broken (test case involving document-rotation)
by Bryce Harrington 25 Jan '17

25 Jan '17

[==========] Running 4 tests from 1 test case. [----------] Global test environment set-up. [----------] 4 tests from AttributesTest [ RUN ] AttributesTest.SupportedKnown [ OK ] AttributesTest.SupportedKnown (2 ms) [ RUN ] AttributesTest.NameRoundTrip [ OK ] AttributesTest.NameRoundTrip (1 ms) [ RUN ] AttributesTest.ValuesAreKnown /<<BUILDDIR>>/inkscape-trunk-0.92.0+devel+15444+85~ubuntu16.10.1/testfiles/src/attributes-test.cpp:613: Failure Value of: ids[i] > 0 Actual: false Expected: true Attribute string with enum 59 {inkscape:document-rotation} not handled [ FAILED ] AttributesTest.ValuesAreKnown (4 ms) [ RUN ] AttributesTest.ValuesUnique [ OK ] AttributesTest.ValuesUnique (2 ms) [----------] 4 tests from AttributesTest (9 ms total) [----------] Global test environment tear-down [==========] 4 tests from 1 test case ran. (9 ms total) [ PASSED ] 3 tests. [ FAILED ] 1 test, listed below: [ FAILED ] AttributesTest.ValuesAreKnown 1 FAILED TEST 3/5 Test #2: color-profile-test ............... Passed 5.74 sec 4/5 Test #3: dir-util-test .................... Passed 5.73 sec Start 5: object-set-test 5/5 Test #5: object-set-test .................. Passed 0.31 sec 80% tests passed, 1 tests failed out of 5 Total Test time (real) = 6.06 sec The following tests FAILED: 1 - attributes-test (Failed) Errors while running CTest Makefile:130: recipe for target 'test' failed ----- Forwarded message from Launchpad Buildd System <noreply@...1881...> ----- Date: Wed, 25 Jan 2017 05:27:43 -0000 From: Launchpad Buildd System <noreply@...1881...> To: Bryce Harrington <bryce@...961...> Subject: [Build #11913969] amd64 build of inkscape-trunk 1:0.92.0+devel+15444+85~ubuntu16.10.1 in ubuntu yakkety RELEASE [~inkscape.dev/ubuntu/trunk] Reply-To: Launchpad Buildd System <noreply@...1881...> * Source Package: inkscape-trunk * Version: 1:0.92.0+devel+15444+85~ubuntu16.10.1 * Architecture: amd64 * Archive: ~inkscape.dev/ubuntu/trunk * Component: main * State: Failed to build * Duration: 45 minutes * Build Log: https://launchpad.net/~inkscape.dev/+archive/ubuntu/trunk/+build/11913969/+… * Builder: https://launchpad.net/builders/lgw01-42 * Source: not available If you want further information about this situation, feel free to contact a member of the Launchpad Buildd Administrators team. -- amd64 build of inkscape-trunk 1:0.92.0+devel+15444+85~ubuntu16.10.1 in ubuntu yakkety RELEASE https://launchpad.net/~inkscape.dev/+archive/ubuntu/trunk/+build/11913969 You are receiving this email because your team Inkscape Developers is the owner of this archive. ----- End forwarded message -----

2 2

Media Caching on Inkscape.org
by Martin Owens 25 Jan '17

25 Jan '17

Hi inkscapers, The inkscape website has been under stress recently. Higher load after the release mostly. But also a broken cron, failing logrotate, low disk space (in that order of knock on effect). I've fixed the cron, which fixes the logrotate and I've got a ticket out for increasing the disk space next Monday. The web server will be down for 30 minutes while I go through the process with OSUOSL. The load issue though was troubling me. Lots of media requests. I opened a ticket with Fastly, the very kind CDN service we use. They had a look at our logs and noticed that Fastly was asking if files had changed every 3 minutes. Which is a bit often. So I've set the expires to 30 days. This shouldn't effect any of the actual pages since it's just about the media / downloads. This is also one reason why uploads never use the same filename, appending -1 and etc to make them unique. So we shouldn't have an issue. But let me know if you spot anything odd or interesting. I'll keep monitoring. Best Regards, Martin Owens Website Administrator

1 0

Re: [Inkscape-devel] Google Summer of Code 2017 - Mentors?
by Krzysztof Kosiński 25 Jan '17

25 Jan '17

I can mentor too. On Jan 24, 2017 12:05, "Martin Owens" <doctormo@...400...> wrote: On Tue, 2017-01-24 at 10:35 -0800, Josh Andler wrote: > Hey All, > > The Org application period is currently open. We've had a couple > potential students already reach out. Given those two things, who is > willing and able to Mentor for our organization this year? > > I'm willing to Admin as usual, hence my bringing this up. I'm ready to do a spot of mentoring also. Thanks Josh! Martin, ------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

Google Summer of Code 2017 - Mentors?
by Josh Andler 24 Jan '17

24 Jan '17

Hey All, The Org application period is currently open. We've had a couple potential students already reach out. Given those two things, who is willing and able to Mentor for our organization this year? I'm willing to Admin as usual, hence my bringing this up. Cheers, Josh

3 2

Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
by C R 24 Jan '17

24 Jan '17

Sounds great to me! I'll read over what we have as well again this weekend and put some thought into the content and graphics, taking into account all suggestions made here. I think a bit of humour would be great to convey a friendly and fun atmosphere to welcome contributors while not being too cheesy. :) -C On 24 Jan 2017 6:03 a.m., "brynn" <brynn@...3133...> wrote: I think that's a brilliant idea. You're right that we have written bits > along these lines in the past, which could be extracted, dusted off, and polished to be more digestible to a more modern audience. You're right that there's probably a few different "types" of people so maybe a few different pages to message in different ways would make sense. I.e. one that talks to people who could get into coding work might focus on explaining branches and patch contributions, whereas another page might come from the angle of someone who isn't AT ALL interested in coding and instead just address good non-coding ways to contribute. Another one geared for translators, another maybe for evangelists, yet another specifically focused on usability testing. Or something like that. Would you like to take a shot at extracting the existing text and roughing it into a more useful shape? I think I could contribute verbage to the pages, or link in someone to help. Bryce __________________________________________________ Yeah sure, as long as we're waiting for OSUOSL, I have time to spare. I'll have to look in the FAQ to see what's left still there. Because now that I think of it, a lot of it has been brought to the Contribute page already, and some on the Promote page. https://inkscape.org/en/contribute/ https://inkscape.org/en/contribute/promote/ Should we split those sections up, and add more to them? I think what might be missing, to address this concern, is language that perhaps is more inviting (and maybe more warm and fuzzy?) as opposed to strictly informational. I know we had a report recently, where someone thought the info about helping with the website should be on the Contribute page, rather than Promote. I originally put it on Promote, because I was thinking that's what the website does, is promote Inkscape. Plus, it made a way to break into 2 pages evenly, while all on the same page, it's too long. Anyway, maybe there's a better way to organize all that? Ok, the only thing left in the FAQ is this: https://inkscape.org/en/learn/faq/#how-communicate-effective ly-throughout-inkscape-community-and-avoid-causing-flamewar which I deliberately left there, thinking it should probably be deleted, but not wanting to make that decision alone. I think we can definitely use that first paragraph. And maybe some other parts too? Since we have the CoC, we can probably lose the flamewar part. Hhmm....I'm thinking of an introduction to the Contribute page, which contains most of that info. Section title "So, You Want to Contribute to Inkscape? Here's how to get started" More warm and fuzzy, but maybe too corny? C R, jump in with comments too :-) All best, brynn PS - another thought - Maybe the CoC could have some language for bringing new people in without saying "patches welcome"? -----Original Message----- From: Bryce Harrington Sent: Sunday, January 22, 2017 7:51 PM To: brynn Cc: C R ; inkscape-devel Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug On Sun, Jan 22, 2017 at 08:50:49AM -0700, brynn wrote: > >"Patches welcome" has become a flippant and dismissive way to say, > >"well, fix it yourself". > > Most of my experience helping Inkscape users is in forums (approx 8 > years), as opposed to the mailing list (approx 2 or 3 years). I've > never seen this suggested in a flippant or dismissive way. > > I could see a webpage....or a section of a webpage, which has kind > of a pitch or invitation. Without looking, I don't remember > specifics, but I think parts of the faq (user faq on the website) > already do this. So it could be made into a page or section of a > page. Since people have all different kind of issues, we couldn't > provide the support info. But it could include generalized support > info, along with everything else I mentioned above. And then when > we find ourselves thinking "patches welcome", we could link to it, > rather than type it all out, every time. > > Or would that be too impersonal? If the Inkscape project is known > for being a friendly community (as someone said earlier) it could be > written in sort of a warm, fuzzy way.....if that would help? Just a > thought :-) > I think that's a brilliant idea. You're right that we have written bits along these lines in the past, which could be extracted, dusted off, and polished to be more digestible to a more modern audience. You're right that there's probably a few different "types" of people so maybe a few different pages to message in different ways would make sense. I.e. one that talks to people who could get into coding work might focus on explaining branches and patch contributions, whereas another page might come from the angle of someone who isn't AT ALL interested in coding and instead just address good non-coding ways to contribute. Another one geared for translators, another maybe for evangelists, yet another specifically focused on usability testing. Or something like that. Would you like to take a shot at extracting the existing text and roughing it into a more useful shape? I think I could contribute verbage to the pages, or link in someone to help. Bryce

1 0

Re: [Inkscape-devel] Inkscape 0.92 Portable version ?
by Gord Caswell 20 Jan '17

20 Jan '17

On 18 January 2017 at 16:47, Bryce Harrington <bryce@...961...> wrote: > > > Between this, and Eduard's request for help, I'm building it right now. > > Great, thanks for tending to it. > We've built & digitally signed the portable package, ready for upload: http://download2.portableapps.com/portableapps/inkscapeportable/InkscapePor… SHA1: 9f949bf3b77f4d529673ff43d597e7827b3b327b Gord PortableApps.com

1 0

Move Wiki to Git*b
by Martin Owens 20 Jan '17

20 Jan '17

Dear developers and wiki enthusiasts, Our current wiki hosted on wiki.inkscape.org is doing ok, but is running on an old machine that the hosting provider OSUOSL would like to retire if at all possible. Since we are moving to Git*b, this is an opportunity to also move the wiki to that service. This decreases our system-admin burden and the resources we ask from osuosl. It would also say that our wiki is more of a developer/contributor focused effort, leaving user content to the website. I expect things like hackfest planning and other plumbing to continue to use a wiki system. The process of moving it would entail waiting until our code is on git*b and then convert each of the existing pages from MediaWiki syntax to Markdown syntax. A script such as this https://bitbucket.org/wikier/mw2md could be used, but testing would be needed to see what kind of output we got. For all people involved in using and editing the wiki, I'd like your thoughts on how we should manage our wiki service going forwards. Thank you all. Best Regards, Martin Owens Website Administrator Hat

9 18

Mesh Gradients Polyfill
by Jayesh Salvi 19 Jan '17

19 Jan '17

Hello, I've implemented Javascript polyfill for SVG files that have mesh gradients in them, so that they can be rendered in browsers successfully. I ported the mesh gradient rendering code from Cairo to javascript in order to do so. The code and instructions on how to use it are available at https://github.com/zectorio/mesh-gradient-js This code could be run on SVG files created in inkscape and make them renderable in browser. Please take a look. I'm looking forward to your feedback. (There are still some rough edges, as this is still a proof-of-concept thing. But the code works for examples in samples directory) Thanks, -- Jayesh

4 4

Inkscape 0.92 Portable version ?
by Marc Jeanmougin 19 Jan '17

19 Jan '17

Hi all, For previous releases, we used to ship a portable version with portableapps, but there does not seem to be such a version for 0.92. Is it an oversight? I don't know who took care of those in the past. If no one is planning to do it, we had a portableapps developer on #inkscape-devel offering to build it Thanks, -- Marc

6 7

Todays trunk : some objects lacking after reloading files
by ivan louette 18 Jan '17

18 Jan '17

Hi That's one of the the most spectacular regression I never saw in trunk : today after reloading some of my files created with yesterdays trunk version some rectangles and even some text blocks are lacking ! Of course I didn't save these files again with the new version ;-) I work with Trunk on Kubuntu 14.04 ivan

1 0

extensions handling user-units and query-all in 0.92
by Pelle Nilsson 17 Jan '17

17 Jan '17

Hi, I just joined this list because after asking about extensions and handling of dpi etc in 0.92 on the Inkscape forums and on Launchpad I got several recommendations to bring it up with you developers here instead. (I should probably have lurked here a long time to keep updated about changes happening to Inkscape before major releases. My extensions have been online since 2008.) Either I am confused about how user-units are supposed to work (and my extension is even more confused) or there is a bug in Inkscape (possibly in inkex.py?). http://www.inkscapeforum.com/viewtopic.php?f=29&t=31525 https://answers.launchpad.net/inkscape/+question/431543 https://bugs.launchpad.net/inkscape/+bug/1654907 https://www.boardgamegeek.com/thread/299033/inkscape-extensions-boardgame-d… For testing I created a rectangle in 0.91, a 1x1-inch square at -3 inches x (I only bother with the x-coordinates in the following). Inkscape UI reports that it is at -270px. If I transform it by translate(270) it ends up at x=0, as expected. It also works in 0.92. Inkscape UI now reports -288px, but still a translate(270) works as expected, so Inkscape internally correctly understands that the user-unit in this document is 1/90 inches (I confirmed by calculating svg width and viewBox that it is indeed that). But the countersheetsextension running in 0.92 on a document from 0.91 gets confused and translates things too far. If the document was created in 0.92 it works (user-units for an A4 for instance being 1mm, and it translates properly). The extension works by reading coordinates using --query-all, and I had to make a small change to even support 0.92-documents in 0.92 (see https://github.com/lifelike/countersheetsextension/commit/aa454f5117fbd457d…), but this fails on a document created in 0.91. The calculations, done using unittouu, ends up with values as if the user-units were 1/96 inches, so in the example above the extension outputs translate(288), and the rectangle is translated 18 units too far to the right. So what I think is going on is that inkex.unittouu fails to properly calculate coordinates in user-units if they do not match some of the pre-defined values, but Inkscape internally does a better job? Trying to figure out a work-around. Perhaps write my own function to calculate user-units instead of using unittouu, or somehow detecting that the document was created using 0.91 (although I guess it will still fail for documents with any other possible user-unit lengths that might exist out there?)? Or maybe I just use the API in inkex the wrong way and what I try to do should already be possible? -- /Pelle

1 0

Independente Inkscape Survey Results
by Victor Westmann 16 Jan '17

16 Jan '17

I said previously that I would publish the results on January 31st but I believe there's no need to wait that much since the answers in the survey are the same for a couple of weeks now. So, attached, is the result of the survey. If anyone needs access anything else let me know. A nice insight we can have reading the survey is that a big part of the Inkscape Community is willing to contribute to the software with $$ to foster a number of different developments. Which is great! ;-) Happy new year! --Victor Westmann

3 4

Getting to git
by Bryce Harrington 14 Jan '17

14 Jan '17

"The time has come," the Walrus said, "To talk of many things: Of shoes — and ships — and sealing-wax— Of cabbages — and kings — And why the sea is boiling hot— And whether Inkscape should switch to gitlab or github or entirely other things." At Hackfest 2015 we broached the topic of moving to git, and while recognizing it as probably inevitable, decided to take care of a few other things like switching to cmake first, and getting a release out the door, and getting going with Gtk3 and C++-11. That release is out the door, cmake is done, Gtk3 is landed in trunk, C++-11 work is under way, and so I think it's time we start on tackling git. When we last visited this discussion, there was a consensus that yes we should move to git, and that rather than self-hosting a plain git repo (ala freedesktop), we would be better to look at an integrated platform like github or gitlab. But there was not a consensus as to which of those two to pick. So the task at hand is to discuss and deliberate the two and decide which should be our focus. Both have interesting pros and cons, and I don't think the decision is clear cut. Where should we go? In github's favor is that it holds the greater mindshare. Where we to go with it we'd potentially tap into a larger community of developers, which potentially could translate into a greater level of new participation in the project. github also seems like it's received a greater amount of polish and has some feature advantages (github's CI was seen as a huge pro last time we looked). gitlab is an up-and-comer and is actively acquiring analogous features to github. A big pro for us is that gitlab is FOSS whereas gitlab is free but proprietary. With gitlab we'd also hold the option of self-hosting, which might not matter or might be a huge advantage, it's hard to say. Both services provide broadly similar functionality and user experiences. The differences between them will be small compared with the differences we'll be facing moving from bzr+launchpad. Also, migration from github to gitlab or vice versa if we change our minds doesn't look like it'd be all that difficult. Those may be the best two options but they're not the only ones we have. There's other services, and of course git can be used serverside all on its own purely as commandline, or with cgit to provide a minimal web service. -- faqs ------------------------------------------------------------------- Why the need to move from bzr? One of the reasons why we switched from svn to bzr rather than git was because it was easier to learn; these days so many people know git and don't know bzr (and probably don't care to learn bzr) that this isn't quite such an advantage any more. git is also more actively maintained than bzr, and has a far bigger ecosystem of tutorials, tools and services. We also liked the integration between bzr and the LP bug tracker -- we'll lose this, although github/gitlab provide different integration opportunities that might compensate a bit. What services would we move? What we've discussed in the past is to keep the migration limited to VCS, branch management, and code review. The issue tracking in github/gitlab is quite different from what we've grown accustomed to in LP so changing that might be too much disruption. bzr->git is the main thing we're concerned with; transition of other services can be handled on a case by case basis. How would we undertake the transition? suv made a good point today that migration of smaller codebases first can be helpful so that the learning curve can be digested in pieces rather than in one big go. So perhaps we should begin by moving some of our more peripheral bzr repos, then maybe things like the website and then 2geom, and then do inkscape last. What about people who don't yet know git? I suspect a lot of us either already know git or have been working on learning it, that this isn't an issue. However, this transition is important enough I'd be willing to propose to the board that we fund book purchases and/or other forms of training for members that might need it. When would the transition be done? We've done some initial experimentation already. I would propose as soon as we have a strong consensus for github or gitlab that we proceed with moving the board's repository, inkscape-docs, and any other small / lesser-used repositories still relevant to Inkscape. Then second in perhaps a few months migrate inkscape-web and 2geom over. Once those are complete then migrate the inkscape repository itself over, with the goal of having the migration done. I'd like to see the transition completed prior to when we start getting heavily into the 0.93 release. Let me know your thoughts, and help us drive towards a consensus for github or gitlab. Thanks, Bryce

12 28

Requesting wiki editing powers
by tiwake walter 14 Jan '17

14 Jan '17

Because bryce said so. Also because I'd like to actually start helping out one of my favorite open source projects. Cheers tiwake

3 2