While viewing those videos about fund-raising, one point stuck in the back of my mind. Make sure you know who your target audience is.
Inkscape has bothered me a little bit by being neither quite fish or fowl. It tries to be friendly to the artist, but it forces him to learn a lot about the nature of SVG. In fact, its founding principle seems to be to use SVG as its internal representation.
(Is there a mission statement?)
I happen to like it, but that's because I'm a professional programmer, so formal languages are my bread and butter. But, if /I/ am the target audience, then the direct manipulation of XML is too weak for my taste. (I use Emacs. My favorite scenario would be to squirt the XML over to Emacs, edit, and squirt it back. . . . (with some indication of what is selected, but that's for another thread.))
So that's the conflict.
That is, it seems to me that the goal of making it friendly to the artist and friendly to the programmer are in conflict. Maybe you can do both.
Andrew
Hi Andrew,
Providing a vector image editor by using SVG as the basis, is pretty much Inkscape's strength. It isn't an svg editor directly and it isn't an unhinged vector image editor. It's a grounded project that works within the format specification to do some truly amazing things to provide tools to artists, graph makers and many others. And that has included pushing the SVg specification forwards at times.
Could you imagine is Inkscape was in the position of Gimp (poor gimp), where the internal format wasn't a standard and svg was a conversion? Firstly all the users who use Inkscape because their software outputs svg files, wouldn't have a natural home for tweaking their graphics.
Then think about it the other way round. Saving in Gimp is torture, it's constantly bugging you to save as xcf, you can't open xcf in a browser, can't open it in a different image editor, can't process it with python as a text/xml file for science. It's a burden.
Sure, Inkscape has done some dumb things (svg 1.2 text) but it's also done some good things (gradient meshes + js). It's trying hard to live up to artists' expectations about tooling, while not becoming undisciplined about the importance of standards setting and data formatting. SVG standards plus user standards equals good software.
Best Regards, Martin Owens
On Wed, 2019-03-20 at 13:44 -0700, Andrew Kurn wrote:
While viewing those videos about fund-raising, one point stuck in the back of my mind. Make sure you know who your target audience is.
Inkscape has bothered me a little bit by being neither quite fish or fowl. It tries to be friendly to the artist, but it forces him to learn a lot about the nature of SVG. In fact, its founding principle seems to be to use SVG as its internal representation.
(Is there a mission statement?)
I happen to like it, but that's because I'm a professional programmer, so formal languages are my bread and butter. But, if /I/ am the target audience, then the direct manipulation of XML is too weak for my taste. (I use Emacs. My favorite scenario would be to squirt the XML over to Emacs, edit, and squirt it back. . . . (with some indication of what is selected, but that's for another thread.))
So that's the conflict.
That is, it seems to me that the goal of making it friendly to the artist and friendly to the programmer are in conflict. Maybe you can do both.
Andrew
Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
While viewing those videos about fund-raising, one point stuck in the back of my mind. Make sure you know who your target audience is. Inkscape has bothered me a little bit by being neither quite fish or fowl. It tries to be friendly to the artist, but it forces him to learn a lot about the nature of SVG. In fact, its founding principle seems to be to use SVG as its internal representation.
Slightly off topic, but if artists are the target, then not having OSX supported as a primary platform is embarrassing. True I guess most "Real" artists use Adobe CS but for the programmers/starving artists, Inkscape is a godsend. The Inkscape on Max mentions/requires XQuartz, and it is by far not a trivial installation experience. There are no stand-alone .dmg or .pkg installers.
The reason I'm on this list is because at one point `brew install inkscape` worked. Then one day homebrew updated and it broke inkscape. Then I went through all the git lab posts and got a build to work -- once. I waited a few weeks, used inkscape again and the document area was just all black. I figured in those weeks inkscape for mac would have integrated the fixes*... but no joy. I'm back to not having inkscape on my mac.
I have a mac so I can do iphone development. I'd use Linux otherwise. Inkscape on Linux is a joy. Inkscape on OSX has been borken since June 2018.
* The issues are simple, during the brew install: 1. there was some bad checksum on a diff. (seems fixed) 2. some goo.h header #include statement was wrong, and failing even though I had it at: /usr/local/Cellar/poppler/0.59.0_1/include/poppler/goo/gtypes.h See below:
==> Installing caskformula/caskformula/inkscape ==> Downloading https://launchpad.net/inkscape/0.92.x/0.92.2/+download/inkscape-0.92.2.tar.b... Already downloaded: /Users/jasonhihn/Library/Caches/Homebrew/downloads/3e16227cc7b60cf452cbbdbe1f45f0c365882d5436c4ca79f9ad6061e184d68a--inkscape-0.92.2.tar.bz2 ==> Downloading https://gitlab.com/inkscape/inkscape/commit/93ccf03162cd2e46d962822d5507865f... Already downloaded: /Users/jasonhihn/Library/Caches/Homebrew/downloads/369b021412bac03164fd51cdf072f9e402caea5fabf430466d2d9779d6208a36--93ccf03162cd2e46d962822d5507865f3451168c.diff ==> Patching ==> Applying 93ccf03162cd2e46d962822d5507865f3451168c.diff patching file CMakeScripts/DefineDependsandFlags.cmake patching file config.h.cmake patching file src/extension/internal/pdfinput/pdf-input.cpp patching file src/extension/internal/pdfinput/pdf-parser.cpp ==> mkdir build ==> cmake .. -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INST ==> make Last 15 lines from /Users/jasonhihn/Library/Logs/Homebrew/inkscape/03.make: make[2]: *** Waiting for unfinished jobs.... In file included from /tmp/inkscape-20190321-12880-1lx99mq/inkscape-0.92.2/src/extension/internal/pdfinput/svg-builder.cpp:23: /tmp/inkscape-20190321-12880-1lx99mq/inkscape-0.92.2/src/extension/internal/pdfinput/pdf-parser.h:28:10: fatal error: 'goo/gtypes.h' file not found #include "goo/gtypes.h" ^~~~~~~~~~~~~~ In file included from /tmp/inkscape-20190321-12880-1lx99mq/inkscape-0.92.2/src/extension/internal/pdfinput/pdf-input.cpp:50: /tmp/inkscape-20190321-12880-1lx99mq/inkscape-0.92.2/src/extension/internal/pdfinput/pdf-parser.h:28:10: fatal error: 'goo/gtypes.h' file not found #include "goo/gtypes.h" ^~~~~~~~~~~~~~ 1 error generated. make[2]: *** [src/CMakeFiles/inkscape_base.dir/extension/internal/pdfinput/pdf-input.cpp.o] Error 1 1 error generated. make[2]: *** [src/CMakeFiles/inkscape_base.dir/extension/internal/pdfinput/svg-builder.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/inkscape_base.dir/all] Error 2 make: *** [all] Error 2
Slightly off topic, but if artists are the target, then not having OSX supported as a primary platform is embarrassing.
It's so important to the project that we consider it a blocker for the 1.0 release. At the hackfest in Pasadena we talked for a long time about how to solve this problem, mostly through recruitment and expert head hunting. We've all taken time to ask our network of friends and other open source projects to find people, ideas, and work arounds for getting inkscape on the Mac working.
If you're interested in this project, please join rocket chat's mac channel to talk to other people using home brew and other issues to do with building the DMG. Your testing would be invaluable.
Best Regards, Martin Owens
[Spoiler]
It might work soon, RdH told he has made a working package.
[/Spoiler]
Slightly off topic, but if artists are the target, then not having OSX supported as a primary platform is embarrassing.
It's so important to the project that we consider it a blocker for the 1.0 release. At the hackfest in Pasadena we talked for a long time about how to solve this problem, mostly through recruitment and expert head hunting. We've all taken time to ask our network of friends and other open source projects to find people, ideas, and work arounds for getting inkscape on the Mac working.
If you're interested in this project, please join rocket chat's mac channel to talk to other people using home brew and other issues to do with building the DMG. Your testing would be invaluable.
If Inkscape is transferred to the Electron platform then it instantly runs everywhere - OSX, Browsers, Linux, Windows:
https://medium.com/@ole.ersoy/rewriting-inkscape-in-javascript-7e351738c37c
There are A LOT of Javascript devs. Could just open a github branch and see what happens.
Ole
On Thu, 2019-03-21 at 19:59 -0500, Ole Ersoy wrote:
If Inkscape is transferred to the Electron platform then it instantly runs everywhere - OSX, Browsers, Linux, Windows:
Ole,
Such a large project needs buy in from developers. It wouldn't even be a fork, it'd be a whole new project. So you're asking for developers to start a new project and not work on Inkscape any more.
I don't think the project's best interests lie in abandoning the project.
Best Regards, Martin Owens
Ole,
Such a large project needs buy in from developers. It wouldn't even be a fork, it'd be a whole new project.
Martin - yes exactly. Something that can be iterated on slowly and hopefully draws in new experienced Javascript developers. There is also a large market for cloud vector graphics, so sponsorship should be easier.
So you're asking for developers to start a new project and not work on Inkscape any more.
Not at all. You can have two versions of the same app. Eventually this will be done under Inkscapes control or not under Inkscapes control. Inkscape is built on old tech. Inkscape can take control now and start reinventing the platform, or wait until someone else does it, and become irrelevant.
I don't think the project's best interests lie in abandoning the project.
It would be an enhancement. Expand the developer tools, expand the developer pool, expand the use cases, expand Inkscapes shelf life, expand the ecosystem of SVG components. AND nail your concern about Inkscape being able to run on any platform.
Cheers,
Ole
On Thu, 2019-03-21 at 23:19 -0500, Ole Ersoy wrote:
Not at all. You can have two versions of the same app. Eventually this will be done under Inkscapes control or not under Inkscapes control. Inkscape is built on old tech. Inkscape can take control now and start reinventing the platform, or wait until someone else does it, and become irrelevant.
Two versions of the same app has never been a winning strategy.
I don't think the project's best interests lie in abandoning the project.
It would be an enhancement. Expand the developer tools, expand the developer pool, expand the use cases, expand Inkscapes shelf life, expand the ecosystem of SVG components. AND nail your concern about Inkscape being able to run on any platform.
Even with all those advantages, it's just not worth it. Firstly, you'd be gutting Inkscape's brand, skinning the project alive and grafting it on a new project... Just to make a new project. Better to develop a brand without Inkscape's baggage. If it's Free and Open Source, the Inkscape project is going to be kindly uncle to any online or electron vector editor pointing users to it.
Inkscape doesn't have to "win", it doesn't have to be afraid of being made obsolete. Inkscape is a project for it's users, and when it's users move on, it will have done it's duty and will quietly live out it's retirement in the internet archives.
A brand new vector editor made in Electron or nodejs, is fascinating stuff. A project experiment that is one to watch. But not something we need to actively replace Inkscape with.
But Ole, you seem VERY into the idea, so you should set about this project; I know there are tons of developers for javascript (although I'm not sure they're atuned to Free Software, so YMMV) but bootstrapping such a project can be done on GitLab very easily. Then when you have made it, keep us up to date here. There are likely developers who would be interested in helping out from the Inkscape project too.
Best Regards, Martin Owens
Inkscape doesn't have to "win", it doesn't have to be afraid of being made obsolete.
Awesomeness is free :)
But Ole, you seem VERY into the idea, so you should set about this project; I know there are tons of developers for javascript (although I'm not sure they're atuned to Free Software, so YMMV) but bootstrapping such a project can be done on GitLab very easily. Then when you have made it, keep us up to date here. There are likely developers who would be interested in helping out from the Inkscape project too.
Like I told Shlomi I'm currently actively developing these open source projects:
https://github.com/fireflysemantics/validator
https://github.com/fireflysemantics/slice
https://github.com/fireflysemantics/collections
https://github.com/fireflysemantics/is
And all the repositories under this organization:
https://github.com/superflycss/superflycss
And these are only my public projects. Which is about 5% of the code base of the logistics platform I'm building. There's also more Apache stuff etc. So I might be a spreading myself a bit thin, but I may still try. It would definitely be a fun project.
Cheers,
Ole
On Thu, 21 Mar 2019 19:59:07 -0500 Ole Ersoy <ole.ersoy@...155...> wrote:
Slightly off topic, but if artists are the target, then not having OSX supported as a primary platform is embarrassing.
It's so important to the project that we consider it a blocker for the 1.0 release. At the hackfest in Pasadena we talked for a long time about how to solve this problem, mostly through recruitment and expert head hunting. We've all taken time to ask our network of friends and other open source projects to find people, ideas, and work arounds for getting inkscape on the Mac working.
If you're interested in this project, please join rocket chat's mac channel to talk to other people using home brew and other issues to do with building the DMG. Your testing would be invaluable.
If Inkscape is transferred to the Electron platform then it instantly runs everywhere - OSX, Browsers, Linux, Windows:
https://medium.com/@ole.ersoy/rewriting-inkscape-in-javascript-7e351738c37c
There are A LOT of Javascript devs. Could just open a github branch and see what happens.
Dear Ole,
your obsession reminds me of this quote: https://www.shlomifish.org/humour/fortunes/show.cgi?id=nyh-sig--a-fanatic-is . If you want to create a TS/JS-based svg editor, feel free to do so, and other people may opt to join you and help you. You can make use of inkscape's code too. But put your code where your mouth is.
Regards,
Shlomi
Ole
Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Dear Ole,
your obsession reminds me of this quote: https://www.shlomifish.org/humour/fortunes/show.cgi?id=nyh-sig--a-fanatic-is . If you want to create a TS/JS-based svg editor, feel free to do so, and other people may opt to join you and help you. You can make use of inkscape's code too. But put your code where your mouth is.
So far I've implemented and I'm actively developing these open source projects:
https://github.com/fireflysemantics/validator
https://github.com/fireflysemantics/slice
https://github.com/fireflysemantics/collections
https://github.com/fireflysemantics/is
And all the repositories under this organization:
https://github.com/superflycss/superflycss
And these are only my public projects. Which is about 5% of the code base of the logistics platform I'm building. There's more Apache stuff etc. So I might be a spreading myself a bit thin, but I may still try. It would definitely be a fun project.
Cheers,
Ole
If Inkscape is transferred to the Electron platform then it instantly runs everywhere - OSX, Browsers, Linux, Windows:
https://medium.com/@ole.ersoy/rewriting-inkscape-in-javascript-7e351738c37c
There are A LOT of Javascript devs. Could just open a github branch and see what happens.
On the surface, it's a fine idea, but then you quickly run into the fact that there is only one event loop so only one function can ever be running at once, no matter how many cores you have. Then you get into async hell.
If you want to port it to something, I would port it to Qt so that it "just works" across the board. Also there are efforts within the Qt project to support web assembly and all that. But ripping out GTK at this point is a daunting task, but at least you can map it mostly 1-to-1 with Qt, with Qt being a toolkit with cross-platform as its stated objective.
On the surface, it's a fine idea, but then you quickly run into the fact that there is only one event loop so only one function can ever be running at once,
Web workers can run background parallel computations like math done while rendering.
https://medium.com/techtrument/multithreading-javascript-46156179cf9a
no matter how many cores you have. Then you get into async hell.
ES7 will have Observables built in. Use RxJS or Promises or any other package more specific to the use case to avoid this.
If you want to port it to something, I would port it to Qt so that it "just works" across the board.
Except for in browsers which is the most leverage use case for applications that want to leverage collaboration capabilities.
Also there are efforts within the Qt project to support web assembly and all that. But ripping out GTK at this point is a daunting task, but at least you can map it mostly 1-to-1 with Qt, with Qt being a toolkit with cross-platform as its stated objective.
It's old tech and the internet is not embracing it, which means it will not benefit from all the effort going into the broader ecosystem.
Cheers,
Ole
Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Sent: Friday, March 22, 2019 at 11:26 AM From: "Ole Ersoy" <ole.ersoy@...155...> To: inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] Mission
On the surface, it's a fine idea, but then you quickly run into the fact that there is only one event loop so only one function can ever be running at once,
Web workers can run background parallel computations like math done while rendering.
https://medium.com/techtrument/multithreading-javascript-46156179cf9a
no matter how many cores you have. Then you get into async hell.
ES7 will have Observables built in. Use RxJS or Promises or any other package more specific to the use case to avoid this.
If you want to port it to something, I would port it to Qt so that it "just works" across the board.
Except for in browsers which is the most leverage use case for applications that want to leverage collaboration capabilities.
Also there are efforts within the Qt project to support web assembly and all that. But ripping out GTK at this point is a daunting task, but at least you can map it mostly 1-to-1 with Qt, with Qt being a toolkit with cross-platform as its stated objective.
It's old tech and the internet is not embracing it, which means it will not benefit from all the effort going into the broader ecosystem.
You're making my point.
Yes, everything is solvable by some future version of Javascript. However Javascript is a relative disaster full of inconsistencies. Still not bad for a language that was invented in 1992 in 10 days. It's great for tinkering on webpages, but there's no large scale formal software built with it. (For a variety of reasons)
Also, I said async hell, not callback hell. The fact that some statements return a promise and others don't... well it's confusing. Where must I sprinkle these "await"s?
By all means if you want a web-enable Inkscape don't let me stop you. I was just trying to make the point that the existing code base does not resemble what a JS version would look like, at all. WebWorkers and a single event loop and async and sandboxing aren't anything the project's source code takes into account now.
Qt is pedigree tech, and it's plenty embraced. Tesla, Mercedes, etc, all use Qt. I regularly use it for embedded, desktop (mac, linux, win) and mobile (iOS/Android). Hardware accelerated, with multiple concurrency mechanisms. The problem with JavaScript is there's a new popular web framework every 6 months, so by the time you're done your Inkscape port, someone wants to do it in yet another hip new framework.
Anyway, no one is changing Inkscape from GTK, so this is all moot.
Yes, everything is solvable by some future version of Javascript. However Javascript is a relative disaster full of inconsistencies. Still not bad for a language that was invented in 1992 in 10 days. It's great for tinkering on webpages, but there's no large scale formal software built with it. (For a variety of reasons)
Ever hear of VSCode?
Gravit Designer?
Postman?
I could literally list apps for days here. VSCode has to be THE most successful large scale IDE to date. Notice the growth rate...the number of plugins ported, etc. RedHat is porting a lot of it's Java capabilities over fast. You find capabilities for just about any programming platform in VSCode now.
Also, I said async hell, not callback hell.
Either way these are very simple to deal with. Just write an Observable facade over the interface / API that it is you want to use. Find me one package that's tricky for you to use and I will help you fix it so that it is standardized for all developers. I have already done this WRT exception handling here:
https://medium.com/@ole.ersoy/application-central-nervous-system-37aba8e5e89...
https://medium.com/@ole.ersoy/angular-application-nervous-system-brain-685a6...
By all means if you want a web-enable Inkscape don't let me stop you. I was just trying to make the point that the existing code base does not resemble what a JS version would look like, at all. WebWorkers and a single event loop and async and sandboxing aren't anything the project's source code takes into account now.
Now you are making my point. The code is old and the capabilities don't have modernization drivers behind them. Look at Amazon and Walmart. Amazon has an innovation core that drives results and innovation in all its businesses and it creates a feedback resonance effect on all of them. The synergies are complementary because of the ecosystem it exists in. Is Walmart going to be around in 10 years or is it going to look like Sears? They are still using an IBM desktop from the 70s when you visit their tire center.
Drawing algorithms, sizing, etc. are easily portable and Inkscape would now participate in an Ecosystem that is much better for its health.
Qt is pedigree tech, and it's plenty embraced. Tesla, Mercedes, etc, all use Qt. I regularly use it for embedded, desktop (mac, linux, win) and mobile (iOS/Android). Hardware accelerated, with multiple concurrency mechanisms. The problem with JavaScript is there's a new popular web framework every 6 months, so by the time you're done your Inkscape port, someone wants to do it in yet another hip new framework.
Just use Angular :)
I see your point here, but this effect also drives a lot of innovation. It's part of what keeps the space fresh and fun. An electron app could also be a PWA framework agnostic build using something like Google Workbox. Its not necessary to rely on a framework and it can be quite refreshing to just build something from scratch using NPM packages and core V8 capabilities.
Anyway, no one is changing Inkscape from GTK, so this is all moot.
I'm sure within a year we will have another really good open source SVG editor in Javascript besides Gravit designer. Obviously most people like to stay with what they are comfortable with and I understand and respect that. Truck drivers like to drive their trucks. However it's also a good idea to look around and have options because this skill is rapidly being replaced:
Cheers,
Ole
Also, I said async hell, not callback hell. The fact that some statements return a promise and others don't... well it's confusing. Where must I sprinkle these "await"s?
Here's an example of a project that that combines:
- Browsersync
- Mozilla Nunjucks
- A File watcher
- PostCSS
- Many PostCSS plugins
- Commander
Took about 2 days to write, builds all files in parallel, and has a unified promise based internal API.
https://www.npmjs.com/package/@superflycss/cli
When the ecosystem gets better I instantly benefit. It's like having a gas driven Porsche 911 that gets upgraded to a Taycan the minute it gets released :)
Ole
On Wed, 20 Mar 2019 13:44:04 -0700 Andrew Kurn <kurn@...3346...> wrote:
While viewing those videos about fund-raising, one point stuck in the back of my mind. Make sure you know who your target audience is.
Inkscape has bothered me a little bit by being neither quite fish or fowl. It tries to be friendly to the artist, but it forces him to learn a lot about the nature of SVG. In fact, its founding principle seems to be to use SVG as its internal representation.
(Is there a mission statement?)
I happen to like it, but that's because I'm a professional programmer, so formal languages are my bread and butter. But, if /I/ am the target audience, then the direct manipulation of XML is too weak for my taste. (I use Emacs. My favorite scenario would be to squirt the XML over to Emacs, edit, and squirt it back. . . . (with some indication of what is selected, but that's for another thread.))
So that's the conflict.
That is, it seems to me that the goal of making it friendly to the artist and friendly to the programmer are in conflict. Maybe you can do both.
I view it as friendly to the artist, but with the added benefit that the artist can make it do the undoable by manually editing SVG.
A second SVG benefit is it can be directly viewed in a browser or viewer, it can be directly manipulated by other graphics programs, it can be programmatically changed or enhanced by a home-grown computer program.
I don't see where a native format of SVG constrains use of the GUI. What else would the native format be? YAML? JSON? Some database in SQLite? Some binary or text format that really boils down to a subset copied from SVG, because SVG already captures all the needed data?
One more thing: Humans perform amazingly once they shed their mental blocks. There's no law of nature saying that artists lack the IQ to edit SVG. Sure, they'll need to do some trial and error to see what changes an SVG change makes in the drawing, and what changes a drawing change makes in the SQL. It will require a couple days dedicated learning. So what? To me, an artist not willing to spend time learning his tools isn't very dedicated to his craft.
I'd recommending leaving the native format as SVG.
SteveT
participants (7)
-
unknown＠example.com -
Andrew Kurn -
Jason H -
Marc Jeanmougin -
Ole Ersoy -
Shlomi Fish -
Steve Litt