This should be ready for the 0.9.11 release - hint text for fields. No more rolling your own or just ignoring the feature. If you don’t know what hint text is, it’s the grey text in the field (in the picture “Hello World”) that lets the end user know what to type in them without having to have a label field next to them. Once the end user starts to type, the hint text goes away.
Funny you should mention this - I literally built a search box just two days ago and spent way too much time wrestling with show/hide logic and a bunch of other “why is this even happening” moments just to make it behave properly.
So yeah… I’m actually pretty excited to see this 
If there is anything you’d like added to HyperXTalk, let me know - we have the source code and can do pretty much anything we want.
let’s just make sure that we don’t miss any of these for the wiki, because, obviously, we’re forking away from LC, so if someone wants to move projects back and forth (or wonder if they should make the switch)
How is the hint text stored without adding to the file format?
I’d guess in a custom property set, which is better than a format change but needs documenting.
I guess we’re changing the file format.
I suppose that’s inevitable, though it carries cost.
Would using custom props be a mistake for this? Are we at a point where there are enough new features dependant on persistent properties that it’s time to bite the format bullet?
Bite the bullet!! hehehe
break the binary stack paradigm. it can be binary when it’s built.
That’ll probably be a “future thing” just due to the amount of work that it entails.
Whether that’s useful depends on how you define “built”.
I haven’t shipped an app in years that didn’t enjoy the efficient ease of transferring binary stack files across the Internet.
There’s built and there’s built. Script-only stacks are compiled into binary format in memory. Working on the IDE gets complicated if you can’t submit pull requests for binary files. There’s no easy diff for binary stack files. So if I want to submit a change to a stack that hasn’t yet been scriptified, my best move is to supply a procedure for what to modify. And if that includes adding resources to a binary stack it’s even more complicated.
i’ve been thinking about what i want to tackle/have tackled:
it seems like the biggest bang-for-the-buck across the entire project will be coming up with and implementing an alternative to binary stacks. heck, maybe they should be called “hives”.
To use the hint text, it’s a property of the field so just set it like the following:
set the hintText of field <field> to <hintText>
For example:
set the hintText of field "username" to "Username"
There it is: without a heredoc element what had been a tidy file becomes a collection of parts and pieces requiring additional care to keep them together as we move them around from file system to file system.
For development it doesn’t matter to me, and in a world where the limitations of others’ tools have come to define our workflows, contributions to this project make sense as script-only stacks.
I’m fine as long as my stackfile deliverables require no extra steps to use the robust and efficient native format.
there can be several kinds of “builds”:
there also isn’t any reason why one would have to abandon the old ways and adopt the new ones.
This is an interesting discussion but perhaps it would be better in its own thread?
I thought there was a thread on the topic.
I opened an issue on github so I can think out loud about it, and maybe someone else will chime in.