lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] UI for non-traditional platforms (was: Group premium quotes: U


From: Vadim Zeitlin
Subject: Re: [lmi] UI for non-traditional platforms (was: Group premium quotes: UI)
Date: Fri, 23 Oct 2015 23:44:06 +0200

On Fri, 23 Oct 2015 21:25:25 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2015-10-23 15:05, Vadim Zeitlin wrote:
GC> > On Fri, 23 Oct 2015 01:46:30 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> The BYOD era has begun; should we be targeting some
GC> > GC> new platform instead?
GC> > 
GC> >  Just in case it wasn't a rhetorical question, I think we should, if we
GC> > can. It's "just" a question of resources, but ideally, i.e. if the
GC> > resources were unlimited, any GUI application nowadays should support at
GC> > least the following platforms:
GC> > 
GC> > 1. Classic MSW
GC> > 2. OS X
GC> > 3. Linux/other Unices
GC> > 4. Android
GC> > 5. iOS
GC> > 6. UI-formerly-known-as-Metro for modern MSW versions
GC> > 7. HTML5 for everything else
GC> > 
GC> >  Now I have no idea whether lmi users priorities are, all I can say is 
that
GC> > supporting 4-7 is not going to be simple. (6) would probably be the least
GC> > onerous platform to target and also arguably of most interest for lmi, but
GC> > even it would require a lot of work.
GC> 
GC> I've already used lmi on (1) and (3), and presumably (2) either works
GC> already or would not be very difficult. But could we cover the other
GC> platforms at least temporarily by doing something in even an ancient
GC> version of HTML and declaring that the browser is the platform? We
GC> do have some very old CGI-BIN code, but we can't ask all users to run
GC> a webserver.

 No, which is why it has to be done inside the browser, entirely on the
client side. And this is what I meant by "HTML5" in (7) above, except, of
course, "HTML5" is actually 10% of HTML, 20% of CSS and 70% of JavaScript
(or, if you want to preserve your sanity, something that "transpiles" to
JavaScript, e.g. TypeScript or Dart or whatever -- anything is better than
raw JavaScript IMHO). It's probably doable, but it's a huge work and it
won't have the same performance as C++ (although JavaScript can be
surprisingly good from this point of view). An intriguing possibility could
be to embed C++ code in JavaScript using e.g. SWIG but I had never done
this before, so I'm not sure if this could be made to work e.g. under
Android. In any case, the UI would need to be completely rewritten, of
course.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]