Enable Oolite development (2)

[hiran]

BTW, what do you think of the UI in general? How is it compared to the in-game Expansion Manager?
Do you think it could be improved or made easier?

I'm still very lukewarm on the visual/color-based tag system as it's currently implemented. Not having the tags (or some representation of them) visible in the list itself makes the tags only about 50% useful.

Also, and maybe I'm just looking in the wrong place, I can't see if it's possible to update the expansion list (download the current list) from the Starter itself. Is this an automatic process on launch of the Starter? Is it not implemented? Is this what the "Reload" button does? (If the latter, then "Reload" should be a different word - Retrieve or Renew or something like that.)

Thank you for the thoughts.

The tags should go to the list? That would mean yet another column where for my taste enough columns are there already. So let's brainstorm a bit:
How should the tags get displayed? Are all of them necessary? Would you like to filter based on tags?

Yes, the download of the expansions list is contained and automatic on every startup plus whenever Oolite terminates plus whenever you press ghe reload button. That button not only reloads the online expanions list but also scans the local filesystem for expansions. I named it after the button in web browsers. Thus just use it when you believe something changed online or you modified something on disk. In what way could this change? Does a simple rename really help?

[hiran]

Thank you for the thoughts.

I'm still very lukewarm on the visual/color-based tag system as it's currently implemented. Not having the tags (or some representation of them) visible in the list itself makes the tags only about 50% useful.

The tags should go to the list? That would mean yet another column where for my taste enough columns are there already. So let's brainstorm a bit:
How should the tags get displayed? Are all of them necessary? Would you like to filter based on tags? Would it help to increase the amount of possible columns yet allow the user to choose which of them are visible?

Also, and maybe I'm just looking in the wrong place, I can't see if it's possible to update the expansion list (download the current list) from the Starter itself. Is this an automatic process on launch of the Starter? Is it not implemented? Is this what the "Reload" button does? (If the latter, then "Reload" should be a different word - Retrieve or Renew or something like that.)

Yes, the download of the expansions list is contained and triggered
- automatically on every startup (we need a current list)
- whenever Oolite terminates (the in-game Expansion Manager might have changed something)
- whenever you press the reload button (the user may have changed something on disk)

That button not only reloads the online expanions list but also scans the local filesystem for expansions and savegames. Thus just use it when you believe OoliteStarter is showing outdated data. In what way could this change? I named it after the button in web browsers. Does a simple rename really help?

[phkb]

The tags should go to the list? That would mean yet another column where for my taste enough columns are there already.

Removing the Identifier column would free up some space. It's meaningless for end users. Put it on the data form side, so you can see it if you select an OXP, but you don't need it as a column. You'd then have plenty of space for working with tags.

[hiran]

The tags should go to the list? That would mean yet another column where for my taste enough columns are there already.

Removing the Identifier column would free up some space. It's meaningless for end users. Put it on the data form side, so you can see it if you select an OXP, but you don't need it as a column. You'd then have plenty of space for working with tags.

Nice idea. I moved that field over.
OoliteStarter v0.1.21-elul.4

[phkb]

The Windows installer doesn't update the application if it's already installed. It gets to a small window that says "Preparing to install..." and then closes after a second or two and stops. The only way to update is to uninstall the old version manually first.

[phkb]

And on Windows 11 at least, uninstalling the app removes all the config, so you have to set up everything from scratch.

[hiran]

The Windows installer doesn't update the application if it's already installed. It gets to a small window that says "Preparing to install..." and then closes after a second or two and stops. The only way to update is to uninstall the old version manually first.

And on Windows 11 at least, uninstalling the app removes all the config, so you have to set up everything from scratch.

Good to know. Although currently I would not know what needs to be changed. I lost access to my test Windows machine.
So if uninstalling is a possible workaround, maybe that's what I need to document somewhere.

[phkb]

So if uninstalling is a possible workaround, maybe that's what I need to document somewhere.

It would be a better workaround if you could keep your config between installations. Maybe including "Backup/Restore config" menu options or something similar would be helpful.

[hiran]

So if uninstalling is a possible workaround, maybe that's what I need to document somewhere.

It would be a better workaround if you could keep your config between installations. Maybe including "Backup/Restore config" menu options or something similar would be helpful.

Actually the config gets stored in $HOME/.oolite-starter.conf. This file resides in the user's home, while the application should get installed under C:\Program Files. Is the config file really removed upon uninstall?

[phkb]

I just did a couple of tests, and discovered my problem. I hadn't clicked "Save". So I had installed the previous version, set everything up, then closed it, downloaded the new version, uninstalled the old version and installed the new one. The .oolite-starter.conf file never got created, and so the new version had nothing to work with. Therefore, this issue is not an issue after all.

However, can I suggest you change the "Save" button to be a "Save on exit" check box? If the user doesn't want to save when they exit, they can uncheck it, otherwise it should always save the config when you exit.

[hiran]

I just did a couple of tests, and discovered my problem. I hadn't clicked "Save". So I had installed the previous version, set everything up, then closed it, downloaded the new version, uninstalled the old version and installed the new one. The .oolite-starter.conf file never got created, and so the new version had nothing to work with. Therefore, this issue is not an issue after all.

Ok, that explains your observation.

However, can I suggest you change the "Save" button to be a "Save on exit" check box? If the user doesn't want to save when they exit, they can uncheck it, otherwise it should always save the config when you exit.

Somehow I do not feel happy with that.
I have seen applications crash in middle and thus not execute a save on exit.
I have seen applications crashing while saving - invalidating the data file and thus destroying what was there before.
Hence I prefer to allow the user to control when to save the data.

The save button turns orange if your configuration has changed from the disk. It seems that was not sufficient in your case.
But Mr Gimlet could should give a shout if you exit the application without having saved.

[phkb]

I have seen applications crash in middle and thus not execute a save on exit.
I have seen applications crashing while saving - invalidating the data file and thus destroying what was there before.
Hence I prefer to allow the user to control when to save the data.

Perhaps saving should be removed altogether. As soon as a change is made, it is written to the config file.

But Mr Gimlet could should give a shout if you exit the application without having saved.

This is another possible solution, although it should be a dialog the user has to interact with. Ideally, it should say: "Do you want to save changes to your configuration file? Yes or No". And if you haven't saved the config file at least once it should tell you in the dialog.

Some more suggestions:

• The "Manual" tag color is red with light gray text, which is almost unreadable.
• The "Status" column and the coloured tags are doing some similar jobs (the "O" flag and "Online"/"Installable" tags for example). I think it would make sense to combine the functionality. Keep both, though: the table view should keep the flags, but the data view should have the coloured tags, which would then allow for the UI to be self-descriptive (ie "What does that status column mean? Ah, look, there are the tags that correspond to the flags!")
• The "MissingDeps" label at the bottom should provide a way to view what dependencies are missing. It should be a "hover over it to show a mini-form with the list", or clicking on it does a filter for the OXP list to restrict it to the OXP's with missing deps.
• You probably don't need the time value in the date column. It's not that helpful, and just clutters up the column.

[hiran]

I have seen applications crash in middle and thus not execute a save on exit.
I have seen applications crashing while saving - invalidating the data file and thus destroying what was there before.
Hence I prefer to allow the user to control when to save the data.

Perhaps saving should be removed altogether. As soon as a change is made, it is written to the config file.

That would mean a lot of writes even if the user does not intend to save some experiment.
I still prefer to allow the user to control when to save the data.

But Mr Gimlet could should give a shout if you exit the application without having saved.

This is another possible solution, although it should be a dialog the user has to interact with. Ideally, it should say: "Do you want to save changes to your configuration file? Yes or No". And if you haven't saved the config file at least once it should tell you in the dialog.

Done.

Some more suggestions:

• The "Manual" tag color is red with light gray text, which is almost unreadable.
• The "Status" column and the coloured tags are doing some similar jobs (the "O" flag and "Online"/"Installable" tags for example). I think it would make sense to combine the functionality. Keep both, though: the table view should keep the flags, but the data view should have the coloured tags, which would then allow for the UI to be self-descriptive (ie "What does that status column mean? Ah, look, there are the tags that correspond to the flags!")
• The "MissingDeps" label at the bottom should provide a way to view what dependencies are missing. It should be a "hover over it to show a mini-form with the list", or clicking on it does a filter for the OXP list to restrict it to the OXP's with missing deps.
• You probably don't need the time value in the date column. It's not that helpful, and just clutters up the column.

I changed the coloring of the 'manual' and the 'conflicting' tags (both are still red, but the text is black now).
The date column now just shows the date.

Indeed the status column is related to the tags, which came later and give more information. I am not sure how to put the tags back into the table and stay 'understandable'. I'm open for suggestions.

MissingDeps is displayed if you installed an expansion that requires more expansions and at least one of those is not installed.

Check expansions in the list that have a capital R in the status column. They have expansions listed as 'Requires'. If these requirements are not installed, they are marked with a red error symbol. If the expansion that requires other (missing) ones is not enabled that is no problem.

Now install/enable such an expansion. Those that are required are still not installed. You will see the MissingDeps tag, and the Requires list turns red to hint that something is wrong here. And you should see what you asked for: the missing dependencies are marked up with the red error symbol.

On top of that the list view shows this expansion underlined - it is problematic and needs attention. You can filter for 'problematic' to focus on all those that require attention.

Quite some explanation for a UI intended to be 'intuitive'...

[arquebus]

The tags should go to the list? That would mean yet another column where for my taste enough columns are there already. So let's brainstorm a bit:
How should the tags get displayed? Are all of them necessary? Would you like to filter based on tags?

I'm still partial to one of my earlier suggestions. You don't need a new column, you just need coloration/font (not typeface) variation on the expansion names. Currently, IIRC, you have OXPs with conflicts marked with a brown-ish underline. So more of that, changing the colors of the text, adding bold/italics/caps, more underline colors, etc. You don't necessarily need all of the tags, but being able to see at least the following would be helpful:

- installed/not installed (bold vs normal?)
- online/not online (normal vs italic?)
- up to date/out of date (aka update available) (normal color vs something red-adjacent?)
- conflict/no conflict (this one is already there)

So, for example, an OXP name in bold red with a brown underline would mean that it's installed, can be updated, and conflicts with something else. An OXP in bold italics would indicate that it's installed, but in the non-managed directory.

[hiran]

The tags should go to the list? That would mean yet another column where for my taste enough columns are there already. So let's brainstorm a bit:
How should the tags get displayed? Are all of them necessary? Would you like to filter based on tags?

I'm still partial to one of my earlier suggestions. You don't need a new column, you just need coloration/font (not typeface) variation on the expansion names. Currently, IIRC, you have OXPs with conflicts marked with a brown-ish underline. So more of that, changing the colors of the text, adding bold/italics/caps, more underline colors, etc. You don't necessarily need all of the tags, but being able to see at least the following would be helpful:

- installed/not installed (bold vs normal?)
- online/not online (normal vs italic?)
- up to date/out of date (aka update available) (normal color vs something red-adjacent?)
- conflict/no conflict (this one is already there)

So, for example, an OXP name in bold red with a brown underline would mean that it's installed, can be updated, and conflicts with something else. An OXP in bold italics would indicate that it's installed, but in the non-managed directory.

I get the idea, and it is not too difficult to implement. What do other players think? Is this what would help to make the UI more intuitive?