Comments (23)
Any of your proposed solutions is okay. Just decide and 'Run Forest run" :)
To finish 'bootlader mode flashing procedure' we need one more feature:
Moving downloaded file to /FIRMWARE folder plus in case of B&W targets changing firmware name to 8+3 format (xxxxxxxx.bin)
from flasher.
Issues 7 and 8 are fixed 5365aba, let me know what else should be changed!
from flasher.
Great. I will do review in 2hrs.
BTW in interactive agency I was working for years some devs were initially "regretting" they've asked for review. By the end of the day both users and devs were pleased :)
from flasher.
The 'releases' branch in "Simple" mode gives access to the latest nightly as well as release versions... so perhaps just
"To flashnightly ordevelopment versions (which are not considered stable) activate 'Advanced Mode' in Settings tab." for the second sentence?
Which is wrong IMHO. I know due to some files structure they are in release group.
But nightly from user perspective is not 'stable or tested' version. And should not be available in BasicMode.
That's why I proposed
- Releases (tested and stable)
- Nightly (not so tested and may be not stable)
- Other or Development (everything else - may crash every 2 seconds or go into EM etc)
from flasher.
Firmware notes
When there is single one sentence note is okay but with long text like for 2.4.0 release is practically non-usable
To preserve compact form of Flasher that I like we should code button or icon that will open pop-up with scrollable firmware's notes.
from flasher.
- I don't see point to use collapsible folder. Features in all 3 folders must be selected to end procedure successfully. So collapsed folders increase only amount of clicks.
- Radio target -> Radio Model
- Same reveal method can be used because until you select proper "Radio model', at least one voice pack or select proper Disk you can't write anything to SD card. When using reveal method no need to display error messages or code buttons as inactive.
from flasher.
Yes, a lot has been solved since this thread was started. There may be more that needs to be done but this thread has been stagnant for some time so if the issues are still of concern we can resurrect this
from flasher.
So I just updated to UI to make this much simpler, take a look and see what you think!
I like the approach you suggest and i may end up moving to that design in the future
from flasher.
This can probably be closed now as there is a filter in place ;)
from flasher.
Hey @CoderElectronics. I've downloaded today last ver of flasher. Good work.
Few minor adjustments
- Advanced Mode should be OFF by default
- We target non-advanced users primarily
- Nighly & RC should have own 'Branch'
- Writing branch I don't actually mean GH thing but separate dropdown item. By Releases we mean stable. Nightly and RC are not (ie 2.4.0 RC4 has serious bug). So IMHO they should be visible only in Advanced Mode
- I would change 'Flash' in left menu to 'Radio firmware'
- Last selected radio model should be preserved.
- People usually have 1 radio or mainly used radio.
from flasher.
from flasher.
@JimB40 Here are just some pieces of info:
- Yes, on the first time starting the app it will be off by default. If the app has been opened before and it defaulted to something different that will stay persistent.
- We could do that, but again to avoid hardcoding it's going to be sort of messy... I personally think unless we add release name patterns it would not work very well
- Adding now...
- I'm looking at this now.
@pfeerick Updates!!
- Yes, exactly.
- I can do that, that would be handy (releases in advanced mode)
- I think nightly should still be shown if someone wants to try that "edge" out but still stay relatively safe
from flasher.
Exclude by .*RC\d+
?
from flasher.
Ad 2
Hardcoding is always the worst solution so as far as I understand
a. We have to adjust GH so Release candidates and Nighlies land in separate branch
b. We can agree naming scheme so @CoderElectronics can filter them now or ever after same way
What is your point of view Raphael?
PS.
As soon as we do it we'll put good 'how-to' video on line
I was playing more with flasher so few more things:
-
I'd change 'About' to 'Welcome
-
Welcome text proposition
"Here you can flash your radio firmware with different versions of EgdeTX or prepare SD card content.
You can also check progress flashing development versions (which are not considered as stable). To do that activate 'Advanced Mode' in Settings tab. -
Settings Tab
Text in parentheses -> (Development & unstable versions available) -
Radio firmware tab (now Flash)
I Like radio target selection however I would opt for version you used in SD card (drop down). Pros are
- better visual confirmation what target is selected
- Manufacturer name easily fits and is visible.
This is very important point in flashing procedure. If someone makes mistake @ this point it may cost new radio. So 'Jumper T12' and 'Radiomaster TX12' is way safer than 'T12' & 'TX12'
from flasher.
Hardcoding is always the worst solution so as far as I understand
a. We have to adjust GH so Release candidates and Nighlies land in separate branch
b. We can agree naming scheme so @CoderElectronics can filter them now or ever after same way
What is your point of view Raphael?
We do have some sort of naming convention already:
-
Release: git tag; we use semantic versioning and prefix with
v
. Example:v2.4.0
-
Release Candidates: git tag; same as Release, prepended with
-rcX
, whereX
is the RC number (up to 2 digits). -
Nightly: git tag; single tag called
nightly
. This will stay to be nightly build onmain
. -
(once
2.5
gets forked) Nightly "next stable": git tag;[major].[minor]-nightly
. Example:2.5-nightly
(does not exists yet). -
Branches: anything else. We might work out something to get the branch name into some metadata file, so it is easier, or whatever can be used.
from flasher.
Thanks for reminding me (to comment!) 😁
For 8, it still needs the manufacturer names - i.e. just like in the SD card tab. Preferably sorted like that is also, as it then keeps models from different manufacturers together.
After that, I would like to see
- Release's listed before nightly (in simple mode)
- Ensure that firmware versions (in advanced mode) are ordered by date (descending order) (sometimes they are out of order)
- Use commit hash rather the github action run id when building the filename for advanced mode
from flasher.
- Mentioning OTX Companion is not relevant anymore
- Mentioning theme is misleading as this regards Flasher theme not EdgeTX theme. While most asked question is how to
"how to flash nightly or dev
So:
Here you can flash your radio with different versions of EgdeTX firmware or setup SD card content.
To flash nightly or development versions (which are not considered stable) activate 'Advanced Mode' in Settings tab.
from flasher.
The 'releases' branch in "Simple" mode gives access to the latest nightly as well as release versions... so perhaps just
"To flash nightly or development versions (which are not considered stable) activate 'Advanced Mode' in Settings tab." for the second sentence?
from flasher.
Droplists names should be visible all time. labels will serve as guide
- Labels are light grey to focus attention on selection
- Firmware branch -> Firmware type & Radio Target -> Radio model (branch and target are dev slang)
from flasher.
UI Flow
When there are selection dependent UI elements (droplists in our case) designing UI most prefered method is reveal. Using it we don't have to code empty or unselected state in unnecessary UI elements.
Example in Advanced mode
Step 0
- [Flash LOCAL FILE] visible as this independent form server source of *.bin
- only [Firmware type] droplist visible allowing user to select Releases, Nighly or Development
- only [Firmware type] & [Firmware version] droplists visible allowing user to select FW version
- Now we ask for radio model or pre-select with lastly selected (most probable user will flash same type)
- You can add later in Flasher settings 'My radios' so list will be narrowed only to user owned radios simplifying process even more.
- we have *.bin file downloaded so notes and buttons are visible
from flasher.
Plus manufacturer name and dropdown list sorted alphabetically mentioned already by @pfeerick. :)
from flasher.
But nightly from user perspective is not 'stable or tested' version. And should not be available in BasicMode.
So, how do we structure this... separate toggles for showing nightly and development builds, or lump both under Advanced Mode? I'm leaning towards the former, as it is good to expose nightlies without the whole "what is the X branch about" (work in progress branches and PR merges).
For the firmware notes, perhaps just a link underneath that brings up the relevant/release notes page?
I do like (and hate) the 'step-by-step approach' ... it can be beneficial, but at the same time there aren't that many questions being asked, so it becomes more a question of is it beneficial in this instance. i.e. the ELRS configurator also shows all the options at once... which I quite like as there are no unknowns ("what question will it ask next").
from flasher.
@CoderElectronics I take it there has been some progress on this for the issue to be closed?
from flasher.
Related Issues (20)
- SD card setup doesn't complete when there is no sound pack selected HOT 1
- [BUG] Wrong radio target being flashed/downloaded HOT 3
- Incompatible version of dfu util deliverd with win releas. HOT 2
- Change software source HOT 2
- DFU flash error with TX16S but T-Lite works fine HOT 2
- Flash local file missing in Windows version HOT 2
- Change icon to distinguish between Flasher and Companion app HOT 2
- Radio screen doesn't shows up HOT 3
- Version still not being shown on Windows builds HOT 8
- Horus X10 flash goes fail with wrong PCB detected HOT 3
- Tried on X9D 2019+ and won't work HOT 4
- [Feature Request] linux support - deb or tar.gz HOT 3
- SDCard Tab buttons are disabled HOT 1
- flash.bin not found HOT 1
- Error when trying to flash on a Mac HOT 3
- Problem with "Setup SD Card" HOT 6
- All languages selected. HOT 7
- sd card contents
- undefined symbol: libusb_set_option on linux HOT 2
- Build 0cdfd9d does not work on Win11 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from flasher.