On Sat, 22 Apr 2017 23:21:14 +0100 C R <cajhne@...155...> wrote:
Nobody in this thread called anything about Inkscape "bloat", nor said that code related to what they don't use is "bloat". Go back and check the archives. I brought up "bloat" with respect to Firefox.
*sigh* Which was your reply to Donn's comparison of firefox to Inkscape as another example of a program that was good at a lot of different things. Maybe it was not your intention to say Inkscape's new features will lead to Inkscape being bloatware, but it certainly came off that way.
Look back through the archive, and see the context in which I used the word "bloat". But now that you mention it, I'd be surprised if adding everything suggested, quickly and at once, would not add complexity, leading to behavior most folks associate with "bloat".
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization.
Nobody in this thread said Inkscape is currently bloated. What I said, although not in so many words, is that glomming on the feature list recommended by Donn Ingle would greatly increase its complexity.
Some of Donn's stuff is right on the money, and have already been discussed in previous emails and on IRC.
"Some." Which ones? Heck, I might agree if it weren't presented as a laundry list.
If you've got some issues with particular items, that can be discussed. Dismissing someone's personal wishlist wholesale isn't very helpful.
It *is* helpful, given the manner and lack of prioritization the wishlist was presented. If an attempt was made to implement the whole thing, the Inkscape program would likely suffer badly.
We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
In that case, the professional graphic design users should prioritize which good ideas are most important
They do, all the time, in fact. And most of them are written into the roadmap somewhere.
Where? Seeing such a roadmap would be most informative.
And those pro graphic designers should give us some ideas of how to implement those ideas in a way compatible to SVG1, or else brainstorm to come up with an idea of how to implement stuff incompatible with SVG1 within separate executables.
Uh, no. :) SVG1 is a delivery format for simple vector graphics. SVG2 will eventually become a delivery format as well because it's no longer developed.
Then there may be good news. I'm not a C++ guy, but I just downloaded and very quickly scanned some of the Inkscape source. It's about 100K lines of .cpp and about 28K lines of .h, and appears to me to be laid out in a clear, well abstracted way. It's a big program with a lot of stuff because it's a big program that does a lot of stuff, but it seems to me to be laid out logically.
I spent 5 minutes checking out the SVG2 specification. Probably because I know little of the mechanics of image manipulation, I didn't understand what I read, but you and Donn would likely understand more. Once you understand the spec, if the Inkscape developers go along with it, you and Donn could start moving it over to source files, one at a time, that would be read only if #ifdef SVG2CANDREC20160915 or whatever. There would probably have to be some other #ifdef SVG2CANDREC20160915 conditional compiles in existing code, but the idea would be to have your code enabled by #define SVG2CANDREC20160915, and if that's not defined, it should compile to the exact same program it does not. You should also make a program called "graceful_degrade" that removes all version-2-only XML from the finished Inkscape file. I'm more of a C guy than C++, but if you do this, I might help you to a limited degree.
That's exactly what this thread is about: some users have it in their minds that everything must be somehow crammed into an SVG, and viewable in browser.
That's sure my definition of Inkscape, and Inkscape would be much less valuable to me otherwise.
Well, it's not going to happen. Inkscape will always be able to save/export to SVG1 and SVG2 as a delivery format, and read those formats back in for use in other projects.
If those conversions are round trip and pass a diff test on SVG files that have gone several round trips through them, I'll worry less about SVG not being the native format. Otherwise, it's a big worry.
However, those formats simply don't cover the complete needs of a pro-graphics construction file. We even have mesh gradients now, which is not officially in either spec. Guess we should abandon that too, just because some people like Inkscape the way it is? No... no I think not. :)
Not at all. It was defined sanely in a few .h files, I assume implemented sanely in files that could use mesh gradients, and a mesh gradient could be made to gracefully degrade by changing any fill properties using the mesh to something more appropriate.
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs,
Oh HELL no. If devs hugely complexify software to the extent that it becomes buggy, slow and incompatible, they ruined the software, and deserve disrespect. It should be noted that nobody in this thread made that accusation about *Inkscape* developers.
Except Inkscape IS a complex program.
It's big and does a lot, but I wouldn't call it complex. From the half hour I've spent looking at the source, it's a very sane and simple way of implementing something so powerful.
You're saying everything that can not be done in SVG1 should be excluded. Everything else is "bloat", right? Frankly, I don't know what you're trying to say at this point. :)
After looking at the program, I think there are ways you guys could start implementing SVG2 features, **one at a time, with heavy testing**. I could help to some degree, and could write documentation.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques