Defining Pet Features and Essentials

[Ender Nafi Elekcioglu]

This was part of another topic, but I didn’t want to digress it, so opened a new thread. 

I think the issue is important as customers have an effect on the future roadmaps of companies. 
People wanted *theming* and *resolution independence*, RunRev provided it. 
Nobody seems to care about size constraints of objects, so there isn’t any plans about it. 

The definition should be, in my opinion, as: 
Pet features are those which can already be achieved via pure Livecode; 
where Essential features cannot. 

Andrew stated: 
“Any kind of timelines or updates on any of the stretch goals other than theming/res independence would be great. ... it is also the least important to folks who aren't doing mac or mobile dev.” 
and said that he would sell a piece of his liver for the non-blocking url commands. 

I couldn’t agree more, even I’m an iOS-only developer, I don’t need and don’t use *fullscreenMode* 


The thing is, resources are scarce; time and efforts of RunRev team should be distributed wisely. 

There is a reason why we call some features as *pet*. 
One can love them, desperately need them; 
but some others don’t and those can be achieved already via pure Livecode script; 
than those are not *essential*. 

Some example scenarios: 

I have lost a 16.000$ project for one lacking feature: *Rotating an image without wiggling*. 
Funny, isn’t it? 
16.000$! 
I could happily donate one fourth of it to RunRev 
in exchange of a timed handler consisting “set the angle of tImage to …” command which works right. 

But that doesn’t qualify it as an *essential* feature for two reasons: 
* Most of you don’t need it, even don’t notice its absence. 
* Livecode already rotates the image, just not perfect. 
It’s a pet feature; pet of me, for one. 

Theming cannot be considered as an *essential*, 
use a couple of png’s, it’s done and done. 

*fullscreenMode* cannot be considered as an *essential*. 
Read the resolution of the screen, choose appropriate image resources, 
resize and relocate your controls, upscale or downscale your font-sizes, easy peasy. 




Transparent unicode support is an essential; 
there’s no way to find a work-around other than using an external, even externals are not sufficient most of the time. 


Raw performance is an essential; 
there’s no way to speed things up beyond the engine’s limits 
and they’re fairly low. 
Try to calculate a recursive fib(33) under 0.5 second 
{it’s 14 seconds on a brand new Macbook Pro Retina, where it’s ~100ms. for Javascript.} 
or taking a snapshot of screen on mobile under 40ms 
{it’s +300ms. even on an iPhone 5S}. 


Using int32 for object sizes are essential; 
there’s no way to scroll content without using groups 
and there’s no way to increase a group’s size limit in pixels. 
It's not 1998 anymore, resolutions of device are not 800*600. 
32thousand pixels for a group is clearly not enough for nearly any content. 


A revamped url library is essential; 
One cannot cancel a download process in mobile. 
If it’s started, it’s started and will continue, end of story. 
One cannot update the UI while pulling the content from the server. 
All commands are blocking. 

Combine the last 2 of these examples and try to develop another Circa, NY Times, Snapchat, Instagram, Twitter, … 

I’m giving only mobile examples, because this is my field. 
I’m sure more examples can be given from desktop use cases. 



Interestingly, these are not among the future plans of RunRev except unicode thing. 


Back to my definition proposal; 

IF (the number of developersWhoNeed < the number of developersWhoDontNeed) OR \ 
(can_It_Be_Done_With_Pure_Livecode) THEN 
        put “Pet Feature” 
ELSE 
        put “Essential Feature” 
END IF 




Best, 


~ Ender