On 2015-05-11 02:05, Bjoernke von Gierke wrote:
Adding unicode is nice, but making all text handling slower by half
(sometimes even 30 times slower) is not going to convince me to start
using 7 (ignoring the added stability hit compared even to current 6
versions). Especially as the only actual difference for my needs is
that I am not allowed to use uni-en/decode, but instead two
syntactical different (but functionally completely the same) terms.
Sure nice for non-latin scriptures users to have a slow version of LC
just for them tho.. I guess? But basically, this is not what I expect
from "seamless unicode support". Therefore, I consider the unicode
part of the kickstarter unfulfilled.
Well that's your opinion - but I certainly don't agree with your
assessment.
'seamless unicode support' means that you can load a stack developed in
an older version and it will work, and assuming you aren't doing
intimate text processing which requires knowledge of Unicode to be
'correct' then it will work with both unicode and non-unicode inputs
whereas before it wouldn't have been able to handle unicode at all.
As a case in point, I just opened up revNavigator from the plugins menu
- and it works in 7. Indeed, if I have objects with Unicode names,
revNavigator still works perfectly, displaying precisely what you would
expect. There was no need for me to modify the code, nor do anything to
the stack.
In regards to textEncode / textDecode then they were introduced because
they have the correct semantics for dealing with the notion of 'text'
which is may or may not be unicode (whether it is or not shouldn't, in
general, be a concern to the scripter).
It is important to remember that uniEncode and uniDecode work with
UTF-16 binary data - not with text strings - and if, for example, you
want to encode a string as UTF-8 you have to use:
get uniDecode(uniEncode(tMyString), "utf8")
with textDecode it is just:
get textEncode(tMyString, "UTF8")
Given the operation being performed here is 'encoding a string to UTF8',
I think the latter makes a great deal more sense.
The same goes for skinning. Promised as part of the kickstarter, this
now sounds like a "can change colours" checkbox for the new
widgets/externals. Sure is nice, but certainly not what I'd expect
when I hear "make your own themes". Sounds like this is only for those
people who want to deal with another scripting language, and in LC it
affects only those parts that are compatible with widgets. Instead of
adding community made themes to the "os 9 (emulated)" menu, or
improving on how object style inheritance works, or any other approach
to making themes actually easier, it's just gonna be some objects,
made by some people, for some cases... Sounds to me like the same as
it is now. I'f I'm right with this assessment, theming is not going to
be fulfilled in my eyes.
You are incorrect here. The themeing library we are working on will be
pluggable - it needs to be, as it at least has to account for both
emulated and native themes on the various platforms we support.
There isn't a 'magical' way to make controls automatically theme with
pluggable themes (which is what you seem to be suggesting that there is)
- the controls have to be written in such a way to use the themeing
library (which our widgets will be, and a developer of widgets can
choose to use the library if they wish).
--
Mark Waddingham ~ [email protected] ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
