Ground Control Forum

whitestone · 2006-11-01 15:39:33

EDIT: OK, I'm being brain dead. But I'll ask everyone's forgiveness because I'm not a programmer--even though I did know the difference between an IDE and an API at one point in my life. Since that time, I've managed to flush my acronym section and just switched them around. It's hard to just go in and "silently" make the changes, because I entitled the whole dang thing with my faux-pas. They are all changed now--so read-on. END EDIT.

adamrice has brought up the good point that by deciding on focusing on developing a Cocoa API and not offering anything that can be accessible by those that may have the skills to create a Widget with JS/XML or AppleScript, but not the hard coding chops required by Cocoa and Obj-C, that that excludes some possible real "gems" as a result.

Some of the concern is that it is appearing to be a deliberate effort to create a high barrier to entry for module developers and why would you want to do that, when you're trying to encourage the adoption of GC? Well, the fact is, both are true. The high barrier is more of a by-product of the API decision, and not a deliberate attempt to lock smaller-scale Widget developers out. The resulting benefit is that because of the the high barrier, the resulting modules will be developed by professional, highly-skilled coders that will hopefully produce some killer modules that set the standard high for GC. Obviously, that limits the potential GC module development community to just highly-skilled Obj-C coders--a rather narrow market indeed.

In order to accommodate the more JS/XML or Ruby/Python savvy that would be interested in creating modules, that would require a completely separate API. And one that would probably be even more difficult to create well than the Cocoa API. Right now, it's a matter of limited resources. Even if MDA would have coded the app, Jason had already made it pretty clear that the second API would be unfeasible at this point.

That's not to say there is no hope for the future. Obviously if there was a demand, there's a market, and resources will be made available to create a sweet JS/XML/RubyRails/Python/AppleScript/BBCode/Etch-a-Sketch™ IDE that your kindergartner could use. As long as it meets GC's Module Nazi standards of course!

Personally, I understand both sides of this dilema, and I wish there was an easier answer for the easier-to-code side. I was pushing for something that would be extremely easy, but still retain the tight UI compliance, but as is usually the case, to make something easy is so much harder to do. Just ask Apple and Microsoft.

Last edited by whitestone (2006-11-01 17:02:40)

mythrol · 2006-11-01 16:00:45

Ground Control is not Konfabulator/Dashboard and it doesn't use widgets. We're trying to make an application that is streamline and allows for the user to Get Things Done faster. Period. Our focus isn't on end user developed modules as much as it's on allowing developers of other applications to tie into Ground Control to give their users an easier way of interacting with their application. Anything more than that is gravy.

I think one of the issues is that people are still associating GC as being just another dashboard clone. While possibly that was the view even Russell had when he first thought of GC, after 2 months at MDA, multiple talks with developers, and the cleaning and sharping of the GC vision; It is clear that GC is not that anymore.

I personally like GC in it's current state. It's slowly getting more refined into something more than Dashboard. We're not talking about simply allowing Widgets to run inside a module, inside a bar, on your desktop. We're talking about building an environment where the end user has multiple functions, from multiple applications all at ready access; All being done in very simple, very easy, very fast style.

It's not simply about allowing the end user to make a RSS feed module. That's not the main focus of GC. We're trying to make it easy for professional developers to move their applications to GC as easily as possible. If we were to build two separate IDE's there would also be a very noticeable drop off in quality, from running lean coded professional developed modules to end user developed modules.

While this isn't necessarily a problem for most people, and not really a big problem for me personally, it does introduce the risk of GC becoming a resource hog allowing the masses to make modules for it.

That's one of the big things GC is trying to avoid.

Possibly in the future there will be enough demand for it that GC will build the IDE that is needed for end user coders to make modules.

But when you've got a very small team of people working on GC, and a limited resources fund, decisions have to be made as to what's going to be in the 1.0 and what's not. There's simply not enough demand to warrant the investment of time and capital to build two IDE's.

Understand, this idea isn't off the table completely. Just put on a back burner until deemed necessary.

We want everyone's support as possible, and hopefully in the future we will make it where a larger audience can make modules. That's why I've pushed to allow skinning (not that much pushing is needed as I think Russell and Steve both agree to allowing skinning) to give the end user some customizational features with GC. I think GC very much wants to build a community of users around it, hopefully in time we'll be able to do that.

At this time however, we've got to start somewhere, and sadly this was where the line was drawn.

Steve Streza · 2006-11-01 17:37:55

Just a small clarification:

IDE = Integrated Development Environment. Usually involves an app like Xcode which brings all of your development tools together in one interface.
API = Advanced Programming Interface. High-level interface to make programming something complex easier.

For a 3rd-party developer to write a module, they'd use the module API, not IDE.

As far as this goes, as I said in the Ask-a-Dev thread, I'm not going to put in an API other than Objective-C/Cocoa for the 1.0. The effort that would be required to implement a JS/XML, Python, Ruby, *sh, or AppleScript module API is immense, because I'd need to pretty much convert that code to Objective-C/Cocoa code on the fly. That'd be very difficult to debug, too.

However, that's not to say that you can't use some hooks, like PyObjC, to make modules. And I'll probably write wrapper modules that would let you run custom scripts (a big text box and a run button).

Ground Control Forum

#1 2006-11-01 15:39:33

I'd Rather Have the Best Modules

#2 2006-11-01 16:00:45

Re: I'd Rather Have the Best Modules

#3 2006-11-01 17:37:55

Re: I'd Rather Have the Best Modules

Board footer