#Modifiers for Input Config Items

1 messages ยท Page 2 of 1

sly verge
#

everything that is changed on the config is done on a temporary copy

tame oriole
#

we would want to show the modifier working while you edit them, to read the pot value to set a setpoint for interpolation or compare etch maybe? not sure if everything but possibly for some things

sly verge
#

so we would keep the original config and submit the temporary copy more often and when a user hits save... nothing would change because the changes were already submitted... and if the user cancels then the original config would overwrite all settings

#

that is likely the easiest way to do it.

#

have you had a chance to try if it is really more reponsive now?

#

with interpolation we can now define a deadzone for the joystick for example... i will try and see if i can see a difference in performance.

tame oriole
#

I downloaded the latest, let me see

#

it would be nice to have a axis calibration modifier specifically for that maybe

#

because with interpolation you need to know to make a bit of margin on the endpoints

#

so you actually reach 0 and max

#

it is not at all obvious for users unless you know this

sly verge
#

the sorting of the interpolation modifier is still crap

#

i have to change the data structure

tame oriole
#

yeah and it should be more interactive at later iteration too. it autosortd if you change the value to fit in another order

#

but doesn't move your focus along

#

do it is very strange

#

but I will try that latest build

sly verge
#

it should be identical to the current UI

#

i did not invent anything new

#

not saying it was good until now ๐Ÿ˜„

#

actually it just stays in an unordered way until you save the changes

#

i guess i will do that too then

tame oriole
#

so it would be very good to show at least the current value because the log is hard to see now that the dialog shades the main window since it is modal

#

not sure if the config wizard needs to be modal but it is

#

but most cases that I can identify are related to looking at raw/final values of other configs (likely references) or log for current pot value

#

so solving those problems might actually make it more obvious what is an issue if we keep it modal

sly verge
#

yeah!

#

it is such an improvement

#

driving the elevator axis directly via the input modifier vs going through the variable -> output config -> input action

#

you can tell that there is a noticeable difference

#

the old way is stuttering

#

the new way is super smooth

#

and no performance hit either

#

i am not using the log

#

i am looking at the value that is displayed in the config list view.

#

it should be in the panel though for sure.

#

and it should become effective the moment you set it.

sly verge
#

OK... the interpolation modifier is now keeping the current sequence - only once you close it out and reopen - you will see the new order of the rows. This is like the old UI also did it.

#

there is still room for improvement to ensure proper data input... but i think it is not critical

#

After 7 days straight working on this feature - i will merge it now back into main.

tame oriole
#

let me try now

#

new zips appear faster than I can test ๐Ÿ˜„

tame oriole
#

this same happens when you edit a modifier

#

also, if your precondition becomes unsatisified, it should show some kind of grayed out visual style in the preconditions summary

#

and a question: Should it then disable the modifiers from updating while you edit them?

#

I guess it is a matter of convention: should preconditions work also when the wizard is open?

#

ie, when you are editing a config? I guess one could argue that a config that is being edited is not "in production" but being edited, and it should thus be active, regardless of its preconditions state. HOWEVER we should maybe make the whole preconditions frame green when they are satisfied, and that purple color when they are unsatisfied?

#

and the individual preconditions would show their own satisfaction via being gray or colored

#

So you would have

Preconditions (satisfied) or Preconditions (not satisfied)

#

I know it is technically wrong to keep a config active when preconditions are not satisfied, but I think an open config wizard is a different context for a config, and it should inform you of the preconditions state clearly in the summary, but it should not actually turn the config off, because that would be more of an annoyance while editing a config

sly verge
#

these are all nice additions for later iterations

#

the question is: what is fundamental for the first release.

#

there are currently some limitations

#

but nothing that was available in the old UI either

#

i already merged the branch into main

tame oriole
#

yeah, it means people start to use the features, so it will mean migrating the functionality later

#

yeah

sly verge
#

if we find an actual bug thats a differnt story

#

for example i fixed the interpolation and it would not rearrange the rows anymore

tame oriole
#

but this is clearly a new functionality that is more like experimental at this point and the UI and behavior is likely to change

sly verge
#

that was essentially different from the status quo

#

i need this kind of feedback right now.

#

the next iteration should be the arrangement of the information, like we started with neil yesterday.

tame oriole
#

so I think MVP should only show the modifiers that make sense, so most modifiers only for axis

#

but its a bit of a muddy thing

sly verge
#

maybe even enabling the interactivity for the values. but even right now ... the way it was ... i was definitely able to get the job done

tame oriole
#

like blink would kinda make sense for button

sly verge
#

let's play with it for a bit and also have users play.

tame oriole
#

I think the summary values should work regardless if MF is running or if precondition is satisfied

sly verge
#

if the blink doesn't make sense and it is there... that's not really a problem.

tame oriole
#

yeah

#

because we have our own idea of what works

#

and then someone comes up with a wild idea that is nothing we thought of

sly verge
#

we needed to migrate the modifier anyways

tame oriole
#

like doing custom L-vars via RPN earlier

sly verge
#

it is ok. we should not spend time on this discussion right now

tame oriole
#

yeah

#

let me play with these more

sly verge
#

i am thinking to add the move tab command without drag n drop for now

#

just to the context menu

tame oriole
#

move tab?

sly verge
#

it should be an easy fix

#

profile tabs

#

we don't have it right now because the DnD is a bit complicated

tame oriole
#

oh, this is modifiers thread ๐Ÿ™‚

#

was confused

sly verge
#

I know. i am thinking about what is important.

tame oriole
#

yea

sly verge
#

we should open a new thread for feedback on the input modifiers. this here is just too long

tame oriole
#

could also use #development-chat I guess

sly verge
#

nobody will ever join the conversation.

tame oriole
#

I know, but we would

sly verge
tame oriole
#

yeah damn

sly verge
#

i would not even dare to open this

tame oriole
#

I mean the flow has to happen somewhere

sly verge
#

the new modifiers are so speedy

#

really cool

tame oriole
#

but yea, maybe that works

sly verge
#

i might just hack away a first version of the output config wizards.

tame oriole
#

development chatter thread, and then feedback thread

#

with REQ FEEDBACK -prefix or something

sly verge
#

but better not ๐Ÿ˜„

tame oriole
#

you know you want ๐Ÿ˜…

#

its just all the devices

sly verge
#

i would like to release the wingflex controller support and winctrl officially

#

that's why

tame oriole
#

yea

sly verge
#

let;s get back to the hubhop clean up discussion

tame oriole
#

MobiFlight LTS ;-P

sly verge
#

that would be nice

tame oriole
#

yea

sly verge