Kickstarter 2013 Revisited

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps