jaremko / archerbc2 Goto Github PK

Add please visualisation of short-name-bot and short-name-top parameters as Icon in the app gui, cause It's not obvious what i need to fill there when profile builds

I think that main actions with file not have to be hiden in dropdown menu, when you working with many profiles in the same time.. ghosh..

It would be handy for managing large distance sets.

After opening the file dialog to save file, whatever i do, saving file or clicking on cancel, app freezes for few seconds without indication of some actions executing on background

Make autobackup profiles to AppData directory on it's open, to have a way restore previous data if it corrupted

We need Ukrainian localization ASAP.
It shouldn't be too hard since seesaw has j18n support.

See examples/j18n.clj , examples/j18n.properties and examples/j18n_de.properties

Currently, we have user selected color themes specific to each individual installation. In a similar manner, it would be beneficial to allow user-specified units of measurement such as distances, weights, and speed.

I propose this feature could be implemented as a popup frame containing list-boxes. Each list-box would allow users to select a preferred unit of measurement for a specific type of value. The selected configurations should then apply to all values of that type throughout the application.

At present, we utilize a static unit of measurement within our specifications. These specifications could serve as a foundation for this feature as they represent our internal unit representation.

The primary task would be to create a conversion table that can convert any possible unit (chosen by the user) back to our base units, and vice versa. A possible implementation could be a set of maps where keys represent units and values represent conversion coefficients. This approach seems straightforward and could be the basis of our implementation.

A basic modification of our spec conformers should do.

We need it implemented ASAP.

Move the Dialogs on app start to top, cause they dont shows the icon in taskbar and if many windows opened on the desktop the app dialogs hides under it

https://github.com/JAremko/ArcherBC2/blob/main/doc/user_guide/ua/pictures/wizard-bc-type.png

Use app specific directory as default directory to saving profiles instead of Documents, it have to simplify searching the files, cause wouldn't need to search it in many other files in Document dir
Use C:\Users\%USERPROFILE%\ArcherBC or C:\Users\%USERPROFILE%\Documents\ArcherBC for example

Keep current Windows build for x86 (Win7 WinXP) but add new one x64 with jpackage for all platforms (including Linux) .

Currently, in our file operations, we don't have the ability to pre-specify the filename in the file chooser(it always starts empty). This feature could improve the user experience by providing a recommended filename, saving users' time, and reducing the possibility of typos or naming inconsistencies.

We'll have to rework SeeSaw's file chooser to support predefined(pre-filled) filenames.

Add please displaying a profile metadata of .a7p file on click it in files explorer
Show it in status bar or add widget to right side
It would be useful without opening the file for editing to see such data as a rifle / cartridge, etc
e.g. as on image below

Logics of this calculations you can found here
https://github.com/JAremko/ArcherBC2/blob/main/doc/user_guide/en/USER_GUIDE_EN.md#powder-sens

While handling file loads and imports, it has been noted that there's an absence of error-status indicator. Specifically, files that do not contain valid data are being silently rejected. This behavior suggests that the parser may be encountering errors and silently fails.

Relevant code is in rosetta.clj file

We employ Java's NumberFormatter for handling formatted fields. It effectively manages real-time input validation as users type in values. Additionally, it processes the formatting of values according to specified precision (fraction digits), and efficiently eliminates spaces and other unwanted characters. This feature proves to be quite useful!

However, NumberFormatter utilizes the current locale settings to determine the handling of comma , and period . characters, treating one or the other as the decimal separator. Unfortunately, it lacks the configuration to accept both , and . as valid decimal separators.

Given the criticality of this part of the code to our project, and the high visibility of potential lag during user interactions, it is crucial that our solution remains highly performant so I propose we consider reimplementing this feature at the Java level.

Add proposition of file name on it's saving, base it on profile metadata, like "new_profile_<rifle_name><ammo_name>_.a7p"

It have to make searching the profile simple in files three

Also, maybe better use default system FileOpen/FileClose dialogs instead of framework's dialogs. They are more common, fammiliar and userfriendly that that's using now, a.g. below

In spacetools I use cats.monad.exception for reification of generic problems in the pipeline. This way a problem can be passed back as an alternative to a "happy path" value. When used with nio2 it allows writing in-memory test of file ops.

• update start dialog docs
• update start dialog docs screenshots

Currently, after deleting a distance you need to click again for deleting next. It would be more ergonomic to auto select next distance (if any) after deleted one.

Add the selection of a set of distances to the menu for editing the table of distances

Add a set of "ultra long range" distances to the program (up to 2000m)

Able to run two update processes running in the same time if 2 app instances launched in the same time

Steps to reproduce:

1. Installed app version have to be not the latest version
2. execute 2 instances of the app. They both runnin the update dialog
3. Click the update button in both dialogs
4. App would be updated and wouldn't executing no more

Solution can be is preventing running 2 instances of the app in same time or prevent running update process twice if one is already running

We stand at the cusp of a bold endeavor, a beacon of progress emanating from the heart of our very application. In the annals of software history, revered tools such as text editors and their Clojure counterparts have raised the standard, offering the promise of undo and redo functionality. This virtue of user-friendliness and efficiency, hitherto unattainable, remains yet beyond our grasp. Our application, in its current state, lacks this much sought-after capability, which may prove a deterrent to those daring to make more audacious changes and demand of them an undue vigilance to prevent errors.

Now, we gaze upon the structural backbone of our application, holding fast the vast majority of state within a single, mighty atom. This unified foundation could be the vessel by which we bring the blessing of undo and redo capabilities to our users. Yet, we are confronted with the absence of certain vital elements - the current tab, the focus, - not secured within this atom, creating an onus for additional development efforts.

Moreover, we must square our shoulders against the gusts of compatibility, wrestling with the likes of seesaw, a system which may not readily accept our transformative design pattern. And yet, we are not daunted.

We must turn our gaze, too, upon the specter of application performance, a concern that looms ominously in the background. Less robust systems, like the noble WinXP, may falter under the weight of extensive state data, the very lifeblood of our proposed undo function.

So we set forth today, not because it is easy, but because it is hard. We propose to venture into the uncharted terrain of developing the undo and redo functionality, cognizant of the challenges and limitations that lie before us. We do this, not to make our application merely 'friendly', but to ensure it is a beacon of efficiency and accessibility, shining across the vast array of systems that dot our technological landscape.

Let us then, my comrades, not shy away from the complexity of this task. We choose to integrate the undo and redo functionality, not because it is simple, but because it elevates us, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one we are willing to accept, one we are unwilling to postpone, and one we intend to win. Let the words of our efforts echo through eternity: We choose to go to the moon of software development.

Combine sections "drag model type" and "single/multi-bc definitions" of the profile creation wizard into one section

We can show it to a user in the update dialogue. Simple link to the file in the repo could do. But we'll have to provide at least two translations (UA EN).

1. Enhance Windows XP build process
   Our current process for building a Windows XP compatible executable involves the use of an outdated version of Launch4j and JDK 8 (update 202) in a Windows XP Virtual Machine (VM). While this process generates a binary that can function well across all Windows versions, it's far from a sane way of doing thing.

2. Implement PR Testing We currently don't have a system in place to automatically test Pull Requests (PRs).

Add keyboard shortcuts to Menu actions (Ctrl+S, Ctrl+Shift+S for the saving, Ctrl+R for reload etc)

If we reinstlling the app with installator it not uninstall previous version and after that sometimes the new version would not be able to open, it raises java error

1. Multi-Select Deletion: The ability to delete multiple items at once is requested. This feature would help manage large amounts of data more efficiently.

2. multy drag-and-drop Moving around segments of the list would also be cool.

Manually entering numerous custom coefficients can be tedious.

When a different file is selected in the file tree it sometimes loses focus. It's annoying when traversing the tree with arrow keys.

1. Add please export/import of Custom drag match functions in one of popular format, like lapua drag function (.drg)
2. Make custom drag function editor with same gui as distance editor, it's not obvious to set row count before fill the drag table, adding rows to table with + button is better, or predefine the table with 100 rows for example

Instead of hardcoding calibers we can download them from AWS in CI (similar to how we handle hardware updates now)

The app should works asis on Mac but we need to wrap it into an image(installator).

This can be done with GitHub actions like we wrap it for Windows.

We can use jpackage

Floating point fields must accept both a period and a comma as a floating point number separator. Dot symbol raises form validation warning

As known the app still have issues on update process, so many will be good to not commit that all to a master before testing

Replace file tree to the side of app, not as tab and make it always displayed on the screen (as is in Explorer or common IDE)
It would simplify work with 2 or more profiles in same time

The current implementation of the profile selector could be improved by showing more relevant information.

1. Move Profile Selector to a Side Bar: Relocating the profile selector to a side bar could provide a cleaner layout and enhance user interaction.

2. Introduce Scroll Panel/List Format: Replace the current display format with a scrollable panel or list. This would improve navigation, especially when dealing with a large number of profiles.

3. Enhance Information Displayed: Continue to display current information (mainly profile descriptions), but consider adding additional data such as the selected drag function and the zeroing distance. This additional information would give users a more complete understanding of each profile at a glance.

4. Highlight Active Profile: Make it clear which profile is currently selected. This could involve highlighting, using a different color, border or adding a marker/icon next to the active profile.

5. Integrate Delete and Duplicate Buttons: Embed the delete and duplicate functions within each profile in the list. This could improve the speed and convenience of managing profiles.

Performance Considerations:

In all these improvements, we need to be mindful of the potential performance impact on low-end systems. We should aim for an implementation that offers the proposed improvements while keeping system requirements low.

Objective

Enhance the user experience and functionality of the ballistic function view by improving its data visualization/editing features. Specifically, integrate a 2D graph for visual representation of ballistic coefficients, and a user-editable/re-sizable table to manage these coefficients.

Detailed Requirements

1. 2D Graph Integration: Develop and integrate a 2D graph that visualizes the ballistic coefficients data outlined in the table. The graph should be responsive and immediately reflect changes in the data when any modifications are made to the coefficients table.

2. User-Editable Coefficients Table: Construct a table to store, display, and allow the editing of the ballistic coefficients. Users should have the capability to modify the coefficients directly from this table. The table should have a capacity of up to 200 rows for the :custom type and up to 5 rows for :g1 and :g7 types. After converting :g1 or :g7 into a :custom type for graphing purposes, the value set may contain more rows, up to 200. (while the table view stays the same).

3. Data Representation: Ensure the appropriate usage of data based on the type of function. For the :custom function, the data should be utilized as it is. However, for :g1 and :g7 functions, the data should be transformed into a :custom representation solely for the purpose of graph visualization.

4. Respect resource constraints It should run smoothly on low-end hardware.

The file wizard.clj contains a substantial amount of code duplication from widgets.clj.
We should DRY it.
Furthermore, widgets.clj has expanded significantly in size. It would be beneficial to extract helper functions into a new namespace to improve manageability and readability.

Since new items are added at the begging of the list, it is virtually impossible to add distance to the long distance list.

Instead, distances should be added before or after selected distance.

Display a summary screen upon saving. This summary should encapsulate key details about the saved data and highlight any potential problems or errors.

Specifically, it should include:

1. Notification if all ballistic coefficients are not unique and reject save since this is invalid state.
2. Highlight any rounding that has been applied to 'zero_x' and 'zero_y'. It would be beneficial to notify the user about this rounding and explicitly state the final rounded values in the summary screen.

This summary should provide a concise overview of the saved data, facilitating better understanding and troubleshooting. It would be a valuable feature if the summary could also showcase the differences (if any) between the previous and current state of the data (a diff, in other words).

Add settings with the ability to select measurement units (metric/imperial/etc)

example:

1. Create a mountpoint for galery storage to the tree view (in AppData for example)
2. Add syncing it in the background
3. Make the profiles in gallery readonly
4. Add drag-n-drop to the tree view to simply adding profiles to the device/workdir

You can use a separated github repo or brunch in app repo to store and update the gallery and also for the versionong
After use GitHub REST API to fetch for the latest updates by the commit, and get the download links to the files or branch archive
In this way the update of the gallery will be available in just few http requests

My own gallery you can fing here
Also you can get the updates by the release version from the jsdelivr CDN
It is the profiles library that's already has the checked for the valid data profiles

After loading a shootout from another profile, everything is overwritten in the current profile instead of just zeroing data

Join this screens to one. It's too strange and useless to have a separate screen for each one parameter