Note that this is really an abrupt change that's going to break a lot
of automation, hence I think it'd be highly advisable to maintain this
command-line "API" compatibility throughout 1.x line, even if it would
be, for instance, accompanied with a deprecation warning if that's
indeed a desired direction.
Thanks for considering!
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Also note that keeping --file=foo.png where mere foo.png would work
alone could be caused with a not too clear (option string may be excluded) wording in the original help screen.
Hmm, --export-png no longer works, either, thought this was all to it.
Now, any (SW build system) automations relying on Inkscape to distill
curves into pixels are in a pretty precarious situation.
Is it really intended that these would need to "smartly" conditionalize
(i.e., complexity growth) on the Inkscape version happening to be in the
environment?
I am just not sure if this is a bug or if this functionality of the application that was removed intentionally.
Maybe @doctormo, @Moini, or @ede123 would be able to clarify this a bit better.
My info:
Operating System: Windows 10 Home
Operating System Version: Version 1903 (OS Build 18362.476)
Inkscape Version: 1.0beta 2
@poki you also forgot to mention valuable information for us (Operating system (name and version) and inkscape version as well). Thank you.
you also forgot to mention valuable information for us
(Operating > system (name and version) and inkscape version as well).
I did not ... all provided in the initial description.
Nonetheless, @kgaillot noticed that there was another "inconsistency"
(intentionally quoted for a paradox we shall see later) in how the
respective surrogate shall look like between said beta and rc1.
This really verges on very tough maintainability for (said) build
systems that aim to be "work equally everywhere", unless some more
complexity (equals costs) are put into that. I think some more
considerations around these "batch production" use cases might be
appropriate.
Respective merge request, justified with "consistency" (which
apparently means everything but the long term usability consistency):
inkscape!1433 (merged)
The problem with the lack of compatibility is that now I need to make every script that uses inkscape know about both interfaces for the foreseeable future. So since you weren't willing to do that in inkscape itself, everyone else needs to do it again and again. Changing an interface that is used in build scripts is a terrible thing to do to people, and doing it in such a way that we can simply fix said scripts adds insult to injury.
For now I can put off dealing with this, and perhaps better to just find another tool for the job. I've got until Debian makes it's next release, to the extent that I can avoid using my laptop for paper writing.
@daveroundy I tend to agree. Although I think an inkscape intermediary script could be fashioned to translate one format to the other since it was literally impossible (technically) to do inside of Inkscape 1.0.
The problem I saw, was that there weren't any contributors who were interested in developing this.
I fail to understand why this is such a big deal. It's really not that unusual that interfaces change from time to time. You either adapt and move on or you stick with the version(s) you have.
I've looked at your GitLab @daveroundy trying to see what scripts you are talking about. You are using Inkscape to create PDFs in Makefile and papers/paper/figures/fac-svgs.py. If this is what you're talking about, a small intermediary script as @doctormo mentioned will do the job. In your case it'll be really simple since you only have to take care of translating --export-pdf to the new format.
That's just false. Well maintained command line told don't change their interfaces for precisely this reason. Making everyone modify all their programs is a great way to make everyone decide yours is not software they want to use. I've never before encountered a change like this in about twenty years of computational physics. The closest I've seen is tools stop being maintained and drop entirely out of Debian.
I hardly have anything up on gitlab, and relatively little on GitHub. I haven't bothered dealing with this (it running a grep to count the instances that will need changes) because it's only my laptop that now has the new inkscape and I can just not work on papers until the quarter ends. My plan is to see whether cairosvg meets my needs at that time.
Let's leave it at that. Whenever people resort to "arguments" like "I have x years of experience and never seen this" and "threats" like "I'm not going to use your software anymore" there's really no point in talking to them.
I agree. When a software developer respond to a bug report with an "I don't care about your experience" there's really no point continuing to discuss the bug. Telling me that it's easy for me to parse and convert command line flags, but impractical for you to do so does not make me feel any better.
Also cannot but to defend the conservative view here, which I tried
to raise here as soon as I spotted the change is upon us users (as
you can see, it was half a year ago, not the best outcome ever that
the interface allegedly received yet another shake in the interim).
I think it is quite a testament of the importance of the
free-standing SVG renderer that inkscape became go-to solution
for this task (admittedly despite this not being its main purpose).
But that alone means there is a ton of "batch use case" scripting
around, and I can only imagine plenty of them, like from source
generated documentation of some SW as mentioned, will only get
exercised infrequently (yep, despite all the CI calls, which
actually led me to this discovery), so some pain about this
disruptive change is still deferred, yet imminent. Ditto when
such processing is based off slow-rolling and LTS OS distributions
-- respective audience is yet to discover they have now new things
to tackle. Heck, I cannot easily regenerate my master thesis now,
unlike with the dead-conservative LaTeX part alone :-)
Showing some responsibility under this perhaps originally not
anticipated (but see above) weight would mean one-off centralized
effort to preserve original command-line interface vs.
hard-to-quantify (but perhaps non-negligible) effort spread over
the cases of still latent disruption. Would this constructive
discussion regarding the work that needs to be done to undo
particular effect of existing change(s) occur at the point it
was raised, perhaps there would be more happiness around now.
@daveroundy The only reason we changed the command line interface was because we were forced to by using the g Application class. There was a big discussion of the problem a few years ago, but I don't think in this case the project did enough to account for the massive number of users using Inkscape on the command line.
Alas the change was forced on us. So an argument about whether it should or shouldn't have been changed isn't on the cards. But a discussion about what can be done about it, is something we should think about.
I'm asking, because if the goal of this is to ensure the old options continue to work for the foreseeable future for convenience of users it should likely be in 1.1+, too.
If the goal was to inform users about the deprecations and have them update their scripts - well we basically had already implemented that in the most efficient way by removing those options altogether forcing people to update . Having it in 1.0.1 "only" might not be overly useful anymore for most people that are facing the issue now.