Could we have a strings slider?
The format would be something like;
parameter.strings(variableName, tableOfStrings, startingIndex, callback)
So for instance a set of strings might be:
{“physics demo”, “lighting demo”, models demo”, “hitchhiking demo”}
And moving the slider shows the string at a given index when you slide it to that position?
@UberGoober - you can do that with a table of strings and a pointer from 1 to #strings. Why re-invent the wheel. Will post code later when I have access to my pad and not through my phone.
@Bri_G I know this, anyone who’s looked at the default Codea demos knows this. I’ve made tons of such things myself. There is absolutely no need to post code showing how to do this.
However if you look at the many many many places this is used for purposes that require conveying information beyond a sequence of numbers to a user (like for instance selecting between things with obvious names, like demos or levels or interaction modes or lighting effects or camera viewer types or model sets or types of butterfly or geographical regions or world-generation types or, or, or, or…) they all have to take various workarounds to display that information.
Some print it directly on screen, as with the physics simulator.
Some put explanations in the output window.
Some make a different parameter use the slider index to display the information in the parameter pane itself.
Many put no explanation at all and let you fiddle with it to figure it out.
Each coder has to figure out on their own how to get what is often essentially a very simple string’s worth of information to the user.
So I could not disagree more strongly that this is re-inventing the wheel. What is reinventing the wheel is forcing every coder who faces this issue to come up with their own way to get a simple piece of information to the user.
From a coding perspective it’s a negligible amount of extra work to turn a number into a string. From a UI perspective there is a world of difference between showing a number that means nothing to the user versus showing a string that is helpful to the user.
which doesn’t even touch on the fact that strings are the single most common non-numerical keys used in tables, so forcing programmers to take the extra step of turning an index into a key into a value is not a huge deal once, but forcing them to do it again and again and again and again, when they could simply use the slider to display and choose between those keys… well there could not be more apt an example of reinventing the wheel than that.
This would be extraordinarily useful, and over time save almost every Codea user a significant amount of extraneous grunt work.
Which is what a good UI should do.
@UberGoober this is something we built for Shade’s inspector and something I’d like to bring to Codea. In Shade it’s called an enumeration and displays either as a series of tabs horizontally, or vertically if there are more than three options.
It is very useful and almost all of the advanced settings panels use it to present selectable options to the user
@UberGoober - my bad, thought it was a bit odd for such a basic solution. Will wait for the resolution if this occurs later as @Simeon hinted at.
@UberGoober If you want a table of strings to show in the print area, try this. I would rather @Simeon fix the bugs in the current code then spend time creating things that can already be done. As far as I’m concerned, the print area is for quick input/output for debugging code or for quick one time coding or for new users just learning. Just about everything else can be done on the regular screen using text.
function setup()
tab={"val1","val2","val3","val4","val5"}
parameter.text("val")
parameter.integer("pos",1,#tab)
end
function draw()
background(0)
val=tab[pos]
end
@Simeon @dave1707 - noticed today that you can’t put touch into a parameter.watch, even if it is displayed as a passed variable to the touched routine. Have to provide variables to achieve this. Is there a possibility that we could include touch as a parameter to watch. Perhaps a parameter.system(“touch”) call. That may be useable for other defined system variables.
Edit: another parameter that would be useful would be FPS.
@dave1707 the simplicity of any given solution is not the point. And helping me personally is not the point.
The point is threefold:
a) just looking at the various pieces of code all over these forums, it seems to me that this is an issue almost every Codea coder will come up against sooner or later, and forcing each coder to find their own way around it is unnecessary when it’s simple to provide an easy and consistent parameter function to do it. It’s like the argument Steve Jobs made to the original Mac team about making the startup time faster—if you aggregate all the time saved, even making small things more efficient is saving lives.
b) I think your perspective is only taking into account what such a change means to you, the coder, which is entirely legit. But’s it’s equally legit to think about what it means to a user. In other words, it’s the difference between presenting a user with a piece of UI that in most cases displays irrelevant information—a numerical index—which is inevitably confusing to users without some explanation—and presenting UI that shows only the relevant information, like tab names, which is extremely helpful. What you don’t show is just as important as what you do show. This is in line with my experience of running lots of the code that gets posted here, where it’s not immediately clear what a given slider is doing, and I have to search the code for an explanation. I’m not saying that you personally have to care at all about this issue, but if you want to understand why this would be fantastically useful to others, thinking about how one makes things clear to users is also important.
c) At just the basic level of theoretical design priorities of any program pertinent to lua coding, it seems to me, it can’t be ignored that lua has one fundamental structure that has two fundamentally separate behaviors: a table with an array-type behavior and a hashtable-type behavior. This is the rock-bottom nuts and bolts of lua, as far as I understand it: tables, indexes, and keys. Tables, indexes, keys. Right now the baked-in UI for parameters can only directly handle indexes. That’s it. It seems to me that to have a UI system based on lua that can only easily be used with indexes is, at a very basic level, incomplete. Having an easy way to display hashtable information isn’t some superficial frill, it’s giving access to one of the most basic language features. While having a string-based slider would not fully address that, seeing as since strings are probably the most common keys used in key-value pairs (which is just a guess on my part, but a pretty good one, I think), a string-based slider would go a long way.
@UberGoober I guess that’s where we differ. I’m here coding just for kicks, helping others, and nothing serious. I’d rather write routines from scratch then have something already written. If I’m searching the forum for something, it’s because I want to know how it was done, not to take the code and just paste it in my program. What’s the point of a string slider when you can easily write code to display it on the screen. Writing things yourself gives you the ability to customize it any way you want, without relying on what someone else might think you want. If I wanted cut and paste coding, I would be using one of the other apps. But then that’s your option to request whatever you want. I’d rather have the bugs fixed then have unnecessary options added. Maybe that’s why the iPad operating system is so huge. Apple is trying to include everything they can think of to accommodate whatever they think everyone wants. So you need to buy larger and larger iPads/iPhones just to handle the new operating systems.
Just my 2 cents, but I think the whole parameters and output panels are only for beginners. It’s not useful for larger projects, and complicate the relationship between Codea’s setup function and draw function. Instead of using the built in parameters, I find it better to program your own debug menu with whatever options you want. Parameters are particularly unnecessary, while Output can still be nice for a quick print() check but even then it is not useful for tables or other nested types.
If you’ve ever seen game projects with their own debug options you can see where I’m coming from. Having your own visual feedback, for example coloring your character red or green when they are in an animation vs idle pose, is immensely better than a menu that only prints out text. Also the parameters themselves are limiting, for example, for integers and numbers we have to use sliders instead of being able to input the value so if I want to got from 1 to 10 I actually have to trigger the callback 9 times, instead of just entering 10.
if asked to prioritize string sliders, i would give them a very low priority, not least because i think useful programs wouldn’t use sliders. i find them useful only for simple demos and tests. that’s just me, of course.
There’s centrally the matter of what @Simeon has bandwidth to spend time on, and obviously everybody wants him to pay attention to their pet peeve ahead of everyone else’s, and “my bug is more important than yours” seems to me a less than productive use of time.
The thing I want isn’t the thing you want isn’t the thing the other guy wants and @Simeon gets to choose. Not much more to be said.
@skar you say “only for beginners” like it’s a bad thing. 
@UberGoober NO. My bug isn’t more important than your bug. Bugs are bugs and they affect everyone and should be addressed before adding things that don’t need to be added. And YES, @Simeon is the one who chooses what gets done. But the number of bugs determine if an app is successful or not.
@UberGoober sorry that’s not my intention, I DO think parameters are not useful in the long run, I DONT think there’s anything bad about being a beginner, and I definitely don’t think you’re a beginner.
I think part of my sentiment here is that in my professional work, my tech/project leads are frequently tied up in the notion that we want to write less code that is future-proof, by using better paradigms, tools, and structures. But IMHO the whole point of being a software engineer is that when you encounter a problem, you write code to fix it and you will never be at the point where there’s no need to go and write more code.
I get trying to reduce common processes, but at which point is it ok vs annoying? Is it annoying to have to write if/then/else/end every time?
@dave1707 i have a feeling you’ve been through this argument many times with many people, maybe even me a while back.
Cutting and pasting isn’t the opposite of learning to code, it’s how you learn to code. Understanding how someone else’s code works is one of the best learning experiences there is.
I mean, yeah, your perspective just makes no sense to me. I would absolutely love it if I wrote a piece of code that saved everyone else from having to ever write it again. Doing grunt work that saves other people from having to do grunt work… seems like, I don’t know, good.
@UberGoober I don’t necessarily write the same code over and over and if I do I don’t mind it. I have 650+ projects and I’ll copy routines from them when I’m writing something. I don’t like to use other people’s code because if something goes wrong with it after a few Codea version updates, you’re stuck waiting for them to fix it and if they’re not on the forum anymore, then you have to figure it out yourself or scrap your program. Everyone has their own way of coding, and their own way of learning. I’m having fun and have been since I found Codea 9 years ago. Before that I was coding for a few years with iLuaBox Pro. I still have it on my iPad 1, which is extremely slow compared to what I have now. Even Codea on it is extremely slow. So everyone has their own priorities, but I feel bugs fixes should come first.
@dave1707 I hope I’ve been clear that I’m somewhat in awe of your prowess as a coder, so even though I disagree with you on some things I feel like your results speak authoritatively of the fruits of your approach.
@skar I’m sorry if I misinterpreted you, and while I’m certainly not a beginner in any literal sense of the word, I do make an effort to retain “beginner’s mind,” as they say.
And I mean, if you’re asking me if I’d like something that let me skip writing out if/then/end every time, how do I say yes in every human language?
I’m curious to hear more about people advocating against future proofing things. What are the merits of such an argument? I mean, if you don’t want to future-proof things, there’s no OOP, right? And if there’s no OOP, there’s no NEXT, and if there’s no NEXT there’s no iPhone, for goodness sake!
@UberGoober OOP aside (personally I think procedural and functional programming is the best), here’s an article about why it’s better to hold off abstraction and write the same code again - https://kentcdodds.com/blog/aha-programming