- Inkscape Devel - Inkscape Mailman

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

Mac Video
by Jabier Arraiza 12 Jan '17

12 Jan '17

I just see, not sure if is know yet in the mailing list so share. Install Inkscape 0.92 on Mac OS with Homebrew (Latest) https://www.youtube.com/watch?v=xi5FD2LZZlY Cheers, Jabier.

1 0

Re: [Inkscape-devel] inkscape not building on zesty (17.04)
by Marc Jeanmougin 12 Jan '17

12 Jan '17

The relevant part of the log seems to be in the detection of gmock/gtest: _______________________________________________________________________ CMake Error at /usr/src/googletest/googletest/cmake/internal_utils.cmake:149 (add_library): add_library cannot create target "gmock" because another target with the same name already exists. The existing target is a static library created in source directory "/usr/src/googletest/googlemock". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): /usr/src/googletest/googletest/cmake/internal_utils.cmake:172 (cxx_library_with_type) /usr/src/gmock/CMakeLists.txt:84 (cxx_library) CMake Error at /usr/src/googletest/googletest/cmake/internal_utils.cmake:149 (add_library): add_library cannot create target "gmock_main" because another target with the same name already exists. The existing target is a static library created in source directory "/usr/src/googletest/googlemock". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): /usr/src/googletest/googletest/cmake/internal_utils.cmake:172 (cxx_library_with_type) /usr/src/gmock/CMakeLists.txt:89 (cxx_library) CMake Error at /usr/src/gmock/CMakeLists.txt:106 (install): install TARGETS given target "gmock" which does not exist in this directory. _______________________________________________________________________ Anyone has an idea how to fix this? -- Mc On 01/05/2017 11:11 PM, Launchpad Buildd System wrote: > > * Source Package: inkscape-trunk > * Version: 1:0.91.0+devel+15392+77~ubuntu17.04.1 > * Architecture: i386 > * Archive: ~inkscape.dev/ubuntu/trunk > * Component: main > * State: Failed to build > * Duration: 4 minutes > * Build Log: https://launchpad.net/~inkscape.dev/+archive/ubuntu/trunk/+build/11820680/+… > * Builder: https://launchpad.net/builders/lcy01-10 > * Source: not available > > > > If you want further information about this situation, feel free to > contact a member of the Launchpad Buildd Administrators team. >

2 4

Retrospective on 0.92 release
by Bryce Harrington 11 Jan '17

11 Jan '17

With 0.92.0 now in the rear-view mirror (amazingly!) it's a good time to look at places we could improve. Overall I think it went quite well. Switching build systems was a big change, and getting two year's worth of feature work stabilized is quite an achievement. Based on the feedback I'm seeing, it looks like we made a very good choice to retire our OSX packaging. I admit I was a little worried, but suv's judgment was 100% right, and as anticipated our deliberately *not* providing it is stimulating others to step in and fill the void. With 0.93 on Gtk3 it sounds like we'll have opportunities for even better OSX packages. Release management often is a tough trade-off between staying on schedule vs. delaying to allow pulling in last minute improvements. We did a fair bit of the latter, which looks like it is paying off nicely, but it did result in a quite long release cycle. I feel bad at having to say 'no' so much these last few weeks, I hope no hard feelings! But I suspect to achieve faster releases we're going to need to be more rigorous here. I would love to hear good ideas on how we could achieve that. Part of the delay was that the CMake conversion took rather longer than I had anticipated. I suppose that's the nature of volunteer projects, and is going to hold true for most big changes we need to undertake. Something we'll need to keep in mind when updating the roadmap. All that said, cmake does seem to be working out for the most part. I figure we'll need to revisit this again later (I'm starting to see some strong buzz about a build system called Meson), but should stick with cmake for the time being. We've got other big infrastructural changes pending which now need are full attention. Another big part of the delay was blocker bugs. I found this very hard to get my hands around; the issues are legitimately troublesome problems that should be resolved, but finding people able and available to work on them was tough. Unfortunately bugs are inevitable, and I worry the shift to Gtk3, C++11, and so on are destined to give rise to more. Does anyone have ideas on how we can handle things better so there are fewer blockers? Or ways to get the blockers resolved more quickly? Compared with the above two issues, the actual technical mechanics of rolling out a release are trivial, however there is significant room for improvement. Compared with other projects I do release management for, Inkscape's process is a bit too manual and has a number of extraneous steps. There are some opportunities for automation once we move to git, and simply dropping autotools/btool/etc. will eliminate having to manually edit a bunch of different files to set version numbers. In the future where there are files that require setting version numbers or whatnot, instead of adding manual steps to the release process, what I want people to do is add a configure_file() function call to our 'dist' logic that substitutes the new release version number. (I'm looking at you, .snapcraft.yml.) By now, we've done so many releases we have the release process down to a bit of a science, and we have ample checklists and todo lists. We know quite precisely what needs to be done and when. But where we ran ran into trouble was getting those tasks assigned out and completed on schedule. Thankfully, everything ended up getting done - kudos to everyone that stepped up and pitched in! But far too often they got done only after deadlines had passed; in some cases this caused schedule targets to get postponed, in other cases it caused impacts elsewhere such as translation. Mainly I blame myself - ultimately these are all failures in performing good release management. But some how or other we need to tighten all of this up if we are going to get releases out in a more timely fashion. Does anyone have suggestions or observations that could help us improve this? Finally let me say, "Great work!" Because at the end of the day we've done it - put out a solid release with some awesome features and a good deal of attention to QA. A common theme I'm seeing in comments is the huge positive impact Inkscape has made in people's lives and careers, and the 0.92 release you've created is going to enable a lot of people to do some really great things. Bryce

6 9

Re: [Inkscape-devel] Getting to git
by Bryce Harrington 11 Jan '17

11 Jan '17

----- Forwarded message from Will Entriken <fulldecent@...400...> ----- Date: Mon, 9 Jan 2017 22:04:20 -0500 From: Will Entriken <fulldecent@...400...> To: Bryce Harrington <bryce@...961...> Subject: Re: [Inkscape-devel] Getting to git] Bryce, Thanks for keeping me in the loop. I am very glad to hear about this update. And I fully expect much more participation in the project as soon as we open this floodgate. With a good amount of focus and direction, we should be able to get to 1.0.0 quickly. Here's my two cents on the GitLab / GitHub choice. GitHub is my default choice because it is the most popular and it works well enough. The largest project I contribute to there is https://github.com/chartjs/Chart.js and GitHub has no pain points in dealing with that project. I am more than happy to pick indie/non-popular choices if they are better. And if attracting developers and casual contributions is the goal then I do not think GitLab is better. More thorough discussion: * Top 10 projects of all time on GitLab: https://gitlab.com/explore/projects/starred * Top 10 projects this week on GitHub: https://github.com/trending?since=weekly * Random projects I started: https://github.com/fulldecent?language=&page=2&q=&tab=repositories&type=sou… Projects got more exposure (measured in stars) this week on GitHub than the whole history of GitLab. And my random pet projects (which are way less notable than Inkscape) would rank displace the #1, #2 and #6 projects on GitLab. Therefore I think Inkscape would be a big fish in a small pond there. Please feel free to copy this to the mailing list. Thank you, Will William Entriken 267-738-4201 On Fri, Jan 6, 2017 at 2:32 PM, Bryce Harrington <bryce@...961...> wrote: > Hi fulldecent, > > I know you've been very active in maintaining the Inkscape mirror on > github. You'll be pleased to hear the project is finally getting around > to its git migration planning. > > We're debating gitlab vs. github as our way forward, and while we're > still pretty early in discussion currently consensus appears to be > favoring gitlab. I'd like to make sure we loop you in (and any others > you've worked with on the github mirror) to make sure we have plenty of > input and information before reaching any decisions. > > Feel free to either chime in on the mailing list with your thoughts, or > just reply to me and I'll pass them along. > > Thanks, > Bryce > > ----- Forwarded message from Bryce Harrington <bryce@...961...> ----- > > Date: Fri, 6 Jan 2017 11:21:28 -0800 > From: Bryce Harrington <bryce@...961...> > To: Ted Gould <ted@...11...> > Cc: inkscape-devel(a)lists.sourceforge.net > Subject: Re: [Inkscape-devel] Getting to git > > On Fri, Jan 06, 2017 at 08:56:50AM -0600, Ted Gould wrote: >> I think where this mindshare comes into play is less with drive-by >> contributions as much as integrations with other services. There are a >> lot of cool tools built that "just work" with Github. Some only support >> that as a backend (even though they probably just grab git and work on >> it, they just don't have an option in the UI) What I'm not sure about >> is whether we'd end up using any of those services anyway. > > True, good points. And yeah, most of the services I actually have in > mind for us just require git, so should work equally well regardless of > what we pick. > > I've used both gitlab and github for medium-sized projects, and found > them both to be usable and performant. Inkscape is larger and more > complex, but so far I haven't seen any reason that either of those > options wouldn't do the basic job as well as the other. > >> > 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. >> >> Since the last time we've discussed it LP's Git features have matured a >> lot. I don't think that they're on par with Github/Gitlab yet, but we >> should probably put into consideration just moving to Git and sticking >> with LP, as it might be a simpler transition. > > You're right it should be included as an option. If nothing else it has > familiarity and inertia to change working in its favor. I'm not sure > how compelling a case can be made for it beyond that though. > > A large chunk of our transition pain will be developers adapting to git, > and we'll have that regardless of any of the options. The other chunk > is the web interface and I suppose there's some advantage with Launchpad > of sticking with the familiar. > > However, Launchpad has remained understaffed for years, and > unfortunately it really shows. The chances of reaching parity with > github/gitlab seem slim to none. And once their development attention > moves on to the next feature development effort, ongoing maintenance of > the service is going to become an issue, as it already has in so many > other places. > > Like gitlab, launchpad is open source. I've contributed LP code > myself. I don't know if we're likely to invest development energy here, > but both gitlab and LP seem on the same level here. gitlab seems to > have a more active development community though. > >> > Let me know your thoughts, and help us drive towards a consensus for >> > github or gitlab. >> >> For me, right now, my feelings are towards Gitlab. I think that we >> should stick with a FOSS solution overall and Github doesn't have >> enough advantages to override that. > > There was a ticket on our github account with people pushing for github > adoption. I'll touch base with them to gather their input, but at this > point I agree with you it seems gitlab is looking the better option for > Inkscape. > > Bryce > > ------------------------------------------------------------------------------ > 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 > > ----- End forwarded message ----- ----- End forwarded message -----

5 5