Just a test of running WebIDE in a web browser, editing, compiling and loading .spin code onto a QuickStart which is attached to a RaspberryPi. Proof of concept somewhat as it's just a simple .spin program without external objects, etc... Could have made the project a little more complex with objects or even used a C project with libraries, but wanted to quickly run this test.
Simple test:
Web Browser to WebIDE, which is running on Raspberry Pi
Create/edit .spin example code
Create simple Python compile/load script:
launches openspin to compile .spin to byte-code .eeprom file
launches propeller-load to upload .eeprom file to QS
runs uploaded code on QS
Run Python compile/load script, display Terminal
Propeller QuickStart is linked with USB cable to Raspberry Pi (via powered USB hub)
I accessed the IDE from another location, created .spin & .py scripts, compiled, loaded & ran my test on the QS.
I'll re-test via my 1st gen iPad later, but should just work (with the "normal" difficulties of using a tablet for source code input )... I do have a Bluetooth keyboard that should make it less painful.
How many QS boards could this connect to, potentially ?
Either by using the hub outlets, or by simple plug-sharing, in an ad-hoc way ?
Well, it is just a reference point as going wireless (WiFi, XBee, etc.) is more likely a goal...
USB 2.0 itself supports how many nodes (128)? Linux will support a non-infinite number of USB-serial ports (I assume). Raspberry Pi will support "in reality" some smaller number of ports. You can daisy-chain USB hubs (in fact, you'll want to just because of power issues on the Raspberry Pi, right?). So the number would be somewhere between 1 and N. N is a variable based on all of the factors mentioned above as well as the Raspberry Pi's ability to handle all of the simultaneous programs and memory needed (web server, compiler, I/O buffers, loader, terminal to the QS's, etc.). Having just 256 or 512 MB memory as Rev 1 & 2 RPi's do, will mean only a small number of simultaneous edit/compile/load/run actions (I assume).
Sorry, not much of an answer, but testing should give an idea of throughput of these executions on the RPi.
To clarify, though the point is to bring the education experience of the Propeller to the iPad mobile platform, we're not necessarily saying C only and also not saying iPad only. Ideally, it would be a solution that doesn't shut the door on other possibilities, including Spin/PASM and perhaps icon-based programming too.
I will be more interested in Pads when they become more like computers.
Until then, the laptop rules.
A serial port of two would solve a lot of problems.
If you had a board to adapt the Prop QuickStart to the Rpi - call it a "Quickstart2Pi" or something, you could use the serial port on the 26pin header. (ttyAMA0). You would have no cable in that case, and not have to worry about the powered hub. Of course this is only good for 1-Rpi to 1 Quickstart - which I'm sure the kids and teachers getting this would prefer anyways.. BTW if such a board existed, I'd buy 3 or 4 today
Never mind the "Quickstart2Pi", that is an expensive adapter that does nothing.
What we need is a Quickstart like board that mounts directly on the Raspi GPIO headers. A "Propeller Plate". The Prop being programmable directly via the UART on the Raspi header.
Well, it is just a reference point as going wireless (WiFi, XBee, etc.) is more likely a goal...
I think supporting both methods will be important - the cabled approach is easier to trouble shoot, and is common with a PC flow.
As the USB nodes connect and remove, does that require a script change for each change in COMx that appears ?
If a class limited to one USB host, could all QS boards be made to appear as the same COMx (one at a time, of course) ?
Could something like 'send to most recently connected' be made to work, in one script ?
These flows are for the download-verify-remove programming model.
For the download-verify-terminal-connect programming model, it might be easiest to manage if each QS target could somehow Student (or Board ID) & script tag ?
Never mind the "Quickstart2Pi", that is an expensive adapter that does nothing.
What we need is a Quickstart like board that mounts directly on the Raspi GPIO headers. A "Propeller Plate". The Prop being programmable directly via the UART on the Raspi header.
That's likely a moderatey small PCB variation, and a good idea for Slave-applications, but it does expose the Pi more to ham-fisted abuse, so is a little less suited to a class/teaching setup.
It would be a great advanced project pairing.
After being away from this for a few days, I thought I'd jump back in. When I left it I was suggesting a web interface as something universal you could do on an iPad and not run afowl of the Apple app nazis.
I've actually become a MFi shop, and can buy BT interfaces for my own use with iPads, but that if I ever wanted to sell one or even give one away, yikes someone comes knocking at the door.
While the RPi is definately cheap, I'm not sure its the way to go. I was thinking that we had to send a lot of data back and forth which means a USB serial is ideal. BUT with the Prop that is not really true, as the Prop is filled up when it hits 32K and that really isn't much data at all. Maybe the audio link is the way to go, and you can pair with BT to "headset" devices.
How about a Prop that looks like a "headset". Ahh brings back the fond memories of programming from cassettes. See there are really no new ideas, just rediscovered ones.
If the solution really is a server, then I'll point back at a really KISS solution we did at Corvus Systems in the 1980s. It was called the multiplexer, and basically it had 1 "server" connection, in this case to a hard drive, and then 8 connections to in this case Apple IIs (mostly) and all the mux did was to connect 1 Apple to the 1 disk at a time, then after some time move onto the next. Pretty dirt simple, and it got sold in a lot of schools back then. We even made a follow on firmware upgrade version so you could stack multiplexers, to get to 64 computers.
Just a test of running WebIDE in a web browser, editing, compiling and loading .spin code onto a QuickStart which is attached to a RaspberryPi. Proof of concept somewhat as it's just a simple .spin program without external objects, etc... Could have made the project a little more complex with objects or even used a C project with libraries, but wanted to quickly run this test.
Simple test:
Web Browser to WebIDE, which is running on Raspberry Pi
Create/edit .spin example code
Create simple Python compile/load script:
launches openspin to compile .spin to byte-code .eeprom file
launches propeller-load to upload .eeprom file to QS
runs uploaded code on QS
Run Python compile/load script, display Terminal
Propeller QuickStart is linked with USB cable to Raspberry Pi (via powered USB hub)
I accessed the IDE from another location, created .spin & .py scripts, compiled, loaded & ran my test on the QS.
I'll re-test via my 1st gen iPad later, but should just work (with the "normal" difficulties of using a tablet for source code input )... I do have a Bluetooth keyboard that should make it less painful.
I will be more interested in Pads when they become more like computers.
Ah, that's never gonna happen. In fact as you may have noticed, both recent Windows and Mac OS X system versions look more like tablet OSes. I think the paradigms for computing are changing in general and what we're all used to now in Desktop, Laptop and even Tablet computing is going to go by the wayside. The "desktop" as it were, was what we were familiar with and that became the paradigm for personal computing. Our kids can't relate to rolodex, paper calendars, HP & TI calculators, yellow sticky pads and even the pencil. Those and many other "simulations" of the real world are going away in computing.
I think supporting both methods will be important - the cabled approach is easier to trouble shoot, and is common with a PC flow.
As the USB nodes connect and remove, does that require a script change for each change in COMx that appears ?
If a class limited to one USB host, could all QS boards be made to appear as the same COMx (one at a time, of course) ?
Could something like 'send to most recently connected' be made to work, in one script ?
These flows are for the download-verify-remove programming model.
For the download-verify-terminal-connect programming model, it might be easiest to manage if each QS target could somehow Student (or Board ID) & script tag ?
As the USB nodes connect and remove, does that require a script change for each change in COMx that appears ?
USB Nodes: propeller-load has the -P option that returns available ports. Of course, the returned name (unlike on Mac OS X) is fairly generic and does not include any serialized naming that a student or instructor could associate with a particular Prop board or robot. (Since we are discussing having the Prop board itself maintain some sort of loading method, it could also have a sort of "ping" that returns an identifier... (???)
If a class limited to one USB host, could all QS boards be made to appear as the same COMx (one at a time, of course) ?
If Raspberry Pi reuses the ttyAMA0 identifier, I guess that would work...
Could something like 'send to most recently connected' be made to work, in one script ?
These flows are for the download-verify-remove programming model.
Good question. The Python script I wrote was very simple. I would think that a robust script could do a lot more, provide preference setting, arguments to the executable, etc... So, yeah that's all possible.
For the download-verify-terminal-connect programming model, it might be easiest to manage if each QS target could somehow Student (or Board ID) & script tag ?
That's what I was thinking, too...
I'm not so sure that WebIDE itself is the IDE that should be used, but just happens to exist and work at some level. It's editor is very limited, it only works with a few web browsers well and it's not extensible to support Propeller-specific needs. But, it sure makes testing the Raspberry propeller tools easy
USB Nodes: propeller-load has the -P option that returns available ports. Of course, the returned name (unlike on Mac OS X) is fairly generic and does not include any serialized naming that a student or instructor could associate with a particular Prop board or robot. (Since we are discussing having the Prop board itself maintain some sort of loading method, it could also have a sort of "ping" that returns an identifier... (???)
If students can list ports, I guess they can infer which one(s) are theirs, in the most basic setup.
With multiple boards and students, a verify message that could include a Board ID ping of some sort, would seem a very good idea.
I'm not so sure that WebIDE itself is the IDE that should be used, but just happens to exist and work at some level. It's editor is very limited, it only works with a few web browsers well and it's not extensible to support Propeller-specific needs. But, it sure makes testing the Raspberry propeller tools easy
Getting something working, that is simple, is a very good first step.
I guess WebIDE is rather like a Gmail, (or a forum editor ) - nothing fancy, but can give base-operation.
I would go xbee serial form the robot programming. One programmer/server machine can redirect itself to specifically address any number of individual xbee connected propeller robots, you just change the destination code. The Pi isn't a very good microcontroller, but it IS a very good embedded computer.
Drat! You beat me to the finish! This where I was headed yesterday afternoon until I got sidetracked!
We'll done!!
I had all the pieces already together (propgcc, SimpleIDE, OpenSpin) on the RPi thanks to the forums... So, it was real easy.
For anyone attempting to use WebIDE from an iPad or Android tablet, you might run across the following:
At this time there's a problem with using my 1st gen iPad to access WebIDE with either Safari or Chrome browsers. Newer iPads that can run the latest iOS may not have these issues:
1. Cursor is not displayed over the correct character, making editing difficult. Typing is not a problem but deleting intended characters is a real chore.
2. Selecting portions (whole words, variables, etc.) of text is difficult
3. Some of WebIDE's functions are not accessible on the iPad (possibly not on other tablets as well). Not able to Control-click, or right/left click on file names (required to edit file names and for other functionality).
4. Terminal area does not always display bottom lines of text after scrolling. Making Terminal use difficult after a few edits.
5. WebIDE loses track of user config each time Terminal is redisplayed (loses my $PATHS environment variable as well as anything in .profle. Have to "source" .profile each invocation)
6. A Bluetooth keyboard only works partially with WebIDE on iPad. Sometimes I'm able to edit text, other times no text shows up when typing on the keyboard. After running my compile script, I'm no longer able to use the Bluetooth keyboard until I've reset the project (exit the project directory and then return to it to reset).
Other things to note:
WebIDE execs your Python and other executables (scripts, compiled code, etc.) as the user "webide", which does not have admin privileges unless you change them on your RPi. You need to add the user "webide" to the shudders list and add all the normal groups that user, as well.
The "webide" user's home is in the directory: "/usr/share/adafruit/webide/" NOT "/home/webide/"
I would go xbee serial form the robot programming. One programmer/server machine can redirect itself to specifically address any number of individual xbee connected propeller robots, you just change the destination code. The Pi isn't a very good microcontroller, but it IS a very good embedded computer.
That's true of Linux/Unix/OSX/Windows in any case at some level... Whether a wireless or wired interface is used, one can always come up with a way to ID different devices. Since it appears that the intention is to run a loader on the Prop board and upload executables to an SD card (or some other form of storage)via that loader, it could dispatch a unique ID when pinged by the RPi (or other suitable server).
I think the transport method(s) used in the end should be whatever works best for the user (Educators, students, etc.). But, developer types, like the folks on this forum can use USB Serial (or other serial comms) now for development and testing. It's also very fast and does not require any additional comm-specific code on the Prop board for testing.
Let me throw one more configuration into this mix...
Instead of doing the data entry via the touchscreen, if the user has direct access to the connected USB keyboard/mouse, then load x11vnc which shares the local user input with the session.
You win the Internet for the rest of the day. I'm not kidding.. It's yours. Every webserver, router, and fiber line until Midnight tonight.
That is almost EXACTLY what I had envisioned here. Wonder what it would take to get some proper syntax highlighting for Spin in WebIDE?
Jeff
Really, all the work was done by others (propgcc, SimpleIDE and OpenSpin on Raspberry Pi). I just used what existed after reading everyone's ideas (good engineers copy, the best engineers steal, right? :thumb:)
Yeah, syntax highlighting and a lot of other code editing features for Spin, C, C++, JavaScript, Python, etc. would be great!
But, maybe WebIDE is just a good prototype for a Propeller-specific web-based IDE. I think Heater mentioned something about C++ to JavaScript porting exists. Maybe SimpleIDE could be wrangled out of Qt (Jazzed, would that be an option?)
Let me throw one more configuration into this mix...
Instead of doing the data entry via the touchscreen, if the user has direct access to the connected USB keyboard/mouse, then load x11vnc which shares the local user input with the session.
Jeff
I didn't intend to ever use my iPad's touchscreen for text entry. Not enough patience for that...
Not sure where you mean to use x11vnc. On the tablet? Or on the RPi? What config do you mean (I can probably test it)?
I do use ssh with the -X (X11) option to get RaspberryPi's graphic UI on my Mac, which is running XQuartz (X11 for Mac OS X) for testing SimpleIDE (my RPi is located in the laundry room). Suppose I could have run an X11 variant on my iPad for that as well.
At this time there's a problem with using my 1st gen iPad to access WebIDE with either Safari or Chrome browsers. Newer iPads that can run the latest iOS may not have these issues:
How does that combination(s) work with gmail compose-mail text editor, or this forum's reply editor ?
One issue I discovered when attampting to write a browser-based program editor (http://forums.parallax.com/showthread.php/132690) is that data persistence is a problem if you close the browser or the tab/window the editor appears in. It's one reason I like Google's "Packaged Apps" approach, which provides a persistent backend divorced from the browser itself and which is capable of writing files on the client system, rather than having to upload text to the server for saving.
Maybe SimpleIDE could be wrangled out of Qt (Jazzed, would that be an option?)
Personally, I think any web based IDE will have to be from a different code base than SimpleIDE. That doesn't mean that it's a completely different track, though. All the experience and discussions that Jazzed and Parallax have had on what is needed for an IDE in general will apply, and will make it much easier for Parallax on a second time around the IDE merry go round.
How does that combination(s) work with gmail compose-mail text editor, or this forum's reply editor ?
WebIDE seems to have a much more difficult time with the iPad's lack of a mouse/trackpad and a way to handle right-click/control-click actions. The cursor problem actually shows up on Safari and Chrome on Mac OS X, as well. That may be a WebKit issue for WebIDE.
But, yes I've had a few issues editing this forum's posts with the iPad as well, because o the lack of the "special" combo-key or multi-mouse-button gestures.
We started discussing some new IDE item possibilities and this thread appears to be part of that conversation.
Just a thought, really. A web-based IDE that has many of the same features of SimpleIDE. Instead of creating a whole new interface for propgcc code development, why not one with a UI like SimpleIDE?
Ok, how about this. Since our audience is the classroom, we don't have to worry about supporting complex configurations like different memory models like simpleide does. It can be fairly basic and should be based on C. If someone wants to do spin, basic, Fortran or forth, they can do it from a real computer.
I'm starting to lean towards a graphical web based language over a text one. The drag and drop approach might be pretty good on a tablet browser.
Not sure where you mean to use x11vnc. On the tablet? Or on the RPi? What config do you mean (I can probably test it)?
dgately
I used a VNC viewer on my android to connect to the Raspberry Pi, do an apt-get install x11vnc on the RaspPi, then run it from inside Xwindows on the Raspberry Pi.
Naturally, you can used Midori at that point to access the same WebIDE from 127.0.0.1.
Edit: the objective with this configuration is to use the tablet as a screen, while maintaining the use of USB connected keyboard and mouse on the Pi.
I'm still trying to get the SimpleIDE and OpenSpin working. (Would love it if you could elaborate on this)
Comments
Simple test:
Create simple Python compile/load script:
launches propeller-load to upload .eeprom file to QS
runs uploaded code on QS
Propeller QuickStart is linked with USB cable to Raspberry Pi (via powered USB hub)
I accessed the IDE from another location, created .spin & .py scripts, compiled, loaded & ran my test on the QS.
I'll re-test via my 1st gen iPad later, but should just work (with the "normal" difficulties of using a tablet for source code input
dgately
Sounds like a great reference point.
How many QS boards could this connect to, potentially ?
Either by using the hub outlets, or by simple plug-sharing, in an ad-hoc way ?
Well, it is just a reference point as going wireless (WiFi, XBee, etc.) is more likely a goal...
USB 2.0 itself supports how many nodes (128)? Linux will support a non-infinite number of USB-serial ports (I assume). Raspberry Pi will support "in reality" some smaller number of ports. You can daisy-chain USB hubs (in fact, you'll want to just because of power issues on the Raspberry Pi, right?). So the number would be somewhere between 1 and N. N is a variable based on all of the factors mentioned above as well as the Raspberry Pi's ability to handle all of the simultaneous programs and memory needed (web server, compiler, I/O buffers, loader, terminal to the QS's, etc.). Having just 256 or 512 MB memory as Rev 1 & 2 RPi's do, will mean only a small number of simultaneous edit/compile/load/run actions (I assume).
Sorry, not much of an answer, but testing should give an idea of throughput of these executions on the RPi.
dgately
I will be more interested in Pads when they become more like computers.
Until then, the laptop rules.
A serial port of two would solve a lot of problems.
Edit: I suppose power might be an issue though.
What we need is a Quickstart like board that mounts directly on the Raspi GPIO headers. A "Propeller Plate". The Prop being programmable directly via the UART on the Raspi header.
I think supporting both methods will be important - the cabled approach is easier to trouble shoot, and is common with a PC flow.
As the USB nodes connect and remove, does that require a script change for each change in COMx that appears ?
If a class limited to one USB host, could all QS boards be made to appear as the same COMx (one at a time, of course) ?
Could something like 'send to most recently connected' be made to work, in one script ?
These flows are for the download-verify-remove programming model.
For the download-verify-terminal-connect programming model, it might be easiest to manage if each QS target could somehow Student (or Board ID) & script tag ?
That's likely a moderatey small PCB variation, and a good idea for Slave-applications, but it does expose the Pi more to ham-fisted abuse, so is a little less suited to a class/teaching setup.
It would be a great advanced project pairing.
You win the Internet for the rest of the day. I'm not kidding.. It's yours. Every webserver, router, and fiber line until Midnight tonight.
That is almost EXACTLY what I had envisioned here. Wonder what it would take to get some proper syntax highlighting for Spin in WebIDE?
Jeff
I've actually become a MFi shop, and can buy BT interfaces for my own use with iPads, but that if I ever wanted to sell one or even give one away, yikes someone comes knocking at the door.
While the RPi is definately cheap, I'm not sure its the way to go. I was thinking that we had to send a lot of data back and forth which means a USB serial is ideal. BUT with the Prop that is not really true, as the Prop is filled up when it hits 32K and that really isn't much data at all. Maybe the audio link is the way to go, and you can pair with BT to "headset" devices.
How about a Prop that looks like a "headset". Ahh brings back the fond memories of programming from cassettes. See there are really no new ideas, just rediscovered ones.
If the solution really is a server, then I'll point back at a really KISS solution we did at Corvus Systems in the 1980s. It was called the multiplexer, and basically it had 1 "server" connection, in this case to a hard drive, and then 8 connections to in this case Apple IIs (mostly) and all the mux did was to connect 1 Apple to the 1 disk at a time, then after some time move onto the next. Pretty dirt simple, and it got sold in a lot of schools back then. We even made a follow on firmware upgrade version so you could stack multiplexers, to get to 64 computers.
We'll done!!
Just saying...
dgately
As the USB nodes connect and remove, does that require a script change for each change in COMx that appears ?
If a class limited to one USB host, could all QS boards be made to appear as the same COMx (one at a time, of course) ?
Could something like 'send to most recently connected' be made to work, in one script ?
These flows are for the download-verify-remove programming model.
For the download-verify-terminal-connect programming model, it might be easiest to manage if each QS target could somehow Student (or Board ID) & script tag ?
I'm not so sure that WebIDE itself is the IDE that should be used, but just happens to exist and work at some level. It's editor is very limited, it only works with a few web browsers well and it's not extensible to support Propeller-specific needs. But, it sure makes testing the Raspberry propeller tools easy
dgately
If students can list ports, I guess they can infer which one(s) are theirs, in the most basic setup.
With multiple boards and students, a verify message that could include a Board ID ping of some sort, would seem a very good idea.
Getting something working, that is simple, is a very good first step.
I guess WebIDE is rather like a Gmail, (or a forum editor ) - nothing fancy, but can give base-operation.
I had all the pieces already together (propgcc, SimpleIDE, OpenSpin) on the RPi thanks to the forums... So, it was real easy.
For anyone attempting to use WebIDE from an iPad or Android tablet, you might run across the following:
At this time there's a problem with using my 1st gen iPad to access WebIDE with either Safari or Chrome browsers. Newer iPads that can run the latest iOS may not have these issues:
2. Selecting portions (whole words, variables, etc.) of text is difficult
3. Some of WebIDE's functions are not accessible on the iPad (possibly not on other tablets as well). Not able to Control-click, or right/left click on file names (required to edit file names and for other functionality).
4. Terminal area does not always display bottom lines of text after scrolling. Making Terminal use difficult after a few edits.
5. WebIDE loses track of user config each time Terminal is redisplayed (loses my $PATHS environment variable as well as anything in .profle. Have to "source" .profile each invocation)
6. A Bluetooth keyboard only works partially with WebIDE on iPad. Sometimes I'm able to edit text, other times no text shows up when typing on the keyboard. After running my compile script, I'm no longer able to use the Bluetooth keyboard until I've reset the project (exit the project directory and then return to it to reset).
Other things to note:
WebIDE execs your Python and other executables (scripts, compiled code, etc.) as the user "webide", which does not have admin privileges unless you change them on your RPi. You need to add the user "webide" to the shudders list and add all the normal groups that user, as well.
The "webide" user's home is in the directory: "/usr/share/adafruit/webide/" NOT "/home/webide/"
Compile, load .spin and execute on QuickStart:
dgately
That's true of Linux/Unix/OSX/Windows in any case at some level... Whether a wireless or wired interface is used, one can always come up with a way to ID different devices. Since it appears that the intention is to run a loader on the Prop board and upload executables to an SD card (or some other form of storage)via that loader, it could dispatch a unique ID when pinged by the RPi (or other suitable server).
I think the transport method(s) used in the end should be whatever works best for the user (Educators, students, etc.). But, developer types, like the folks on this forum can use USB Serial (or other serial comms) now for development and testing. It's also very fast and does not require any additional comm-specific code on the Prop board for testing.
dgately
Let me throw one more configuration into this mix...
Instead of doing the data entry via the touchscreen, if the user has direct access to the connected USB keyboard/mouse, then load x11vnc which shares the local user input with the session.
Jeff
Yeah, syntax highlighting and a lot of other code editing features for Spin, C, C++, JavaScript, Python, etc. would be great!
But, maybe WebIDE is just a good prototype for a Propeller-specific web-based IDE. I think Heater mentioned something about C++ to JavaScript porting exists. Maybe SimpleIDE could be wrangled out of Qt (Jazzed, would that be an option?)
dgately
I didn't intend to ever use my iPad's touchscreen for text entry. Not enough patience for that...
Not sure where you mean to use x11vnc. On the tablet? Or on the RPi? What config do you mean (I can probably test it)?
I do use ssh with the -X (X11) option to get RaspberryPi's graphic UI on my Mac, which is running XQuartz (X11 for Mac OS X) for testing SimpleIDE (my RPi is located in the laundry room). Suppose I could have run an X11 variant on my iPad for that as well.
dgately
How does that combination(s) work with gmail compose-mail text editor, or this forum's reply editor ?
Wrangled to where?
We started discussing some new IDE item possibilities and this thread appears to be part of that conversation.
-Phil
Personally, I think any web based IDE will have to be from a different code base than SimpleIDE. That doesn't mean that it's a completely different track, though. All the experience and discussions that Jazzed and Parallax have had on what is needed for an IDE in general will apply, and will make it much easier for Parallax on a second time around the IDE merry go round.
WebIDE seems to have a much more difficult time with the iPad's lack of a mouse/trackpad and a way to handle right-click/control-click actions. The cursor problem actually shows up on Safari and Chrome on Mac OS X, as well. That may be a WebKit issue for WebIDE.
But, yes I've had a few issues editing this forum's posts with the iPad as well, because o the lack of the "special" combo-key or multi-mouse-button gestures.
dgately
Just a thought, really. A web-based IDE that has many of the same features of SimpleIDE. Instead of creating a whole new interface for propgcc code development, why not one with a UI like SimpleIDE?
Just putting it out there!
dgately
I'm starting to lean towards a graphical web based language over a text one. The drag and drop approach might be pretty good on a tablet browser.
I used a VNC viewer on my android to connect to the Raspberry Pi, do an apt-get install x11vnc on the RaspPi, then run it from inside Xwindows on the Raspberry Pi.
Naturally, you can used Midori at that point to access the same WebIDE from 127.0.0.1.
Edit: the objective with this configuration is to use the tablet as a screen, while maintaining the use of USB connected keyboard and mouse on the Pi.
I'm still trying to get the SimpleIDE and OpenSpin working. (Would love it if you could elaborate on this)
Jeff