
On Wed, Feb 01, 2017 at 05:20:18PM -0500, Julian Rendell wrote:
Thanks for the warm welcome Bryce, and clear answers.
Good that you assume nothing; I’m mostly a user!
(Disclosure: I am starting a makerspace/education business and want to promote Inkscape to patrons. It’s trivial for Linux/Windows… but I suspect supporting brew/Macports might chew a lot of time :-) )
Extra: could the builds be signed so that they don’t raise security warnings?
If you mean can they be gpg signed like the source tarballs, then yes of course.
If you're talking about something more Mac-specific by the word 'signing', such as something relating to app-store registration or whatnot, then you'll need to elaborate. I've got no experience with how things are done on Mac.
Yes, it’s an Mac security thing. Mac’s give a warning before running “unsigned” apps. I’m only vaguely aware of what has to be done to build a package that doesn’t trigger this warning- I think being a registered Mac developer is required. At this point the end user can “approve” the app locally and run it anyway. It’s a “nice to have." This only affects non-Mac store apps (I assume all Mac store apps are signed.)
What's involved in becoming a registered Mac developer?
You're probably already aware of this, but we have plans in motion to migrate the Inkscape codebase to gitlab. This might influence your plans here. I'm guessing this will occur in the March timeframe, but we already have an Inkscape team set up on it and are using it for inkscape_web work to try it out. Would you be interested perhaps in hosting your development team work there within the Inkscape team account?
Not at all aware of this.
If the other interested parties are ok with using gitlab then let’s get it setup.
Let’s give them a couple of days to respond.
Ok, sounds good.
Another bit of data I'll mention, that again you probably are aware of but that might influence your planning, is that our earlier evaluation indicated the OS X packaging would need redone for supporting Gtk3, and indeed it was felt that native OS X packaging for Gtk3 would be significantly easier. We have already landed the Gtk3 changes for Inkscape's trunk, which will be released as 0.93, so I believe if someone wanted to start experimental work on native OS X packaging on top of trunk, the pre-requisites should be in place to permit that. The timeframe for the 0.93 release is uncertain, as always, but my personal hope is to see it released before the end of the year.
Vaguely aware of it. I got cmake to work, twiddled flags, rebuilt, and eventually got a local binary that ran using GTK3 native. It was sort of awful- lots of tearing and things not redrawing; sometimes tools couldn’t be clicked on. Then someone updated the brew file and I went back to using that, which appears to be GTK2 based. But there’s a very good chance I messed something up installing GTK3 via brew.
Having said that, I’d be happy to work with the gtk3/head, if it’s to support the goal of supporting future work. I can setup a VM for development/testing.
It depends of course on how you want to invest your energies and how urgent your needs are. That said, from the projects' perspective having Gtk3 OS X packaging ready for 0.93 is the more strategically important since it will be the longer term need. And to my knowledge no one is working on it at present, so it's a clear area where help is needed.
Bryce