I wonder how far you could get with OneRemote.
I hope we can work on WebGizmo a little sometime soon, so I'd be grateful to hear what limitations you have found.
Thanks.
The main limitation with using OneRemote in this application is that (as far as I know?) it only runs on Android. The raspberry pi and many other little ARM boards can't run android (in some cases not at all, in some cases not in a usable way), they just run plain vanilla linux (like the Id). Some dev boards can run android, but if I were using a device that could run android, there are already two very nicely developed touchscreen JRiver apps already available (jremote and gizmo)
So on devices that can run android, there are lots of options. And on windows there's theater view which works great on my Surface Tablet. However, on vanilla Linux there's nothing but webgizmo, which has definite limitations on a touchscreen. If you were looking for specifics, here are the biggest issues I hit using webgizmo as a touch interface daily on a raspberry pi for about six months:
1) Unlike android gizmo, in webgizmo there is no load-on-demand infinite scrolling. Album views are broken up into pages with 40 or 50 albums per page. To switch pages you need to touch-press a fairly small hyperlinked number button at the bottom of the page. Additionally, only four or five numbers are available for press at any one time (the rest are ellipsized, like 1, 2, 3 ... 45). Android Gizmo and theater view both handle this through infinite scrolling, which would be nice for webgizmo. Barring infinite scrolling (which would be ideal), larger, easy to press page buttons would be better, although if that's the solution, it would also be nice to have an alphabet (like in standard view). As it is there's no good way to browse a large collection with webgizmo on a touch screen. To offer a concrete example, my music collection "album view" gets split across 50+ pages, and because the page numbers are ellipsized, getting to the "middle" of the collection is pretty hard. It requires two dozen clicks and page loads to get to the "M's"!
2) Unlike android, common desktop web browsers are not perfectly touch optimized. Many browsers (at least the the ones that run well on a raspberry) handle a touch screen by effectively treating it like a mouse. This means "touch and grab" android style scrolling does not work, you have to use the browser scroll bars. That makes scrolling even within the view pages challenging, as one has to grab the tiny browser scroll bar and drag it. By contrast, Android Gizmo provides a nice large "grab bar" for assisted scrolling once you start scrolling. An always-visible "grab bar" (like the one that appears on Android Gizmo, but always on) would be very nice to have in webgizmo.
3) Unlike an android phone, the touchscreens I'm dealing with have no dedicated "back" button (many non-android tablets like the MS surfaces also lack such a button). Webgizmo has no touch-friendly way to emulate this "back" function within the interface. One can, of course, use the browser's "back" button, but in an appliance-type setting you don't want the browser chrome to be visible/accessible to a user (they could break things), you want the "app" to run fullscreen and be self-contained. The lack of such a function within the interface makes navigation tough in full-screen. Once you've gone down a level, your only option is to go all the way back to the top, which (combined with the above mentioned paged-view navigation) means that a single mispress can force you to start over on a chain of 10 or 15 clicks. Gizmo for android relies on the fact that all android phones have a back button, but, a better example is theater view. I use theater view on a windows tablet with no keyboard or back button and it works great because theater view always includes a way to move back up one level (through the rollers). I definitely don't think webgizmo needs rollers, but it would be nice if webgizmo had an onscreen way to either do what the browser "back" button does or just move up one level in the view hierarchy. Even just doing it the way Kodi does by making the first item in any view be "up one level" would do the trick.
4) This is a cosmetic issue, but it bothers me, so I thought I'd mention it. The album cover thumbnails retrieved and displayed in android gizmo look nice and sharp, with no visible artifacts. Often, the exact same album art in webgizmo appears to include artifacts or aliasing. I'm not sure why that would be the case, but it's pretty easy to see if you look at the same album art in android gizmo and then in webgizmo on a browser on the same device. Art with large red or pink color fields seems to show it most prominently.
I've been tinkering with OneRemote and it seems to be coming along nicely, but it appears to be using the webgizmo backend? In any case, the same limitations with webgizmo appear to be present in OneRemote so far: paged scrolling, small numbers to change pages, no onscreen way to go up one level or back, aliasing in the album art etc. (although things are made somewhat easier in the android context by the presence of a hardware back button and native touch scrolling, etc.).
Gizmo and JRemote are both fantastic and hard to beat as dedicated media interfaces in the android setting though, they're very polished. In the desktop space theater view is also excellent. Any improvements to webgizmo to make it closer to those interfaces and/or more "touch friendly" would be greatly appreciated, although if/when theater view lands on linux it will solve most of these problems. In any case, I hope this helps, and I appreciate the chance to offer input