On 2016-07-01 12:33, Ben Rubinstein wrote:
That's why I think "it would be better if" the existing basic controls worked reasonably well on mobile platforms, and the existence of the various libraries, widgets, and mobileControlxxx functions - while all of them being extremely valuable - does not, for me, negate that ambition.
If by 'works well' you mean 'look less like they come from the age of the dinosaurs' then I cannot agree more.
The main issue here is that of rendering the iOS/Android 'native themes'. There are no APIs for this on either platform (unlike for Mac, Windows and Linux) so they have to be written by hand using drawing APIs (just as we only had emulated Motif, Mac Classic and Win95 themes before Tuviah added the hooks to use 'native OS API based themes').
Fraser has done some experimentation here to see how this might work - basically it would be a library of LCB handlers which render the different parts of each control using its rich 2D canvas syntax. However, there is a still quite a lot of work to do it before it becomes a feature we can employ.
In my ideal future there would be no more "mobileXXX" terms in the dictionary; just as most of the "iphoneXXX" terms were generalised to be "mobileXXX", my dream would be for as many as possible of the camera (again with functions to tell me which features are available). After all most 'desktops' are now laptops, many of which have cameras, accelerometers, various density screens, idle timers, etc...
Indeed, that is my ideal future too. We need english-like syntax for all these things, and as many as possible should work across all the platforms we support (or at least allow implementations for specific platforms to be added easily when/if such functionality is made available).
The english-like syntax will have to wait until the Open Language project is completed, but the restructuring to allow the functionality to be iterated across all platforms can start with the Infinite LiveCode project.
I'm really hoping (though I'm not clear if this is true or not) that the Native Field Object is not implemented as another new widget but as a new presentation of the LiveCode field object. A new widget would obviously be better than the using the mobileControlxxx functions (themselves a welcome addition); but even better if we can drag a field onto a stack, and have it work appropriately and according to expectation on all platforms.
Well, unfortunately, you will be disappointed in the first instance, but only because there is a logical and obvious path to achieving what you are talking about, and what everybody would really like.
Whilst it is easy to talk about 'an iOS field object' and a 'Windows field object'; the fact is that there is no universal idea of 'field' which is implemented across all the platforms we support. All platforms have things which accept text input, for sure, but they all work in slightly different ways with (in many cases *largely*) varying feature set.
So, if the goal is to have a "field control which uses the native 'field' control on all the platforms we support" then you start with the first logical step: you wrap each OSes 'field control' as faithfully as you can giving rise to an 'native ios field', a 'native android field', a 'native windows field' etc.
This first step means that if you are writing an app *for only one platform* (which is not that rare, I know a number of significant commercial users of LiveCode who use it to write apps for only one platform as that is where the app has purpose) you can do so using specific native controls which give you full access to the features that specific platform presents.
The next step is that you right a 'native field control' which exposes the features which *can* be implemented across all the platforms. This would essentially be a wrapper around the actual platform-specific widget - it would contain one as a child widget and its main concern (code-wise) would be mapping a 'universal' set of properties, commands and messages to the specific idiosyncrasies of the specific platform implementations.
The icing 'on the cake', of course, would be that 'field' would be a 'native' field on all platforms. However, I'm not sure that is in any way practical. The LiveCode field's functionality is not a subset of any of the native field controls on any of the platforms - it has various specific features and ways of working which are heavily relied upon in people's scripts - therefore it is very unlikely you could just switch your fields to native fields without changing code. Which, in the first instance at least, suggests that having a separate control for 'nativeness' makes a good deal of sense - you only have to use it in projects it is explicitly designed for.
(Although the news isn't all bad here - by introducing more specific, 'simpler' controls for specific purposes it should eventually make the 'automatic switching to use native controls' possible. For example, fields are used as labels, lists, rich text editing fields, single line entry fields, password fields, multi line entry fields and they are used in this way by adding script and setting various different properties in various different ways. By giving developers the option of using *specific* kinds of field control which are limited to doing precisely what they are meant to, and no more, it means they can be mapped to the platform specific controls which exist without loss of functionality, or lots of 'if the platform is' type constructs to deal with variant feature-set on each platform).
I think it is important for me to point out that the use of 'native controls' is subject to hefty restrictions at the moment (they all 'float above' the card) - simply because the architecture of the engine was never designed to really work with them. Now, we do have a plan and an good understanding of how to change this (it will require restructuring the way the engine renders / manages its control tree), but even when we do there are a fair few features that will be lost - for example, on all but Mac you cannot composite together (via 'inks') native controls with anything other than 'blendSrcOver' mode. Similarly bitmap effects cannot be supported beyond simple drop-shadows, and even then on only some platforms. However, at the end of the day, this is something you just have to accept - if you want a truly native UI, then you can only do that within the remit of the platform the native UI is running on; otherwise it isn't really a native UI anymore, is it?
Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
