On Wed, 2011-03-02 at 20:55 +0100, Stefano D'Angelo wrote:
> 2011/3/2 David Robillard <d@email-addr-hidden>:
> > On Wed, 2011-03-02 at 19:31 +0100, Olivier Guilyardi wrote:
> >> On 03/02/2011 06:32 PM, David Robillard wrote:
> >>
> >> > Why you are trying to pick apart web UIs in the same email as you're
> >> > arguing where one size does not fit all I don't know... I want a remote
> >> > control that works on any device out of the box. It's about as blatantly
> >> > obvious as anything can be that web is literally the only way to go for
> >> > that, because the browser is actually on those devices. QED.
> >> >
> >> > Do I think /all/ desktop PC hosts and plugin should use it? No. It's for
> >> > "remote control" things (even if not remote). Is GL good? Yes. I sure
> >> > wish I used it for the Ingen canvas. Has anyone actually showed up yet
> >> > who wanted to write a GL UI? No. Unless you're one, talking about it is
> >> > a waste of time.
> >>
> >> My Android audio application is GL based. Right now I see things from a host
> >> developer, and am wondering how third-party plugin UIs could integrate into my
> >> app. Plugin support is in my plans. Of course I will generate the UIs by myself
> >> from the ports data, but I think that specific well-design UIs could be nice in
> >> some cases.
> >>
> >> It seems to me like we are talking about different things. You give a lot of
> >> importance to remote control, why my concern is "$subject on native hosts". And
> >> you seem to agree that a Web UI is not necessarily adapted for a PC host.
> >
> > Yep.
> >
> >> Right now, all my plans for audio software on mobile platforms involve GL and
> >> highly interactive interface. If there was a way to create plugin UIs which are
> >> portable on both desktops and mobile systems, then it could result in plenty of
> >> attractive plugins arriving on Android and others. But this is only important
> >> for fancy UIs. The UI can be generated from ports and groups in other cases as
> >> Paul mentioned. I don't need no HTML stuff for that.
> >
> > I would much rather all the UIs be based on GL than a bunch of different
> > toolkits, but toolkits solve all the problems required (e.g. input), and
> > GL solves a tiny part of it, and people in this community know the
> > toolkits. So here we are.
> >
> >> Also, I am mainly brainstorming and sharing some of the knowledge I acquired
> >> while doing mobile development. I don't think that I can really help with the
> >> long-term design choices that you need to make in the context of LV2. But I hope
> >> that sharing my point of view shred a little light :)
> >
> > UI types aren't pressing decisions (a point that this list in general
> > loves to miss lately...). The UI extension is toolkit agnostic for this
> > reason. Maybe some day someone will make GL plugin UIs. Maybe not.
> > Whatever.
>
> No no and no, this won't be settled down this easy. :-)
Wanna bet?
/me goes back to doing something more useful than the perennial l-a-d UI
bikeshedding thing
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Mar 3 00:15:04 2011
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2011 - 00:15:04 EET