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.
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 - ā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.
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().
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.
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.
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.
