#Modifiers for Input Config Items
1 messages ยท Page 2 of 1
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
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.
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
the sorting of the interpolation modifier is still crap
i have to change the data structure
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
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
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
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.
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.
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
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
yeah, it means people start to use the features, so it will mean migrating the functionality later
yeah
if we find an actual bug thats a differnt story
for example i fixed the interpolation and it would not rearrange the rows anymore
but this is clearly a new functionality that is more like experimental at this point and the UI and behavior is likely to change
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.
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
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
like blink would kinda make sense for button
let's play with it for a bit and also have users play.
I think the summary values should work regardless if MF is running or if precondition is satisfied
if the blink doesn't make sense and it is there... that's not really a problem.
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
we needed to migrate the modifier anyways
like doing custom L-vars via RPN earlier
it is ok. we should not spend time on this discussion right now
i am thinking to add the move tab command without drag n drop for now
just to the context menu
move tab?
it should be an easy fix
profile tabs
we don't have it right now because the DnD is a bit complicated
I know. i am thinking about what is important.
yea
we should open a new thread for feedback on the input modifiers. this here is just too long
could also use #development-chat I guess
nobody will ever join the conversation.
I know, but we would
yeah damn
i would not even dare to open this
I mean the flow has to happen somewhere
but yea, maybe that works
i might just hack away a first version of the output config wizards.
development chatter thread, and then feedback thread
with REQ FEEDBACK -prefix or something
but better not ๐
i would like to release the wingflex controller support and winctrl officially
that's why
yea
let;s get back to the hubhop clean up discussion
MobiFlight LTS ;-P
that would be nice
yea
https://github.com/MobiFlight/MobiFlight-Connector/pull/3092 was merged into main.