1 reply to this topic

[Brian]

This may be a crazy idea, but let me throw it out there and see how it lands...

Since the Android GCS issue came up, and I've been trying to think of a way that we could have a more unified GCS on multiple devices.  There really aren't many alternatives that work on desktop OSs and (without much porting effort) on mobile devices.  One alternative that I have a bit of experience with is Processing.

Processing is a programming environment that is mostly geared towards generating animations and graphical programs very easily.  The standard processing environment uses Java, but there's also a JavaScript version for generating JavaScript web apps.  Others might know it as the standard environment for developing Arduino applications in C++.  The nice thing about it is that it is very easy to use, and makes very portable applications.  It's currently possible in the standard Processing GUI to just toggle a menu item and generate a program that runs on Android.

My first thought when I thought if it is that it's not designed for full-fledged GUIs.  It has add-on libraries for standard GUI elements, but there are no composition managers, so the GUI elements don't resize or readjust automatically based on screen size.  After thinking about it for a bit I realized that maybe that's not so important.  Currently the GCS has a notion of rearranging tiles.  Maybe it would be good enough to have fixed size GUI elements (say 400x400) and allow composition of those based on screen size.

For example, on a 400x800 android phone screen, one could have 2 tiles per window.  On a 1280x800 netbook/tablet screen, one could have 6 tiles per window, and on 1600x1200 desktop screen, one could have 12 tiles per window.  The main program could even auto-detect the screen size and have preset defaults for different window sizes.

If we have to start almost from scratch on the Android GCS anyway, maybe this would be a nice way to make a portable GCS that would work on a wide range of platforms.  Any thoughts?

One thing that I should point out is that you don't have to program Processing apps in the Processing GUI.  They're really just Java apps, and it's not hard to develop them in whatever environment you want.

[Kenn Sebesta]

Wow, this topic sat unanswered for a while. Unfortunately, I'm not going to be able to add much, except to say that in my experience, processing is like arduino. It's fun, but not for serious projects where mission criticality is important, and complexity grows. It suits the artist community nicely because it hides everything that can be hidden. However, I worry about the ability to debug, for instance, or to expand.