On 02/05/2018 11:52 AM, Maren Hachmann wrote:
I know there has been talk about separating extensions out into their own packages - but I got the impression that's more or less a long term solution, for which we lack volunteers... and not a solution that will help with 0.92.3, or probably even 0.93.
(or would anyone be interested in separating extensions out?)
This is my goal long term for the snap. The problem is that the snap format doesn't have everything we need to do this today. I've been requesting the features we need.
- There was talk about having them in a separate git repository,
comparable to ... atom editor plugins, or pelican website generator plugins, for example, and having them managed by a different set of developers. That was what I meant here. Sorry, I've been a bit vague.
Sorry, yes, I think that'd be good too. Somewhat orthogonal though as they could be a separate repository and still in the main Inkscape package. Also vice-versa. I imagine that for anything we have as a download (i.e. a Windows installer) we'll want to include a bunch of extensions. The only place that I can imagine separating them being useful is distributing through stores that have a prompt for other downloadable content.
For me, there are two reasons to do this. One so that we can make snap not have to include everything for every extension. The second is so that extension developers can upload and manage their own extensions. And, if they choose, charge money for them.
- They already can do that now, I think? At least I've seen separate deb
packages for extensions. I suspect it's not currently possible with snap to save stuff in the directories of another snap (i.e. move the extensions into Inkscape's extensions directory), is that what you mean?
Snaps can actually share directories, the problem is executing the extension. There's no way currently for a snap to execute another snap. For debs there's no real security besides file permissions, so things work fine there.
I would argue that extension developers could make debs, but they can't easily distribute them. Getting into the trusted Debian archives for their OS is difficult, and not practical. Things like PPAs are such a large security risk I don't consider them a practical solution. They're fine for groups of folks working together who trust each other, but they require an impractical amount of trust in every uploader to that PPA for them to be useful for general users.
Would a short term fix via error message be okay, until something like that happens?
The extensions have a dependency checking mechanism already, where in it can look for binaries. That could probably be extended to look for Python modules as well. I'm not sure how one writes C code to look for a Python module, but I think that's probably the long term answer. Then we can hide those that won't work like we do for when binaries are missing.
- I find that hiding already is problematic, it's not helping people
find the things they need. I often see people wonder why they don't have extension xyz, which they have seen in some video.
It would make more sense if there were an automatic message at the very first start of Inkscape, or some 'module' overview, as there is for other programs. There it tells you 'If you want optional functionality x to work, you need to have abc. Get abc ->'.
People will look for hidden gcodetools on the web (although they already have a compatible version), and go and install them from somewhere else, and wonder why they still don't work. They do *not* usually look into the extension-errors.log. Most don't even know where their preferences file is, or where to put new extensions, let alone are able to dig into error logs to find out what is going wrong. (Those who *do* look in there are usually worried that important things are missing, because they don't really understand it).
Hiding is fine (for me) if a user *knows* that it's hidden, and is okay with it, because he/she doesn't need it. Hiding without informing people about what's happening is not nice, in my opinion.
Please don't hide the gcodetools :-( - I'd like to just add the error message (no new strings, promise!)
I wouldn't mind making extensions optional (even though I find that many of them supply something that could be considered core functionality), or what I'd like even better would be to have some functionality inside Inkscape that lets you choose which ones you want to install, and to have a kind of 'shop' for them. But currently I'm a bit worried about the security implications that would have, and about the amount of maintenance work that it would require. It's more of a dream, I guess, but one that came up in various discussions.
Yes, I don't think us implementing an App store makes sense. That's the domain of OS vendors, and they've all done it already for us. They provide means for doing DLC for their OS, we should use those mechanisms. But, I think it makes sense to integrate with the means they had in a way that provides a positive experience.
I understand your concern with hiding functionality. The problem becomes: "I know I don't have numpy, stop filling up my menus with stuff I can't use." I'd agree that we need to provide a way to discover why things aren't starting up as expected better, and a hidden file isn't a great solution. I worry about going down the route of providing installation instructions because of the complexity of how everything is configured (a config option of Mint is what started this discussion!). And also things like "install numpy" is super technical. I don't want to say there is no solution, just point out some of the landmines on the path. We can do better, but I don't think we can entirely work around every distributor's choice without reinventing packaging.
Ted