Re: [Inkscape-devel] Hackfest 2018: Actions and Toolbars
Hi all,
A lot of exiting things going on here. Separating the GUI from the functionality of Inkscape and allowing to use it as a command line tool sounds really cool.
Now the question that arises to me is whether that means Inkscape could be used as a service and output could get rendered to a client browser? That would allow for a wide variety of GUI's to be developed that could cater to specific uses. I could envision a touch version and probably a VR interface would be more of an option as well. Obviously the fast rendering with Cairo would be lost that way, but for limited use cases (for instance without filters) that should be fast enough I think.
Cheers,
Jelle
On Sat, Mar 31, 2018 at 12:40:59PM +0200, jelle via Inkscape-devel wrote:
Hi all,
A lot of exiting things going on here. Separating the GUI from the functionality of Inkscape and allowing to use it as a command line tool sounds really cool.
Now the question that arises to me is whether that means Inkscape could be used as a service and output could get rendered to a client browser? That would allow for a wide variety of GUI's to be developed that could cater to specific uses. I could envision a touch version and probably a VR interface would be more of an option as well.
I imagine there's a variety of different kinds of solutions that could be built atop a generalized backend API. Using it to support web-based art seems like an interesting area of exploration. As this is all still much in the "hand-wavey" stage, it's hard to predict exactly what will and won't be possible, but the overall architectural vision would seek to suit a wide variety of "headless" uses.
A lot of work will need to be done before we can say for sure what will and what won't be feasible to do, and we'll need to be cautious to not get over-ambitious in our planning - better to do just a few new things really well, than a whole bunch of different things poorly. But, we're all excited by the possibilities and hope others will also be enthusiastic in joining us to make it into a reality.
Obviously the fast rendering with Cairo would be lost that way, but for limited use cases (for instance without filters) that should be fast enough I think.
Could you elaborate? Why would that be lost necessarily?
Bryce
Hello Bryce,
If much of the handling of objects would be done through a command line, I can imagine using the browsers rendering engine to create the end result. Rendering SVG is something most browsers are capable of, up to certain limits (filters a not Edge's strong point I believe). Using SNAP or other javascript libraries building a GUI would be fairly straightforward. But with the end result being displayed in browsers I see little use for Cairo.
Cheers,
Jelle
On Sat, 31 Mar 2018 16:22:09 +0200, Bryce Harrington <bryce@...961...> wrote:
On Sat, Mar 31, 2018 at 12:40:59PM +0200, jelle via Inkscape-devel wrote:
Hi all,
A lot of exiting things going on here. Separating the GUI from the functionality of Inkscape and allowing to use it as a command line tool sounds really cool.
Now the question that arises to me is whether that means Inkscape could be used as a service and output could get rendered to a client browser? That would allow for a wide variety of GUI's to be developed that could cater to specific uses. I could envision a touch version and probably a VR interface would be more of an option as well.
I imagine there's a variety of different kinds of solutions that could be built atop a generalized backend API. Using it to support web-based art seems like an interesting area of exploration. As this is all still much in the "hand-wavey" stage, it's hard to predict exactly what will and won't be possible, but the overall architectural vision would seek to suit a wide variety of "headless" uses.
A lot of work will need to be done before we can say for sure what will and what won't be feasible to do, and we'll need to be cautious to not get over-ambitious in our planning - better to do just a few new things really well, than a whole bunch of different things poorly. But, we're all excited by the possibilities and hope others will also be enthusiastic in joining us to make it into a reality.
Obviously the fast rendering with Cairo would be lost that way, but for limited use cases (for instance without filters) that should be fast enough I think.
Could you elaborate? Why would that be lost necessarily?
Bryce
The thought of a headless-inkscape makes me dizzy with the possibilities for developers to create apps to help designers with vector icon sets and UI elements and stuff and USE Inkscape under the hood..
It opens the door to tools like Sketch to be developed without having to reinvent the svg editing "wheel" as it were.
Also I'd LOVE to automate some of my own icon-creating workflow using just BASH. Ya know?
On Sat, Mar 31, 2018 at 10:31 AM jelle via Inkscape-devel < inkscape-devel@lists.sourceforge.net> wrote:
Hello Bryce,
If much of the handling of objects would be done through a command line, I can imagine using the browsers rendering engine to create the end result. Rendering SVG is something most browsers are capable of, up to certain limits (filters a not Edge's strong point I believe). Using SNAP or other javascript libraries building a GUI would be fairly straightforward. But with the end result being displayed in browsers I see little use for Cairo.
Cheers,
Jelle
On Sat, 31 Mar 2018 16:22:09 +0200, Bryce Harrington <bryce@...961...> wrote:
On Sat, Mar 31, 2018 at 12:40:59PM +0200, jelle via Inkscape-devel wrote:
Hi all,
A lot of exiting things going on here. Separating the GUI from the functionality of Inkscape and allowing to use it as a command line tool sounds really cool.
Now the question that arises to me is whether that means Inkscape could be used as a service and output could get rendered to a client browser? That would allow for a wide variety of GUI's to be developed that could cater to specific uses. I could envision a touch version and probably a VR interface would be more of an option as well.
I imagine there's a variety of different kinds of solutions that could be built atop a generalized backend API. Using it to support web-based art seems like an interesting area of exploration. As this is all still much in the "hand-wavey" stage, it's hard to predict exactly what will and won't be possible, but the overall architectural vision would seek to suit a wide variety of "headless" uses.
A lot of work will need to be done before we can say for sure what will and what won't be feasible to do, and we'll need to be cautious to not get over-ambitious in our planning - better to do just a few new things really well, than a whole bunch of different things poorly. But, we're all excited by the possibilities and hope others will also be enthusiastic in joining us to make it into a reality.
Obviously the fast rendering with Cairo would be lost that way, but for limited use cases (for instance without filters) that should be fast enough I think.
Could you elaborate? Why would that be lost necessarily?
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2018-03-31 at 18:27 +0000, Grady Broyles wrote:
Also I'd LOVE to automate some of my own icon-creating workflow using just BASH. Ya know?
We could probably talk about that wrt extensions, ui improvements, exporting etc.
Best Regards, Martin Owens
On Sat, Mar 31, 2018 at 07:14:59PM +0200, jelle wrote:
Hello Bryce,
If much of the handling of objects would be done through a command line, I can imagine using the browsers rendering engine to create the end result. Rendering SVG is something most browsers are capable of, up to certain limits (filters a not Edge's strong point I believe). Using SNAP or other javascript libraries building a GUI would be fairly straightforward. But with the end result being displayed in browsers I see little use for Cairo.
Oh sure, that's true. But that's what's great about SVG, it's a standardized format that should be renderable by many different renderers.
Thanks, Bryce
Cheers,
Jelle
On Sat, 31 Mar 2018 16:22:09 +0200, Bryce Harrington <bryce@...961...> wrote:
On Sat, Mar 31, 2018 at 12:40:59PM +0200, jelle via Inkscape-devel wrote:
Hi all,
A lot of exiting things going on here. Separating the GUI from the functionality of Inkscape and allowing to use it as a command line tool sounds really cool.
Now the question that arises to me is whether that means Inkscape could be used as a service and output could get rendered to a client browser? That would allow for a wide variety of GUI's to be developed that could cater to specific uses. I could envision a touch version and probably a VR interface would be more of an option as well.
I imagine there's a variety of different kinds of solutions that could be built atop a generalized backend API. Using it to support web-based art seems like an interesting area of exploration. As this is all still much in the "hand-wavey" stage, it's hard to predict exactly what will and won't be possible, but the overall architectural vision would seek to suit a wide variety of "headless" uses.
A lot of work will need to be done before we can say for sure what will and what won't be feasible to do, and we'll need to be cautious to not get over-ambitious in our planning - better to do just a few new things really well, than a whole bunch of different things poorly. But, we're all excited by the possibilities and hope others will also be enthusiastic in joining us to make it into a reality.
Obviously the fast rendering with Cairo would be lost that way, but for limited use cases (for instance without filters) that should be fast enough I think.
Could you elaborate? Why would that be lost necessarily?
Bryce
participants (5)
-
Bryce Harrington -
Grady Broyles -
jelle -
Martin Owens -
Mihaela