1:44 p.m.
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
2:32 p.m.
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-user
7:39 a.m.
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.ta...
Already downloaded:
/Users/jasonhihn/Library/Caches/Homebrew/downloads/3e16227cc7b60cf452cbbdbe1f45f0c365882d5436c4ca79f9ad6061e184d68a--inkscape-0.92.2.tar.bz2
==> Downloading
https://gitlab.com/inkscape/inkscape/commit/93ccf03162cd2e46d962822d55078...
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
7:44 a.m.
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.
https://chat.inkscape.org
Best Regards, Martin Owens
8:54 a.m.
[Spoiler]
It might work soon, RdH told he has made a working package.
[/Spoiler]
--
Mc
2:45 p.m.
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
5:59 p.m.
> 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.
https://chat.inkscape.org
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
7:29 p.m.
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
9:19 p.m.
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
10:57 p.m.
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
4:41 a.m.
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.
>
> https://chat.inkscape.org
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-user
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
http://www.shlomifish.org/humour/bits/New-versions-of-the-GPL/
The Angel of Death cannot keep up with Chuck Norris’s throughput of killing.
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/
Please reply to list if it's a mailing list post - http://shlom.in/reply .
7:16 a.m.
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.
8:26 a.m.
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-user
8:35 a.m.
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
8:42 a.m.
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
11:29 a.m.
Sent: Friday, March 22, 2019 at 11:26 AM
From: "Ole Ersoy" <ole.ersoy@...155...>
To: inkscape-user(a)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.
2:07 p.m.
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-37aba8e5...
https://medium.com/@ole.ersoy/angular-application-nervous-system-brain-68...
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:
https://www.autobon.ai/
Cheers,
Ole
2:24 p.m.
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
1718
days inactive
1720
days old
inkscape-user@lists.inkscape.org
19 comments
7 participants
participants (7)
-
unknown＠example.com -
Andrew Kurn -
Jason H -
Marc Jeanmougin -
Ole Ersoy -
Shlomi Fish -
Steve Litt