Your take on my words is bizarre. Be more charitable.
fwiw, you have lots of good ideas. I'm not sure why Steve has this burning desire to dismiss the lot of them as if it were one single request. Don't let it discourage you. Most of what you're proposing is already in the works in various stages, or in plans for the future. It is certainly not "crap", and a rather large community of artists and more than a few devs agree with most of your list items. Steve seems to be saying "hey, let's not do that all at once, and make the software too complex!". I think we can let him have that point. What do you think? ;)
-C
On 22 April 2017 at 18:39, Steve Litt <slitt@...2357...> wrote:
On Sat, 22 Apr 2017 09:21:52 +0100 C R <cajhne@...155...> wrote:
Confining it to specific simplistic use cases based on personal preferences, and calling what you don't personally use "bloat" is ignoring the bigger purpose of inkscape as a professional vector graphics design tool.
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.
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.
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, so we don't bury everything and a marching band inside currently good code. 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.
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.
I did, however, say that if Donn Ingle's long laundry list of changes were implemented en masse, and especially without regard to the SVG standard, it would result in complexity (a better word for bloat). I stand by that, and suspect that Inkscape developers agree.
and its disrespectful to the design community who need Inkscape to be a fully realised vector graphics production studio.
OK, fine. Why don't you submit a list of improvements to Inkscape, sorted by descending importance, so improvement can be done slowly and steadily, instead of as a free-for-all. Next to each improvement, be sure to fully specify how the improvement would look, what the user interface might feel like, what part of the SVG spec can support it, and perhaps a few suggestions of where it might fit into the existing code.
Hey, I never said Inkscape is perfect. Nobody who has ever done a gradient in Inkscape would make that statement. What I'm saying is it's pretty darn good, so don't break it in pursuit of the "perfect".
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster,
"Faster" isn't the usual result when a bunch of features are added. There are limits to the wizardry of even the best programmers.
has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Sounds like you've got some work cut out for you, suggesting a specification for node tools and layer grouping, and for Inkscape's graphical user interface.
Lots of improvements on the way, let's not denounce them beforehand.
I'll denounce them beforehand every time someone suggests a combination of an OLE type thing *and* video *and* multipage *and* Javascript framework *and* XCF *and* 3D *and* Python interface *and* immitation of Flash *and especially* dumping the SVG standard that allows me to use Inkscape as a tool to do some pretty cool stuff. How would you like to code all that crap? How would you like to do support on the finished result? Yeah, me neither. It was a horrible idea, as stated.
That next feature you think you don't need might be the best thing that ever happened to your work flow.
Happens all the time. But it happens only when the next feature is part of an incremental improvement policy, carefully designed for simplicity and encapsulation, carefully crafted, and released only when it's ready. However, when it's quickied into the code, especially as part of a laundry list of almost unrelated other features, the only way it improves my work flow is if I move to a superior program after the current one collapses under the weight of its complexity.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user