Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: What's the best non-JVM native language to look at? Date: Mon, 20 Jan 2014 21:39:39 +0000 (UTC) Organization: A noiseless patient Spider Lines: 91 Message-ID: References: <428f8206-d4f7-4fe6-b93c-8f881b498be6@googlegroups.com> <52db211d$0$304$14726298@news.sunsite.dk> <52dc4c29$0$301$14726298@news.sunsite.dk> <52dc71c3$0$295$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Mon, 20 Jan 2014 21:39:39 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="32140"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18XXyxLOgmFicBcOWbML1Ay2F14Gf9Y58w=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:TGYyDulbWhX00S//ijj059Zf1GA= Xref: csiph.com comp.lang.java.programmer:27362 On Sun, 19 Jan 2014 19:45:53 -0500, Arne Vajhøj wrote: > On 1/19/2014 6:44 PM, Martin Gregorie wrote: >> On Sun, 19 Jan 2014 17:05:26 -0500, Arne Vajhøj wrote: >> >>> Isn't that exactly what MS did with WinRT? >>> >> Thats what they *said* they did, but apparently what they said and what >> they did are not the same. >> >> Its not impossible: its only a matter of providing the same[*] API in >> an ARM box as is already implemented in an X86 box. Proof that this is >> quite possible is given by the seamless port of Debian Linux and the >> GNU C compiler toolset to the RaspberryPi (ARM) from the PC (X86). I >> know, because I've done it with both my own and some 3rd party >> packages, that you can use cvs to checkout a set of sources and >> makefiles from a PC running Linux to an RPi running Raspbian (the >> Debian port) and compile it without changing anything that was checked >> out. If the tiny Raspberry Pi Foundation can make this work, than >> Microsoft certainly should be able to do the same. >> >> [*] 'same' as in functionally identical interfaces after compiling them >> on any of the target hardware. >> >>> But I am not sure that it matters so much. Any attempt to use the same >>> UI on a phone and a PC will fail miserable. >>> >> Why do you say that? There's absolutely no excuse for file system APIs >> to differ > > ???? > > Isn't that what Windows.Storage.Streams.FileInputStream, > Windows.Storage.Streams.FileOutputStream and the rest provide? > >> If your OS exposes a set of, say, APIs to manage a graphical >> display, that should work on all hardware regardless of whether the >> code implementing the system side of the API is the same on all >> hardware or not. In fact I'd expect the system code to differ in order >> to do something sensible with the different screen sizes, pixel size >> and colour palettes supported by target hardware and to hide >> differences between a single-touch screen and a mouse. Again, this is >> nothing new. the X system works perfectly well on the RPi and can >> easily handle different screen sizes and resolutions. I can easily run >> code written for a WinCE-based PNA on a Windows box after its been >> recompiled. Actually its running on a remote Linux box under Wine and >> using my Linux laptop's display: the window it presents on the laptop >> is a lot bigger than the PNA's screen, but it has the same aspect ratio >> and much better resolution and, given that mouse clicks and drags and a >> keyboard are used instead of the single touch PNA screen with a >> graphical keyboard, inputs works exactly the same too. > > ???? > > The menus of a modern PC app is useless on a phone. > Sure - I'm not saying they should be the same, only that I don't see any reason why a program shouldn't use the same API to display menus and accept input from them regardless of how the OS chooses to display the menus. After all, a program that is useful on a desktop, tablet or phone will need to display the same menus and accept the same inputs from them regardless of which device its running on. Similar arguments apply to all the other elements of a graphical interface. Now that the idea of letting a desktop graphical program work with more than one window has virtually disappeared (apart from one or two exceptions like the GIMP) it should be even easier to port such an application provided only that the API remains the same, its window is allowed to occupy the whole of a small screen and that graphical elements are allowed to overlay each other on the smallest screens, i.e. while a menu may be a top bar with drop-down submenus on a desktop or tablet, on a phone the menu and submenus would overlay each other exactly as they do at present on some phones. The application does not need to know how the graphical screen manager has arranged them on screen: thats can be taken care of by the OS. > That is not something I am making up. > Agreed. > Try comparing how web browsers look on PC and phone. > See above. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |