Open Al12rs opened 4 years ago
The OMOD installer would go a lot faster if someone else did all the dialogues. I'm not sure the features here capture everything OMOD can do, though. Many of the fields we could use to autofill/suggest stuff are listed here: http://timeslip.chorrol.com/obmmm/index.html.
The main options dialogue would be sensible to reuse, too. The features OMODs allow for each decision are:
Before I got busy, I had something that could do most of this okay-ish, but only okay-ish.
@AnyOldName3 The dialog is supposed to be used before the actual installation procedure, if the user lets things as default the installer plugin can still set all these things. Like for Fomods, I would show this dialog first and then procede with the normal Fomod choice dialogs.
Maybe copy this over to the Omod installer issue
The dialog is supposed to be used before the actual installation procedure, if the user lets things as default the installer plugin can still set all these things.
I think this is kind of incompatible with:
- Allow the user to either merge or replace one of the listed existing mods.
I don't think users want to choose to merge or replace before knowing what is inside the mod (installed or to be installed). I personally find this already very annoying with the NCC installer.
We probably need two dialogs: one before the actual installer and one after. The one before could be given to the installer so that they can re-use it instead of showing a new one: you basically want a dialog with a top-header with mod name / whatever, a middle widget that installer can customize, and a bottom button row that installer can also customize.
That sounds quite complicated though and would add to the amount of clicks someone that just wants to install a new mod without tweaking anything needs to press. Maybe add a button to show a preview of the contents (visual tree like we offer for bsa contents) so that people can check out with a click from that dialog. Assuming there is still the Manual install button and cancelling the manual setup brings back this dialog then users can just use that to have a look at the contents instead (but preview download contents would be a cool right click menu on the downloads tab).
That sounds quite complicated though and would add to the amount of clicks someone that just wants to install a new mod without tweaking anything needs to press.
I don't see what it would add compare to the current state of things?
Maybe add a button to show a preview of the contents (visual tree like we offer for bsa contents) so that people can check out with a click from that dialog.
Showing the contents make no sense for FOMOD or BAIN installer, or even other installers unless the archive is perfectly formatted. So if we want to show any kind of "conflict" with the existing mod (so that user can decide on merging / replacing / renaming), it's impossible to do it before the actual installation procedure.
None of the data in an OMOD is in the top level. There are several layers of zipping. You're never going to get a nice tree out of it.
Also, we can't really get scripted installers to go inside a parent widget. I don't know about C# FOMODs, but C# OMODs can and do create native windows as and when they please.
Also, we can't really get scripted installers to go inside a parent widget. I don't know about C# FOMODs, but C# OMODs can and do create native windows as and when they please.
Yes, those are kind of differents. But currently you still need a pre-dialog to get the name of the mod, etc.
The OMOD installer is external, so this is hard to apply because the user will be asked to replace / merge / replace even before starting, which I personally find not very user-friendly, but that's one the custom installers work currently.
The installer dialog should:
We currently have these installers:
The new dialog should either be used by the installation manager directly, or be implemented in UIBase to allow the various installer plugins to use it. It should remember geometry and state of some of the options so that the user doesn't need to redo them each time.
Edit 27/05/20: Upon discussion we concluded that the choice of the name can be done with a dropdown where existing mod names are clearly advertised as such and all the other options are part of a thic header that is shared as a base template for all the installers to use (easier implementation of new installer plugins).