Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing app in web browsers #33

Open
ghost opened this issue Jul 28, 2013 · 6 comments
Open

Testing app in web browsers #33

ghost opened this issue Jul 28, 2013 · 6 comments

Comments

@ghost
Copy link

ghost commented Jul 28, 2013

Is it possible to view control in a web browsers (chrome for example) ?
Would make it a lot easier when it comes to testing when using something like Ripple Emulator.

In the console log of chrome I get:
Viewport argument value "med-dpi" for key "target-densitydpi" is invalid, and has been ignored.

Viewport target-densitydpi is not supported.

@charlieroberts
Copy link
Owner

No, but using Weinre to do remote debugging is pretty painless. If you want a browser-based solution give Interface.js a whirl...

http://www.charlie-roberts.com/interface
https://github.com/charlieroberts/interface.js

@ViktorNova
Copy link

WOW I had no idea about Interface.js! I have tried a few times myself to run Control in a browser without success, wanting to run it on the desktop and this is just awesome.. I'm from the Linux world and we really need a native OSC control interface that isn't clunky, I'm stoked

How similar are interface.js and Control as far as the user experience goes, or rather what would you say the key differences are?

@charlieroberts
Copy link
Owner

Some differences off the top of my head:

  1. It's easy to test in any browser, using standard debugging tools. This is a big deal for me, and one of the main reasons I moved away from working on Control. It's much quicker to create and debug interfaces using Interface.js
  2. It works in any modern web browser, so, not just limited to iOS and Android.
  3. If you use local IP addresses (such as yourcomputer.local:8080/blah.htm) interfaces can be bookmarked; simply opening the server and launching the bookmark establishes all the needed connections. No need to fiddle about with entering IP addresses or Bonjour after you've typed in the address once and bookmarked it.
  4. Control uses JSON to define interfaces (well, something close to JSON, technically JSON isn't allowed to include JavaScript functions) while Interface.js uses plain JavaScript.
  5. Interface.js has support for theming and presets.
  6. Interface.js can be added into any web page.

@ViktorNova
Copy link

Wow, so would you say interface.js is really kind of a sucessor to Control? Are there any advantages Control has over interface.js?

@charlieroberts
Copy link
Owner

Control has some fancy stuff built into the development build (not the version in the app store) like computer vision, speech recognition and audio analysis. These are things that web pages can't really do yet.

I forgot another important difference... Safari has much better JavaScript performance for graphics than apps that use Apple's UIWebView class; they say this is for security reasons. But it should mean that widget animations are smoother in Interface.js. Overall, I think the Interface.js is much easier to work with than Control and yes, I consider it a successor.

@ViktorNova
Copy link

Awesome, thank you for expanding on that. And I see you have an official gui editor too! Looks very awesome, I am setting up the server on my linux box now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants