Hi Andrew, As far as I understand, you will want to make a new feature request, in the new gitlab bug tracker, which is here: https://gitlab.com/inkscape/inbox/issues. Click on the green "New Issue" button.

If you have technical or development details about how you think it should work.....I'm not sure where that should go now that we've moved away from Launchpad. Maybe in the wiki? Basically you would write a proposal with all the details you have, and link that page into your gitlab Issue.

Since I've answered, I might add that I've never used GIMP's vector tools. But I have the impression, from reading comments here and there, over some years, that GIMP's vector tools are fairly rudimentary, and not nearly as sophisticated as Inkscape's. Personally I'm totally happy with Inkscape's Pen/Bezier tool. But now you've made me curious, and I might have to test GIMP's tool.

I wouldn't post it in the new forum yet, because not very many people will see it. But you could post it for discussion in other forums. However, keep in mind that the forums are primarily user forums, and developers probably won't see it. Devs will see it from gitlab and the wiki (or wherever).

But one good thing about posting in a user forum, is that you might learn about more Inkscape features that you weren't aware of before. Or there might be different ways to do some things.

Hhmm....well, there might be some gitlab feature that would work for such a proposal. I'm not all that familiar with it, and typically get lost there, if I'm looking at anything except Issues. Maybe someone else can explain about that, if there's a way to do it on gitlab.

All best, brynn

-----Original Message----- From: Andrew Kurn Sent: Saturday, January 26, 2019 5:16 PM To: Inkscape User Community Subject: [Inkscape-user] new post - wish list

I would like to post a wish list item. I'll tell you the topic. You tell me whether I can post it to the new forum (possible?) and whether I should (advisable?).

The current user interface for drawing and editing splines (Bezier) is bad.

I like the Gimp one much better, but partly because I'm used to it.

We can go into detail, but this introduces the topic. Let's improve the spline interface. How to do it?

Andrew

_______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user

...

Victor Westmann wrote: One thing I can tell is that I have bought the proprietary program

called Affinity Designer

...

and even though it is a very interesting application the bezier

tools in there are not

...

as sophisticated as they are in Inkscape.

Yup, Designer is quite the nice tool.

Reminds me of a review I've read somewhere out there in the wild where the reviewer comments that Inkscape always seems to be on the verge of greatness.

I know the intent was to be less-than-positive, but . . . at least they can admit to how close it really is.

~ David

OK, all,

I've posted it to Gitlab. It is #168. The description is short enough that I felt it could fit in the space of a normal issue. So, I didn't reference any page anywhere else.

It's bad news that you have left Launchpad, since it is mentioned frequently on the Inkscape web site . . . so many users will be misdirected.

I looked around to see if there was anywhere to start a discussion, but couldn't find anything. The Wiki doesn't do automated sign-ups and the only other place PHPBB has posts 12 years old.

Andrew

On Sun 27 Jan 2019 16:22 -0700, brynn wrote:

Hi Andrew, As far as I understand, you will want to make a new feature request, in the new gitlab bug tracker, which is here: https://gitlab.com/inkscape/inbox/issues. Click on the green "New Issue" button.

   If you have technical or development details about how you think it

should work.....I'm not sure where that should go now that we've moved away from Launchpad.

On Wed, 2019-02-27 at 18:55 -0600, Ole Ersoy wrote:

This is my wish:

https://medium.com/@ole.ersoy/rewriting-inkscape-in-javascript-7e351738c37c

I completely understand the sentiment. And it's something that's been tried (although bits and pieces, for different reasons). Though never elektron.

I'm personally not moved. As a python and C++ developer I find javascript to be the most clunky language with popularity. It's worse than C++11 on the fundamentals (inkscape's current language). The momentum behind Inkscape's codebase would mean a js version would always be a ground up recreation anyway.

Best Regards, Martin Owens

I completely understand the sentiment. And it's something that's been tried (although bits and pieces, for different reasons). Though never elektron.

I'm personally not moved. As a python and C++ developer I find javascript to be the most clunky language with popularity. It's worse than C++11 on the fundamentals (inkscape's current language). The momentum behind Inkscape's codebase would mean a js version would always be a ground up recreation anyway.

Martin have you looked at Typescript.  It's very close to C++ and the refactoring support in VSCode is quite good.  Not sure if Gravit uses it, but Gravit is a very good backdrop as to what is possible:

https://gravit.io/

Another interesting thing would be to have mini sub assemblies of Inkscape C++ vs. Inkscape V8 (Javascript) just to compare performance and code modularity / foot print size.

Cheers,

Ole

Launchpad is mentioned frequently on the forum, only in reference to bugs. I would think (and hope) that anyone who thinks they have found a bug will either post a new message or visit the website, where either way, they will be directed to gitlab.

We have done everything we can think of, to make sure people who want to report a bug go to gitlab from now on. Every mention of bugs on the website has been edited, we've made posts in the forums, it's been announced in the mailing lists, and in the new RocketChat channels.

I don't know, maybe there's some way to disallow new bug reports on Launchpad? Or maybe a redirect from the new report button?

In any case, leaving Launchpad is not being done without good reason. I can't say exactly what the reason is -- a developer can probably explain it better than me.

All best, brynn

-----Original Message----- From: Andrew Kurn Sent: Wednesday, February 27, 2019 5:14 PM To: Inkscape User Community Subject: Re: [Inkscape-user] new post - wish list

OK, all,

I've posted it to Gitlab. It is #168. The description is short enough that I felt it could fit in the space of a normal issue. So, I didn't reference any page anywhere else.

It's bad news that you have left Launchpad, since it is mentioned frequently on the Inkscape web site . . . so many users will be misdirected.

I looked around to see if there was anywhere to start a discussion, but couldn't find anything. The Wiki doesn't do automated sign-ups and the only other place PHPBB has posts 12 years old.

Andrew

On Sun 27 Jan 2019 16:22 -0700, brynn wrote:

Hi Andrew, As far as I understand, you will want to make a new feature request, in the new gitlab bug tracker, which is here: https://gitlab.com/inkscape/inbox/issues. Click on the green "New Issue" button.

   If you have technical or development details about how you think it

should work.....I'm not sure where that should go now that we've moved away from Launchpad.

_______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user

On Wed, 27 Feb 2019 18:55:16 -0600 Ole Ersoy <ole.ersoy@...155...> wrote:

This is my wish:

https://medium.com/@ole.ersoy/rewriting-inkscape-in-javascript-7e351738c37c

Cheers,

Why in the WORLD would a team actively maintaining and improving a complex graphical project for at least 12 years, with no hint of being painted into a corner, stop dead in their tracks and rewrite their software in another language? Why would anyone suggest they do so?

I understand the value of ElectronJS: I use Kivy occasionally and apparently ElectronJS has the additional advantage of native look and feel. I'd consider using ElectronJS for new construction.

But rewriting an existing application? No.

SteveT

On Sat, 2 Mar 2019 01:17:24 -0600 Ole Ersoy <ole.ersoy@...155...> wrote:

...

Why in the WORLD would a team actively maintaining and improving a complex graphical project for at least 12 years, with no hint of being painted into a corner, stop dead in their tracks and rewrite their software in another language? Why would anyone suggest they do so?

For the same reason is driving developers to switch to VSCode.  I have added many more technical and strategic reasons, including expanding the potential developer pool (There are a lot more Javascript developers than C++ and the inverse relationship is accelerating because Javascript can run on both the server and client), but the main reason I would do it personally is because it's fun and it would expand my skill sets in new and creative ways:

https://medium.com/@ole.ersoy/rewriting-inkscape-in-javascript-7e351738c37c

Newer vector graphics software like Gravit Designer could render Inkscape irrelevant depending on the speed and iteration at which they and VSCode editor plugin development executes.  Once users start sharing prototypes of drawings in the cloud and are able to live edit and fork instances of drawings it becomes a natural default to gravitate to.  Does that paint Inkscape into a corner? Who knows?  But it's definitely a better application if it can be embedded in blog posts and served up as a progressive web application with shared sub components that are consumed by an expanding ecosystem of users.

Cheers,

Ole

As an ordinary user, the further away I can get from javascript the better! It's a malware artists wet dream :( As for 'cloud' (someone else's computer I have no control over), I'd rather leave the family silver on Dartmoor.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ and https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/ for why rewriting is ill advised and for an alternative. This can be mitigated to an extent by gradually translating and embedding/interfacing individual pieces of code. (a la https://en.wikipedia.org/wiki/Chimera_(mythology) ).

Should probably have used to word "Transferring" and "Modularizing" instead of "Rewriting".  I'm sure the Inkscape devs are brilliant and the code is solid.  The medium posts is more targeted at what you can do once the code sits in a different platform, which I also presume will make the entire architecture nimble WRT embedding and collaborating on the web and module reuse / sharing.

Ole

Inkscape is currently the most extensive SVG renderer; how would one transfer or moduralise to Javascript while replacing Cairo and all the intensive bits of technology?

The Javascript version could start out as an experimental javascript branch / playground for anyone interested.  The two could be complementary.  Personally I usually prototype in typescript or javascript because they are simple to setup and very approachable, but if I'm creating server side code I may convert the final to Java depending on how stress / performance tests, dependency robustness evaluation, etc. go.

I would not view the current Inkscape vs a Javascript version / approach as mutually exclusive, but complementary.

As far as development approach -- breaking each "Intensive bit of technology gem" down by use case / module and examining the possibilities from there I'm certain would yield some interesting discoveries.  For some blue sky context:

https://css-tricks.com/rendering-svg-paths-in-webgl/

If done right Inkscape could be the core hub for open source SVG Javascript development feeding upstream libraries.

Javascript SVG Drawing APIs / Implementations (Perhaps Inkscape could provide some standard interfaces bringing these together):

https://svgjs.com/docs/2.7/

http://snapsvg.io/

https://bonsaijs.org/

http://dmitrybaranovskiy.github.io/raphael/

https://www.npmjs.com/package/two.js

https://github.com/sebmarkbage/art/

http://fabricjs.com/

http://velocityjs.org/

Inkscape is much more extensive and intensive than most developers even understand.

That I'm sure of!  It's an engineering gem.

It's both why it's harder to code for and also why it's very hard to replace.

NO REPLACE!!  ENHANCE and COMPLEMENT!! :)

Cheers,

Ole

On Sat, 2 Mar 2019 01:17:24 -0600 Ole Ersoy <ole.ersoy@...155...> wrote:

...

Why in the WORLD would a team actively maintaining and improving a complex graphical project for at least 12 years, with no hint of being painted into a corner, stop dead in their tracks and rewrite their software in another language? Why would anyone suggest they do so?

For the same reason is driving developers to switch to VSCode.  I have added many more technical and strategic reasons, including expanding the potential developer pool (There are a lot more Javascript developers than C++ and the inverse relationship is accelerating because Javascript can run on both the server and client), but the main reason I would do it personally is because it's fun and it would expand my skill sets in new and creative ways:

Fun is good. So is expanding your skillset. So go ahead and rewrite Inkscape in Javascript. But don't distract the Inkscape Developers with calls to rewrite perfectly functional code for an extremely well functioning program. Those of us who actually use Inkscape for:

* Art * Diagrams * Active images * Flyers and newsletters * Mailmerged certificates * eBook covers

appreciate having developer time available for fixing any bugs (I've never found any) or carefully adding new features, rather than rewriting a hugely featureful implementation of a solution to a naturally complex problem domain for fun and experience.

SteveT

Another consideration is that there are fewer and fewer core drivers for desktop apps.  The ecosystem is moving to the web, Electron allows us to write once, deploy anywhere (Web, desktop (Linux, Mac, MS, phone), the ability to collaborate on the web makes writing software more fun and interactive and it's easier to render UIs and drawings in the browser platform.

The browser based platforms are receiving 99.99% of the attention from the guys pulling on the ropes, and for good reason.  So if we do the math that has implications for all native desktop applications.

The slack client => electron, gravit designer => electron, postman => electron ... and so on.  Do we want Inkscape to die a slow death or live?

LIVE INKSCAPE LIVE!!!

Ole

On 3/6/19 12:31 PM, Steve Litt wrote:

On Sat, 2 Mar 2019 01:17:24 -0600 Ole Ersoy <ole.ersoy@...155...> wrote:

...

...

Why in the WORLD would a team actively maintaining and improving a complex graphical project for at least 12 years, with no hint of being painted into a corner, stop dead in their tracks and rewrite their software in another language? Why would anyone suggest they do so?

For the same reason is driving developers to switch to VSCode.  I have added many more technical and strategic reasons, including expanding the potential developer pool (There are a lot more Javascript developers than C++ and the inverse relationship is accelerating because Javascript can run on both the server and client), but the main reason I would do it personally is because it's fun and it would expand my skill sets in new and creative ways:

Fun is good. So is expanding your skillset. So go ahead and rewrite Inkscape in Javascript. But don't distract the Inkscape Developers with calls to rewrite perfectly functional code for an extremely well functioning program. Those of us who actually use Inkscape for:

• Art
• Diagrams
• Active images
• Flyers and newsletters
• Mailmerged certificates
• eBook covers

appreciate having developer time available for fixing any bugs (I've never found any) or carefully adding new features, rather than rewriting a hugely featureful implementation of a solution to a naturally complex problem domain for fun and experience.

SteveT

---

Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user

Not related much to your realtime co-editing vision, but I have really appreciated the upload/download to OpenClipArt feature in terms of allowing others to help with my projects even without necessarily knowing it, and me doing the same in turn for yet others. I guess my wishlist item would be for this existing feature to become just a module in a framework for other repositories to upload to and/or download from, in particular Wikimedia Commons.

Related to that is that more and more icon sets are appearing on NPM like:

https://www.npmjs.com/package/ionicons

A electron version of Inkscape could just add these as a dependency and include them in the symbols section or do what Gravit does and create a searchable interface for them.  That would form Inkscapes installable set.

Then for dynamic sets or refactoring it's possible to build a Stackblitz like dependency management feature for vector graphics and whenever anyone releases a new NPM package containing SVG that could brought into Inkscape very easily.  Inkscape dependency management for vector graphics ...

Inkscape could then become "THE" refactoring and feedback tool for all these svg icons sets.

All the use cases that Steve cited would also benefit from this type of approach.

Ole