Ground Control Forum

adamrice wrote:

mythrol--I took a look at that thread, and to be honest, it's kind of discouraging. If the decision is made to code modules in obj-C (or whatever) to achieve certain necessary functions or performance, I'd say fine. But if it is simply being chosen as a barrier to keep out the riffraff, it's a disappointment. This approach may pre-empt a lot of crap, but it also no doubt pre-empts a few jewels.

Limiting to Obj-C for plugins is most likely a temporary solution.  I'd love modules coded in things like Python or Ruby, but making that work is a pretty big undertaking.  The fact that it raises the barrier to entry is a bonus.

It makes interacting with another application language-agnostic.  So, a front end for, say, iTunes could use Apple Events.  However, the module developer would still as far as creating the module's UI and logic, you can't really use Apple Events unless I expose them all (which would suck very very hard).  Plus, it'd probably be slow and hard to develop in.

adamrice wrote:

Also, GC isn't porting apps, it's interacting with apps--which is exactly what Applescript was invented for. And even if you were porting apps, you would not be porting them from Cocoa to Cocoa.

Maybe your term of porting is different from mine. Saying as we're not sure exactly how apps will run in GC just yet, it's a little hard to say exactly how we're going to implement them. If the module sends information back to the running app that's one. But there's also some thought about certain modules being self contained apps. (ex: AppZapper could easily be self contained) It was in that sense of the word porting I was talking about. Porting the apps from running stand alone to running inside of a module. No you wouldn't be changing the app from cocoa to cocoa. But it would require some rewriting of the app to run correctly in the module. Hence, porting.

I honestly don't see Applescripts working for all our modules. But again, nothing is set in stone, nor has everything been discusses. None of this however changes the fact that to include java/html/etc would require a 2nd API being wrote. Which isn't going to happen early on.

Possibly this question could be posed to Steve in his "ask the dev" section, he might be able to give you a better response regarding Applescript and how modules will run.

adamrice wrote:

Please understand that this is tantamount to saying "go screw yourself" to people like me.

I can handle some scripting, but I haven't written compiled code in 22 years. I enjoy finding bits of scripts that I can cobble together into something useful to me.

If you can't trust me to build a module, you shouldn't trust me to contribute to this discussion either.

Finding bits of scripts and cobbling them together I think is one of the things GC is trying to avoid. That's one of the major flaws (at least in my eyes) with widgets now is it allows too much freedom for what the end user can do, leading to a lot of people releasing a lot of widgets that just plain suck.

One answer to this problem might be to build a module inside of GC that will allow of user inputed java/etc. Let the user put whatever they want inside and the module wraps a pretty shell around it to play nice with other modules. This would allow for those people that "have" to use something with a different coding language the oppertunity without opening GC up to a plethora of crap modules. Again though, this is something Steve would have to weigh in on and give us his thoughts. This might still require a large undertaking and one that's just not feasible in a 1.0 release.

Regardless, Please understand GC is not trying to lock out those people that want to develop modules but can't because of not knowing the language. It's simply a matter of the amount of work involved vs. the payoff for said work. Until GC gathers a large following that asks for the ability to code modules in multiple other languages, it's not feasible to take on such an unnecessary task so early on in it's life.

The key thing to remember is: 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.

At least, that's how I've always seen GC as being.

Last edited by mythrol (2006-11-01 15:39:57)

I have fallen in love with just the idea of this application. It is the application I have always wanted. You had an amazing origonal idea for this application and it has been taken to new heights...

However...and hear me out before you judge this idea please...

          This application is good as it is yes, but it has the potential for so much more. Why not let it be more? This started as an alternative to the dashboard. A new widget environment, but it is crawling closer and closer to a new mini OS X UI. I say add a finder module, or a module that would do what finder does and completely make the dock obsolete. Add quicksilver and or overflow like modules, add a web browsing module. This could become so much more, and its GREAT now. So yeah...that was just a thaught...

Anywho...module ideas are as follows:

1.) Small Web browser.

2.) Flash Player (with drag and drop interface for .swf 's and such)

3.) Widget / Module Creation Module ( a what you see is what you get type of interface that allows you to create your own module right there in Ground Control)

4.) Chat (an adium module that would not only let you check your buddy list but also I.M. using the Ground Control Interface.)

5.) Collection Module ( a module where you can drop widglets like little battery monitors, air port monitors and such into a little popup bubble or something...like a mini dashboard for ground control) {Ok I know like that sounds like it is defeating the purpose...but I'm just throwin ideas out there}

6.) Screen Shot Module (I like the program Snapz Pro but I HATE the Interface maybe ground control can make a screen capture module that is as powerful as Snapz Pro with a better UI)

7.) Transcript viewer Module ( A module that would let you search/browse/view chat transcripts)

8.) Todo Module ( a simple todo list.)

9.) Video Player (I WOULD FREAKIN LOVE IT if I could watch my favorite Vodcasts on a little popup bubble in Ground Control, while I'm working or browsing the web or talking with my friends. Resizable bubble...rounded corners...optional force widescreen...)

These are modules that I would love to see...please tell me what you think of my ideas love it or hate it, I want to know.