UI remake

[sikaxn]

Remake the Ui with a better workflow
UI nolonger stuck while downloading

add a macos build script for on macOS debugging

[JamieSinn]

We don't have a way to codesign these binaries.

[JamieSinn]

This is not the package scope.

[JamieSinn]

@sikaxn - Can you help explain some of your rational and choices here? This to me strongly smells of AI without a lot of logic behind the reasoning. The OSX build script specifically was a big red flag.

I'm not against using AI to help, but having logical and clear decisioning behind each choice is still a requirement.

You've made some sweeping changes here in the functionality of the app that aren't really helpful from a users perspective.

1. Downloading the software lists is now downloading all in the given folder - of which, not all may be valid. This was previous restricted to the format of {program}{year}.json to ensure there was a limited scope of downloaded files for both security, and simplicity. https://github.com/JamieSinn/CSA-USB-Tool/blob/main/CSAUSBTool.CrossPlatform/ViewModels/ProgramYearViewModel.cs#L38
2. This massively changes the workflow; previously you just had to select a season (pre-loaded in the background on starting the tool), and then the software you wanted. What was the reasoning behind this change to a very manual and very verbose workflow?
3. This also forces you to manually verify MD5/Integrity instead of it happening before the download is initiated to de-duplicate the downloads.

I do like the re-design on the selector/tags highlight, that's much cleaner to show in the list view; but the tabbed setup also was quite similar to that of the rest of the software suites provided by vendors, and the tab workflow would be good to keep as is if you can incorporate it.

Would appreciate some clarifications here, as with the current state/explanations I don't want to merge this as is.

[JamieSinn]

See larger comment

[sikaxn]

0. I have to figure out a way to build osx binary locally for test and that script is the one i use to build .app from the source. Maybe it should be excluded from the repository.

1 and 2. Downloading the software lists (Step 1) does not download all in the folder. Instead, it call a GitHub API (https://api.github.com/repos/JamieSinn/CSA-USB-Tool/contents/Lists) which list all the avaliable file on /Lists under the directory. It is Step 2 that fetch the latest json (based on year) which used populate the software list. Under current configuration it will do Step 1 and Step 2 automatically. So there is no need for user to physically click step 1 and 2 button (see gif on #167). The year get chosen isn't based on DateTime.Now.Year; but rather depends on the repository's largest year on filename.

Yes this need an extra APi call but guaranteed to work.

3. There are still room for MD5 workflow improvement and handling for downloaded file can be improved. If file exist, a batter way would be verify it's MD5 instead of redownload. I will improve on this.

4. I think tab workflow can't coexist with list + tag workflow. These are just two distinct UI style. So we have to choose between one of it. I am not a fan of the old tab style as someone might want to download some software from one list plus something extra that's not on one tab. Usingg tag makes this process easier. What's your thought?

Also i don't know if this is just me but the current GUI tool barely works. It would freeze when I click download only unfreeze after download done.

[JamieSinn]

To clarify what I meant by the auto-download, is that it will automatically download a file that potentially should not be downloaded (ie - someone incorrectly uploads/edits a file with the year FRC9999.json) - this will break the functionality of the app for everyone - instead of binding the default to the year. There's much more risk involved with this approach than using the current year, which is generally safest due to the annual repeating nature of the tools use.

Could you explain a bit more on your reasoning/rationale behind the workflow changes? The change to use the github API isn't really clear as to why this was done, nor is the year selector clear.

The freezing and unfreezing is based on the fact I use the main thread of the application to download the software. This was mildly intentionally done to prevent concurrent downloads without too much hassle. I'm not massively tied to this process though as it was done as a way to prevent some user error without massive complication.

Tag vs Tab I don't really have a preference to; but given the workflow for this is primarily used by CSAs to prep files for a given year - I don't know how much value the tag use case brings as a default sort/filtering option. I'm happy to be wrong about this; as I ironically haven't really used my own tool recently.

[sikaxn]

The current implementation freezing the UI during download is a bigger practical issue than the fetch strategy itself, so personally i feel like improving that is a priority. The “bad year file” scenario is possible, but in practice the repo is controlled and low risk enough that it shouldn’t block having a flexible workflow. Users do need to handle non-default cases (other programs, previous years, manual selection), so hard-locking to only current year is too restrictive.

Instead of debating assumptions further, how about I expose all relevant settings so behavior can be configured explicitly per use case.

Also I am working on a switch between tab and list. I do need couple more time to get it working.

[sikaxn]

Now it can switch between tag mode and tab mode.

Also setting button could be hide from user using setting checkbox. Enabling this will hide the settings button on the main window. Temporary access: start with --showsetting or type showsetting on the main window. To permanently disable hide_setting, either remove the "hide_setting" line from config.json, or temporarily show settings and uncheck this option.

[JamieSinn]

I like the idea of the settings page quite a bit. Lets move to use a proper top-nav bar drop down item; and change the settings to use a proper .NET Native method for it.

I'll take a re-review after this is implemented.

[JamieSinn]

Please remove this, we should never be distributing batch/shell scripts as part of a launch parameter. This should just be part of the documentation, or better yet - a top nav bar menu dropdown to open the settings.

[sikaxn]

There is a button to open setting. However, it can be set to hidden. (see photo from previous comment, top right corner)

If setting page is set to hidden, there have to be some ways to bring it back. There are three method to do this. Remove the corresponding key on json, type enable setting on window and use launch parameters.

[JamieSinn]

Curious - why add a solution file here? There is already one at the root? https://github.com/JamieSinn/CSA-USB-Tool/blob/main/CSAUSBTool.sln

[JamieSinn]

This isn't following C# best practices.

https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration

We should be using the Microsoft.Extensions.Configuration native system for configuration; not writing a custom one.

[sikaxn]

I been quite busy for the past couple days as my team just done Shanghai Regional and there are some important wrapup I needs to do with our team.

I will be looking into Microsoft.Extensions.Configuration and impliment it. Yes your suggestion is valid and it should be the way to do.
CSAUSBTool.CrossPlatform.sln is some shit my IDE did. will keep it for debugging and working towards removing it.

Some clarification about settings page needed. Setting page can be designed to be hidden.

1. If you prefer replace setting button with top-nav bar drop down, do you prefer menu > setting or menu > many setting options instead of a full setting page?
2. I can't think of any additional menu item on the drop down. When setting is hidden from user, do you want the whole menubar gone? (Still thinking how to do this)

I will get rid of LaunchWithSettings.bat.

[sikaxn]

This does not look elegant enough compare to the old setting button unless we add more option on menu bar.

Or did I get you wrong?

[JamieSinn]

This does not look elegant enough compare to the old setting button unless we add more option on menu bar.

Or did I get you wrong?

That's the correct flow I had in mind. I'd prefer moving all the selectable types (ie - year, program, etc) to the top bar as shown.

Maybe move your shortcut buttons (select all, etc) into an "Edit" menu in the top bar?