#New Config Wizards
1 messages ยท Page 2 of 1
still here ๐
having a cold one here
Ok. Done. Reworked all panels to the new system
incredible how quickly things go after a couple of hours of sleep
Now i have to update all playwright tests
and then i want to create a couple configs with multiple different actions for the events so that we can take some screenshots and improve the layout of the summaries
i would really like to get it out as stable as quickly as possible
nice, yeah
i think if we want ti release soon then it is rather unrealistic to migrate the output wizards too.
is there a pr for the latest state?
i don't think it builds yet
all playwright tests likely fail because we have introduced the "edit" button...
i wil lhave to fix them first.
the branch is pushed and I now created a PR... but it will fail ๐
you can run it locally from the branch\
i had to work on other stuff in the mean tinme
will get to it later tonight again
now all tests pass and it is building alright
yea nice, I will have a look tomorrow, zZzZ
in the drawer?
also the previews now look like forms that you would want to edit in place, but are disabled, hmm
and onPress as comparison might be like this - Action Type could read the actual action type
so it is consistent wtih OnHold
so we dont need double headlines to just state the obvious
also I think reset filters should also have this "Clear filters" button on the bottom of every dropdown, outside the scrolled area
or if the dropdown does not support that, we should have it as the first item maybe
btw, for some reason, my joystick is not recognized by the PR build
I added something similar to this already - there is a challenge with the data structure but i am sure i can work around it.
yea, and if we want to later allow multiple actions the setting needs to be tied to the event config I guess
or well maybe not necessarily
but then we'll have another "ok where does it go now?" moment
We have to come up with Layout and style for the summaries. And i think it is ok that it takes an extra click do edit them - not inline edit them. At least for the first step
We can iterate later and optimize things - but even now, they are very snappy and easy to navigate.
so i would now commit to this 2-tier workflow (summary -> edit)
it seems to be working quite nicely.
yea I think we shouldnt inline edit
my comment was more like it looks like it would be editable inline
so yeah, I agree
the profile aircraft selection -> preset filter will help with slow and long dropdowns
I was pondering should the dropdowns also be a popup that has more height but it might be weird
I actually had two cards
i guess it works either way. still ... now i have to find a way to update the button hold options.
the data format is a bit meh ๐
I think it can also the same "container" because it is not two things? less framing and visual noise?
oh yeah
I think "long press" is what people also understand and its what we have now, and is not necessarily too bad?
This action is triggererd on a long press, and can optionally repeat after specified interval.
Trigger delay: [ 350 ] ms, repeat every [ ] ms
human language is nice there but it also needs to be to the point and brief so it is not too long, that is the challenge most often
i am not worried about that right now
its all language files
i dont do any form validation right now and it is ok because the backend can handle partially configured stuff
I will also limit repeat ms to some value in the backend regardless what the user puts in.
you mean that it cannot be super long repeat?
no. opposite.
oh right, not utterly fast
a short one.
and 0 or empty means "no repeat" as currently
not shorter than 50ms or so
better add a switch to enable it
hmm yeah
maybe 0 for now - but i am not a big fan of that s magic behavior
Long press delay [ 350 ] ms ( o) repeat every [ 200 ] ms
yeah I agree
its better to have a proper toggle for it
or checkbox
it could be a second line even
then the slider switch works better
we can internally treat 0 as off - but the user should make a conscious decision
yes, and we can of course just have a label there that minimum repeat is 50ms
because the drawer does have space
its been so much effort to do even the baseline properly. I want to get over with it ๐คฃ
but this dialog feels so much better than what we had
makes the output one look so crappy
how about
too much space, don't you think?
I mean it can go on the same line too
but hmm
is it really?
of course what is our baseline screen resolution?
1080p?
hm, need to make the scrollwheel work on these drawers
something might be swallowing the events - because of the drawer on top of dialog on top of everything else
its a shadcn bug iirc
we definitely want to fix that
and the reset filter stuff for them
I also pondered if we could do drawers for them too but it might be a bit much
and too many levels then
but I am pondering something like what mobile devices have - there is a field and then you get a "selector popup"
that is a small modal dialog for choosing an item from a list
it might also work instead of the dropdown but its kinda a rabbit hole in itself, and I think the dropdowns work quite fine now especially when the aircraft preselection will have a predefined filter already
so there are less items
oh I dont know what the issue was, now the joystick works fine in the PR build
hey super quick fix
change the tickmark to X
so it resets the filter
because it does but the tickmark does not communicate that
this reminds me of the digikey/mouser component selector forms that are always super funny horizontal scrolling monster forms
also maybe the "back" action on the drawer could use the same chevron as we use for configlist for navigation,
< Go back
one thing that bugs me with this interaction is the copy paste, because I do like this is a nice way of doing the Action setting in a drawer,
but to copy and paste events between the different action types is now a bit awkward because you need to go back and forth
We could of course have some "Copy this event to [ On Release | On Hold | On Long Release ]"
in the bottom
instead of the copy and paste buttons
**issue: ** selecting a preset does not update the filters to match like in the old dialog
@regal halo how would we do the modifiers?
they are currently a list that can be reordered, so that is quite nice already
Hi, I do not want to disturb your brainstorming.
Would it be a big issue to add the Name/Description of that item in the headline ?
Yes, the selected line/config in the list is highlited.
But when the window is to small you can't really see it.
And the popup window for maintaining is not moveable.
@half geyser no disturbance at all!
and yes, we do want to have the name editable here, and also visible
this is a good suggestion
I know technically is not required by Mobiflight, but for us humans the name label should be unique within a profile (tab).
I am not sure - I mean nothing stops you from doing it that way
but if you share profiles, its kinda nice that for example "backlight" is not something totally different on every profile
but we need to have some system to handle the "global" configs later, but its out of scope of config wizards
I was meaning no repeat labels within one tab
Now, all lines can have the same name.
"New input config"
a bit like device names
but if we make it easier to edit it can solve itself
this would be the new input config with nothing defined yet, it should focus and select the name field
so you can type the new name
or well
maybe it should default to the device name?
Just like module names should be unique within an installation.
"Autopilot master switch"
that might actually work
actually yes, but then it would be after you click "Scan for input", hmm
dang, this is why I sometimes hate UX design
nothing is "just"
It should not defaulted by the device name.
E.g the device is a MUX with 16 inputs. What would be the default name ?
The name hs to be maintained by the user.
I used 2-3 chars for the type of device (BTN, SW, RSW, LED, ...) .
That's not a must but I makes the identification and filtering easier for me.
Maybe, when saving a routine can check if this name is already used in the tab and give a warning.
it would be something you can change of course
what I meant is it could default to the device name
but there is a chicken and egg problem because when you add a new config there is no device yet
Of course we can change, but is not required and a lot of users never bother to change the default name assigned.
@cyan pendant yeah but we probably cannot force it, also if you merge configs it gets complicated to handle
ideally you would keep the names unique to make it easier to maintain your setup. there is a unique ID for each config that is not visible to the user that identifies it, so there is no technical reason for them to be unique
I don't know what you mean, Mobiflight doesn't care about any labels
I mean I think it is kind of a generic thing and the user should really do it themselves, because otherwise it becomes annoying when you cannot for example add a bunch of configs for testing, or if you combine tabs and there are common names
That is exactly why. Because Mobiflight doesn't care, you can end up with a lot of repeat labels, which technically is not a problem, except for the human to understand.
but it is a valid point that names should be good
its maybe more of an education and documentation challenge
I can imagine a nightmare install with four Mobiflight Mega boards and 30 buttons each all named Button1 to 30, all 120 bound to "Input Config".
But if you force unique names, you would then just get "Input Config 1" to "Input Config 30"
which would not really solve the problem of sensible names
That would be 100% better than the current state.
"Input config 3" and "Input Config 5" dont really make it much better though
I think we have two challenges here
- each user tends to have a personal way of naming things, and we should allow that
- we could offer a useful default name that is based on something that identifies the config
- we should maybe suggest a name (pre-filled name in the editor field that is selected, so you can accept it or start typing your own)
those easily conflict
I would recommend at least a warning that there is/are duplicates.
It's up to the user to name it with a meaning "to him".
The second option you listed could be quite difficult. As I wrote one MUX 16 Inputs for Switches, buttons, ...., whithout knowing for MF what is the usage of these.
could also maybe show a note in the dialog if the user has the default name?
@half geyser yeah, the real problem though is that mux switches have no unique names
but we cannot fit them in the flash on Atmel arduinos
Same problem later on for outputshifter.
but thats why it should offer you "Multiplexer: switch 3" and you could name it differently if you want
yeah
I mean on my radio panel I actually DO name the switches Switch1 to Switch 8 because they are in a row - and I often do configs with a bare PCB with switches and no labels. So "swich4" is easier to know what it is, compared to "FUNC"
thats why there are always challenges to know the right way - because every user has a different way of doing things
So first identify the hardware to get the devicetype. Then suggest a default name which can be changed.
But still the not nice situation of duplicate names exists
yeah, I was thinking if there should be a "Add config" -> "Input configuration / Output configuration / Autosense device"
we want to combine input and output config to one "Config" dialog later anyway
because its mostly the same: Trigger -> Modifiers -> Action
trigger can be device button press, or a simvar change
but we cannot autosense a simvar yet
OK. I donnot know the target you want to achive.
By the way: do you name them butons (1..n) from left to right or vice versa ? ๐คฃ
left to right ๐
but these discussions are useful to think outside our own ideas too
As I stated earlier I give them the hardware type (BTN, SW, RSW, LED, ENC, POT, 7Seg, ...) and the name what it is used for (VHF1, VHF2, ... MHZ, ...ON/OFF))
yeah, and that would be best and you would do it in the pin config "MobiFlight Modules" config if the multiplexers and shifters would let you name them there
But as of now, it's not available. Will it ever be available ? So I do this workaround.
I have another suggestion. Maybe it's already discussed.
Sometimes I'm no able to find the code for an item immediately.
Or the function I expected is not yet established in the sim by the vendor.
So I want to leave somewhere a reminder in a textbox.
This could also be used to describe what the code is used for in detail if this is different to hubhop or not even in hubhop.
A radiobutton (comment, reminder) related to the textbox would be great.
Later on in the overview a filter to comment/reminder configs would be also appreciated.
maybe we could have a comment field in the output or input config
lets see once Sebastian catches up here and sees the amount of text we generated ๐
but its great to have feedback! thanks @half geyser and @cyan pendant
Hi! So much to read! Great ๐
yeah I split the following stuff into two topics
will add some thoughts there so its not one huge thread, but its great to have feedback
I think we should auto-generate a new name with consecutive index, similar to how we are doing it for the devices
Input Config Item #2, Input Config Item #3 etc.... could be a way to do it.
When duplicating an item it should say (copy) in the end
I would not go futher than that. Every user has their own ways of organizing their stuff, I would not force anything on them.
I can say for my self that when I am creating actual profiles, not just for testing, I will automatically start using sensible names.
Once we include the name/description as a text field in the config wizard itself, I am confident that items will have a meaningful label right away. Right now you click new item, then enter the wizard, close the wizard and you end up with this repetitive name/description. If you are focused and right away create the next item, then you end up with many items having the same name. The description is currently treated more as an afterthought... which is not right.
Yeah I think you are right, its very easy to try to be too clever and then just get in the way
yeah, something like this, it would be nice if it was pre-selected so you can just type a new name without clicking
and this would be selected automatically only on newly created configs
not if you open it later
it is really not
One thing that is missing is the look up of the actual preset label - because that is just a static placeholder right now
i think it is coming along quite nicely but still has some layout challenges.
The action names are quite long and are cut off
definitely happy though
it would be good if you could select and copy the code from the preview
if we show it
what would be the use case?
copying the entire action from this view and then paste it to a different event would make sense, so that you save that one click.
But even for this decision, I would wait for user feedback.
Iโm a user. ๐
It would be great to be able to copy the code and paste it into a new event.
There are quite a few configurations where you turn something on in one setup and turn it off again in another.
This happens either via "OnPress" and "OnRelease" within a single configuration or across two separate ones.
Another example is feeding a single sim variable with different values in different configs.
Please add a cut-and-paste feature.
yeah maybe well, copying it to save to hubhop
but we should eventually have "share this preset" function down the road
@half geyser yes, this is what the "copy" and "paste" is for, it lets you copy the whole "on Press" event to the "on Release" event
that already exists
so yeah, maybe copying the code from the preview summary does not make sense, you can edit the preset and copy from there if you want the raw RPN
@regal halo should we also have a "summary" and "edit view" for actions? I am a bit unsure because editing presets is such a primary thing
but having those all in the editor mode in the main dialog will make it quite big and cluttered
the new dialogs are fast but the preset list is the slowest thing
and that takes a bit of time to load
i would really like to focus on the current scope and finish the baseline
i basically spent an entire day just to get the onHold and onRepeat options right and everything tested and everything internationalized
Please help me get the current scope right and collect improvement ideas on a different thread.
copy and paste is there already.
It is an unbelievable amount of work and grinding - i am so glad we are at a point where we can call it fully functional - and i mean everything we could do so far, or more.
yeah, what are you right now working on that I can help with?
though the question whether we want the actions also in a "drawer" sidebar or edited inline is related to this scope
ooo exactly
this is exactly why I did the two other threads
for modifiers and output wizard
let me get the latest pr build
oh
let me get the latest latest pr build
@half geyser if you feel adventurous, and want to test and give feedback, the PR test build can be installed independently from your current MobiFlight setup
๐ Try out a GitHub Pull Request Build to see if this version resolves your issue.
- Download the latest zip-file from the Pull Request (PR) on GitHub - scroll all the way down to find the latest version.
- Extract the downloaded zip-file to a temporary folder.
- Extract the zip-file inside the temporary folder. A new sub-folder will be present.
- Run the
MFConnector.exeinside the sub-folder.
:eyes: Let us know if your issue is resolved with this version! ๐ Thank You!
but be aware this is totally work in progress and might not work or have complete functionality even
but it wont overwrite your own MobiFlight setup, start a new project in the pr build and play wiht the options and give your impressions
it is not WIP anymore
i mean
I mean It could be, was referring to PR builds in general
so we talked about a list of MF variables and I love the picker to select existing one
It is quite stable... still WIP but not that you have to fear nothing works
what if there was a "add new MF variable" button with a small widget that pops you a name field and OK
so then we could get rid of the text field in the form and it would be a selector?
yeah
if it doesnt work we fix it.
this is MVP and works fine
we can do then a polishing round once the main stuff is done
arearrangement is ok.
the layout can be tuned without too much effort - but introducing new dialogs and what not means additional playwright tests and all that stuff
I have spent 2 weeks now on this
and if we want to release soon, then we cannot spend time on all the bells and whistles
what you can help with is to compare one more time that we really have covered all the existing functionality
use MF 11.1 and this. and compare.
or maybe we split this in two lines.
Name Use existing
[ New Variable ] [ picker v ]
Expression
[ $ ]
by release do you mean beta or stable?
we have a beta already out
and we should try to bring it to an end
did anyone create a github issue with the user feedback for input config wizards>?
I just did about the keyboard input
I can look through the thread and add whatever might be missed
try to create a single one for all the feedback
I can add to the same
Describe the bug The new config wizards #3043 uses the new toolkit. The keyboard input action type has a regression. Steps To Reproduce Steps to reproduce the behavior: Add a new input config Selec...
will add here
I edited it as a main trunk and will add sub issues for each
the amount of issues is stressing me out.
we had like three things reported, i don't think it was more.
one of them was the long press timeout but you added that already
hah, even Github uses Drawer for sub-issues!
FSUIPC offset panel doesn't work completely.
Dang.... forgot about the quirks with the modifiers.\
Sheeesh
Would like to test. But since Friday afternoon my neighbour and I have no Internet. ๐ญ Hope the technician can fix it on Monday
Good idea. I had the same.
Provider gave me 500GB for a mobile hotspot.
But the transfer rate is an absolut catastrophe.
With 2MBit no meaningfull access is possible. ๐ญ
This situation gives me the oppertunity to assemble more of my modules, improve some existing, create new ones and program my OLED custom device. ๐
Also nice
Good morning.
I don't know who or what was made.
But since 22:51 yesterday my Internet connection is back ๐
So Tuomas asked me to do some testing. How nitpicking shall I be ?
You can ask Ralf just how meticulously I hunt for and find typos and functional errors. ๐
Oh is that you Stefan? Ralfs Airbus Panel parnter in crime?
Yes. That's me.
go for it.
Here are my first results. Happy to lern new things and discuss.