Boxy’s interface has a nice, shallow learning curve, which is great for elementary schoolers but it also does things that Inkscape can’t right now, like boolops. I’m not dead set on Boxy of course, I’d be cool with any integration. Eliminating the hassle of moving files around is really the goal.
I’m brand new to this so am both sending out feature wishes but also looking to learn.
Do any of the svg creation apps (ez or pro) support this kind of direct GF connection?
there’s no direct connection with the files that are already uploaded to the GFUI. and i suspect that won’t ever happen. at that point, the files are no longer locally on your machine, they’re in the cloud on the GF server. i don’t think you’ll see direct interaction with files already in the GFUI from another application.
FWIW, i don’t know of any laser cutter software that has that capability. most others work more like a print driver that gets the file into the laser cutter’s control software. once it’s in there, just like GFUI, it’s in there. the GFUI allows more manipulation already than at least the one vendor’s control software i’ve worked in (Universal). the universal control panel (UCP) doesn’t allow resizing, copy/pasting, changing the order of operations, ignoring operations, etc.
the closest integration there is at the moment would be the ability to copy/paste directly into the GFUI from adobe illustrator.
Copy / paste from Illustrator to the UI is about as close as you can get right now. Not sure if it works for Inkscape as well?
I’d never heard of boxy either. If I was going to support resources dedicated to integration like that, I’d rather see the plugin for Illustrator that was mentioned at some point.
I completely disagree with there being any plugin. The nice thing about the way it works now is it doesn’t care what application you use. You can use absolutely anything, as long as it can produce a SVG or PDF file, which are pretty much standardized, you can use this thing. You can use the tools and applications you’re comfortable with and get things lasered easy peasy. Adding addins and specific applications makes it too limiting for just anybody to use. Nope, I like it just the way it is, and wouldn’t want it any other way.
This sort of plugin/workflow enhancement wouldn’t take any ability away from you, but would simply enhance the users of boxy. I don’t see the harm, except maybe as yet another set of use cases for GF to support.
I just don’t see how adding this would be any different from copy/paste from illustrator, and that hasn’t seemed to get you down.
Now… in terms of ROI…? I don’t know enough to say for sure but I’d wonder if developing for boxy would impact very many users.
agreed. i think if GF does anything like this, it will be for one of the big 2-3 apps, like illustrator, inkscape, maybe some sort of CAD connector.
and really, to me the easiest way, if it could be configured to work with a browser (which is probably why it isn’t done this way), would be to use a printer driver. that’s how the universal does it. you print to the driver and it shows up in your control panel.
Building a plugin for a limited number of users takes resources away from developing things everyone can use. A plugin for a little used web app would be a waste of developer resources.
You don’t know that for sure. This might not take any resources away from anything. I agree it seems like it might work out that way but we can’t say that for sure.
As a professional software developer for 30+, I can tell you unequivocally, it would take resources away from something else to develop this. Writing software can be a long, hard process and with a limited number of developers on the team, you have to decide what they should be working on. It’s far more profitable to have developers working on stuff that everybody can use instead of derailing them onto a niche project that would have very little return. Balancing developers to tasks is no easy feat. So yeah, assigning a developer to work on something frivolous hurts the overall development of a product.
Maybe then I just couldn’t find it then but when I looked a couple days ago, for OSX anyway, there was some beta code that I would have had to build but things like subtract, exclude, join, weren’t in the .92 version.
Will this allow me to set different speeds and powers for different artwork / layers? I’m trying to work out a way where I can ‘paste’ but include all the machine specific details.
Again, GF will create individual ‘art work’ based on different colors in your svg, so it seems like it would not be hard to also be able to include some GF specific data about power / speed etc. that GF could use when it opens the file and splits up the different parts. (Simple example svg: letter-a-7-wide.svg - Google Drive) Right now if I make changes to the svg, I not only have to go through the upload dance, but also go and setup all the speed and power values I want but that didn’t actually change.
Also, I just tried but I don’t see any affordance in the GFUI to let me ‘paste’
no, the copy/paste is basically a shortcut for uploading.
i know the idea of adding cut/engrave/score settings to the SVG prior to uploading has been raised. and it’s been “put in the hopper.” but that’s a big hopper and who knows what the priority list is or how long it will be. or how it would be implemented. nobody from GF has really said or committed to anything.
fwiw, that’s part of why i like the print driver method that universal uses. because you can pull up the settings window in a file, input settings, then print. the file remembers the last settings you used (at least it does in illustrator). which is why i always set them in the process of the print instead of in the control panel.
We all have our biases when it comes to this sort of thing, I think that we probably largely agree here but I’m not willing to say that it’s a slam dunk. Here’s why not:
Assumption 1: your tenure has some effect when it comes to understanding glowforge’s specific org structure and processes.
A lot of us here are long-tenured technical types, plenty of time to get entrenched in our ways of thinking. It’s possible that longer tenure is even a bit of a disadvantage when it comes to innovation.
Assumption 2: this is a frivolous thing.
Not our call, and definitely is in the eye of the beholder. It comes down the ROI, where the I is “effort” and the R is impact. We don’t know how difficult it would be to do this nor how many users (or the specific demographic of said users) would be affected. It’s possible that this would be more impactful than it might seem.
A counter or two, where it costs little to do this. Both scenarios are theoretical but also both quite possible:
Scenario 1: Glowforge opens up an api to the boxy developers. They create a plugin and ask Glowforge for approval to use it. Very few developer hours spent at GF.
Scenario 2: (again thisnis theoretical) GF has a dedicated plugin developer on staff who is tasked with this sort of integration and has some spare cycles at the moment. Adding this project to the docket would allow for better utilization of her time, thus increasing GF’s efficiency.
I’m just saying that there are lots of cases where this sort of work might not impact the rest of the work at GF, and given that we have essentially no insight into their internal processes or staff assignments it’s a pretty big leap to categorically rule it out.
If they had a dedicated developer working on plugins, we would’ve seen results by now, especially if they have “spare cycles”. If they have a plugin developer free to do this, then they’re certainly doing something wrong.
I have never seen a development project that required no developers. In a team, typically everyone is working on something. Want something new, you need to pull a developer off a project to put them on a different project hence the previous project could now be understaffed, and deliverables will most certainly be affected.
We have a working, solid, and stable workflow. To build a one off plugin to an app that most designers probably aren’t using is a complete waste of resources. I’d much rather they work on the core functionality that everybody can benefit from, not those few who have to use a non-standard no name application. If you’re gonna be serious about design work, you’re most certainly not going to be using boxy.
really, this is where i would hope/wish they were putting their efforts in. we have enough members of the community who are capable of using an API to create a plugin that i would expect someone would make some things happen. even if it was just because they wanted to make their own lives easier and some people just enjoy the challenge of making it work.