This is a really interesting thread, I haven't learned so much so quickly in awhile!
Hi Chilli I am also in a position where I'm developing a BBB with a touchscreen. I chose python. I hardly ever used python previous to this project and usually choose node.js or ruby which I know pretty deeply through years of web development experience. I chose python because * it has great support for the serial port which I needed fine control over (node-serialport failed, it was my first attempt, I was sad about this because I have to later refactor my python code in a "tickless" or event-driven style when I have time -- I would have "got this for free" if I had been able to use Node.js. Also with Node.js, if my project is a success, I can find an abundance of coders that can wield it, but same can be said for python) * it has a fine webserver built in, cherrypy, this is serving my HTML and Javascript for the "kiosk" * it has a fine websockets library, ws4py, which provides the connection between the python and the kiosk (which uses Chromium's HTML5 WebSocket) So far this working very well for me as my screen is doing normal things, nothing crazy to require OpenGL or SDL or things like that which are more foreign to me. My kiosk is using the following libraries: * Backbone.js (for its minimalism and modularity, although I tend not to use this anymore in "normal" web app development [I tend to write normal web apps in Meteor these days]) In your case you could easily do something like this and the protocol you develop on the websocket wire (or a superset therein) can be (re)used for non-local connections. The same HTML/JS can be reused (and extended) for those non-local connections. best regards, keyvan On Wednesday, March 11, 2015 at 7:01:23 AM UTC-7, Stephan Mulacz wrote: > > > Somehow we came a bit of topic. > Since the thread is already starving I can maybe resurrect it just to > highjack it a bit... > I'm in a similar situation. I want to implement a program on the BBB with > graphics and touch screen. But in the future there should be also a web > interface for remote control. > So I'm still a bit undecided if to implement first a local solution and > add remote support later or if it is better to make only one common GUI > that covers both. > In first case I would very likely make a full featured local GUI with a > c/c++ graphics library and a restricted web GUI later on (maybe with > Mongoose or other web servers). > In latter case (one full featuered GUI) I would probably use another > language. Maybe html5/javascript with library (fabric, knietic, paper...)? > > What would you use if you had to support both, local and web interface? > > Chilli > > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
