I forgot if this has been requested before, but let me request it again: enhancement for parameter. Here are my suggestions:
Support more data types e.g boolean (bparameter?), string (sparameter?), etc. Now it can be helped by some kind of convertion trick but it makes lot of mess in the code.
Support for inc/decrement step in numeric parameters (parameter and iparameter). Now it can be done by using multiplication, but again it makes lot of noises in the code.
Suppot for table and class. This is also for watch feature. This one might a bit difficult and take more time, so I don’t expect it will come anytime soon.
I do hope the first and second request above will be available in not-so-long-distance future. Right now, if you need a quite amount of parameters which are not numeric, your code is getting messy. I really hate it.
I don’t think it would be worse than regular sliders on a PC that snap to grid. I haven’t tried though - should probably implement one in codea first and see how it feels before I say more.
Those are good suggestions, @bee.
The first one (bparameter, sparameter) are definitely coming. I can’t tell you exactly when — but after custom sprites most likely.
That could be easily added as a fifth argument to the parameter function. I don’t quite understand how it should work, though. Doesn’t the min and max define the step?
I can see how this works for the watch() feature (and it’s something I’d love to implement). But not too sure how it would work for the parameter feature, especially for an arbitrary class.
Min and max define the possible range for the value. Step is for increment/decrement interval. Say I want a param that only accept 10 (min value), 20, 30, and so on, until 100 (max value). Well, it’s not very commonly used and if needed it can be tricked by multiplication. However, it’s nice feature to have and I don’t think it’s too hard to implement.
But given that your slider exists over N pixels (about 280) and your range is defined as [min…max], you get a step of (max-min)/N.
You could artificially set a step larger than this, but wouldn’t it feel very strange if the slider did not track under your finger, and instead jumped to values? Especially if the step did not evenly divide the range.
There would also be some impossible steps, like a parameter from [0…300] could not have a step of 1 or 0.5 because they go below the minimum step (1.07) for that range and slider’s pixel width. (It would be possible, but with a step of 1.0 you would lose 1 unit of precision every 16 steps of the slider, I think.)
Simeon, the slider could snap to grid for large step values.
That’s how I understood it. Wouldn’t it feel wrong to drag a slider and have it jump out from beneath your finger?
Edit: Also what happens if you programmatically set the value to a non-step value?
@Simeon - “Wouldn’t it feel wrong to drag a slider and have it jump out from beneath your finger?” Pages does it… It doesn’t feel wrong to me… Maybe make it so when you let go of it, it snaps.
I have implemented snapping in my version of sound slider which gives you an idea of how it would feel. I also implemented that an integer slider can take string labels as an extra parameter (used for the waveform). This is useful since most parameters in Codea are integers that make much more sense with a label.
I’d also like to put in @Nat’s suggestion of a function callback for parameter sliders.
My slider class uses function callbacks. One for when the slider is being moved and another for the final value. So the program can show what would happen, but doesn’t need to show everything when the parameter is being changed if it would be too complicated.
Are we too stuck on sliders? Is a - 100 + kind of display out of the question where + - would use the increment. Slider vs. +/- style could be an optional parameter on iparameter()
I guess it depends on what one needs it for. For +/- I’d be just as likely to use text and touches instead of iparameter().
Here are the parameters I want:
parameter() --with a text box to enter the number, a stepper on it, and has the option to snap
watch() --which also has the ability to show strings
bparameter() --a button
sparameter() --a switch
rparameter() --a list of radio buttons
tparameter() --a textbox parameter
And this would count as our GUI if we could make them leave the sidebar for fullscreen mode
P.S. Ipda41001 - Happy? :-))
I agree with @gunnar_z on this. I’d rather not import huge (yes Andrew what you’ve created is huge!) UI libraries for a small test, study or sketch. And herein (creating small exploratory sketches) lies the beauty of using parameters.
This can all be done from within the code - it’s another of those things that there’s no real need for Codea to handle it (I’d rather they concentrated on other things!). My UI stuff has most of this in already, and Mark’s does as well, and there are others who’ve done similar stuff.
Then why have parameters at all?
I support the proposal for more parameter types, mainly because for those of us who use codea mainly for prototyping and testing ideas, it is very helpful to not have to import a complete ui library for just a few parameters. And it does not hurt either, if you don’t want it, don’t use it.
Maybe I was being a bit extreme …
How about a slider, but if you tap on the current value you get a little + - stepper appear in a popover for more precise control?
Perhaps this suggests that the feature that would be most useful is library mgmt in codea. If you were able to download Andrew’s code once, and use it anywhere in your projects then you might be more willing to use it in your prototype projects.
@ruilov while I agree that some sort of library system is a good idea, it does not touch this issue. A ui library has infrastructure the programmer has to deal with, be it that I need to call additional functions in my draw/touched/keyboard functions or whatever, of that I have to provide callback functions. The parameter stuff has its infrastructure all set up with nothing for me to care about but retrieve the values when I need them.