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.
2 Likes
i don’t think anyone’s disagreeing with that.
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.
3 Likes
What’s that? Inkscape does booleans
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.
1 Like
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.
2 Likes
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.
2 Likes
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.
4 Likes
long-tenured technical types
Yeah, I’m in this bucket too and it’s a lot of why I am always thinking and typing out-loud about how these pieces could work together better.
GF opens up an api
Yeah, I think this is the real answer. I read the older posts here asking about 'Will there be a GF API?" before I typed out my use case from a black box perspective but purposely didn’t go down that route. I think I just wanted to describe the ideal flow without getting into the details of an API answer right off the bat.
I think allowing any svg editor app the ability to request a view of the bed and then send along basic cut job settings is the best answer for everyone. In this way Boxy, or Illustrator, or figma or whatever app could simply add it in as an option. The plumbing is in place to feed the GF web UI already and since I’ve also been in the sw biz since the late 90s of course I’m not saying that it wouldn’t be a bunch of work to make this available to third parties but I do think it would remove a lot of drudgery from the process.
some people just enjoy the challenge of making it work
+1 to this. After my last reply I started poking around in the JS debugger to see if I could work out how to maybe build a Chrome extension to make it do what I want. =)
1 Like
there’s one user here who created a chrome extension to save settings. unfortunately it broke when GF updated the GFUI to have settings saved inside the GFUI, but it was a great timesaver while it was around.
and that’s the downside to create w/o an API of some sort. the GFUI is a web interface and can change w/o notice and it’s not an update you run on installed software. so things can break easily.
More assumptions here. You’re illustrating my point.
Educated assumptions that are most likely not wrong. Software development is pretty much the same everywhere, and it’s a constant battle balancing development resources to deliverables.
One of the original selling points for me was that they had said there would be an Illustrator plugin. I haven’t heard it mentioned by GF in quite a while. I still want it.
6 Likes
Ditto.
3 Likes
thirded.
2 Likes
Thank you for the suggestions!