GUI Redesign

[Ortham]

Something I'd like to do is try out a single-window design for LOOT's GUI, since as it is, it can get a bit messy with windows and dialogs all over the place.

One of the major problems I have with wxWidgets is that I find it difficult to create responsive UIs with it. As such, since I have experience with HTML/CSS, I decided to look for something which could be used to have a GUI built using them, and I found Chromium Embedded Framework.

UI Feature Implementation

• Message dialogs: Need title, content strings and type (error, info, question)
  • Redate plugins question
  • Redate plugins completition
  • Remove plugin metadata question
  • Remove all metadata question
• Editable Multi-column lists (ie. tables)
  • game list (settings)
  • incompatibilities list (editor)
  • requirements list (editor)
  • load after list (editor)
  • Bash Tags list (editor)
  • message list (editor)
  • dirty info list (editor)
• Filters display
• Editor panel
• Game list display
• Messages display
• Update Masterlist button highlighting if an update is available.
• Sort button highlighting if differences since last sort are detected (including no last sort).
• Current section highlighting (like GitHub Guides have, for example) Not really workable with how the UI is implemented.
• Drag 'n' drop into editor tables
• Plugin priority display
• Some sort of overlay / partial UI freeze while editing
• Correct button functionality for settings dialog
• Validation of table content on editor / settings exit.
• Conflict filter
• Main content text search
• Apply edits made

Stuff That Calls C++

• Masterlist Update button (updateMasterlist)
• Sort button (sortPlugins)
• Apply Sort button (applySort)
• Cancel Sort button (cancelSort)
• Recording of settings
• Saving of settings & edits on quit
• Conflict filter (getConflictingPlugins)
• Menu items:
  • Redate Plugins (redatePlugins)
  • Open Debug Log Location (openLogLocation)
  • Clear All User Metadata (clearAllMetadata)
  • Help -> Help button (openReadme)
  • Copy Metadata As Text (copyMetadata)
  • Clear User Metadata (clearPluginMetadata)
• Game selection (changeGame)

UI Improvements

• Improve the plugin priorities display and drag 'n' drop handling. Instead of replacing the text on hover, the priority info could be given in a tooltip. Also, each plugin should have a "drag" icon displayed to its left when in edit mode, to make drag 'n' drop easier. Maybe just have it display on hover too.
• Improve UI feedback for invalid inputs. Maybe a bit of text explaining what's expected. Placeholder text may also help.
• Split the summary into 3 columns: one for masterlist info, one for plugin counts, and one for message counts.
• Improve the width split between the sidebar and main content so that the sidebar is a bit wider, and also stop it getting wider when the filters are shown (there's less content in it, if anything it should get smaller).
• Highlight the apply button during sorting.

[Ortham]

Icons

I'm using some icons from the Font Awesome icon font. There are a few possibilities for some icons:

• Loads BSA: fa-paperclip, fa-folder-open, fa-cube
• Dummy Plugin: fa-eye-slash, fa-file-o

I think it would be good for the menus and buttons to all have icons.

[Ortham]

Progress is going well now, I think the UI is now receiving all the necessary initialisation data. Two missing things in addition to the list above are:

• Dirty message creation. This should probably be handled during the condition eval C++ code, though maybe if dirty info gets edited it would be better to have it done in JS...
• Population of the editor panel UIs with the metadata.
• Opening of links in the default browser, rather than the LOOT window.

The Javascript code is also in serious need of a refactor. The newer C++ stuff could do with a bit of a tidy too.

[Ortham]

I've been refactoring the JS code in the shadow-dom branch (so called because I started with implementing usage of the Shadow DOM).

As well as object-orientating the code where it makes sense to do so, I've also:

• Taken advantage of Custom Elements support to roll my own helpful HTML elements.
• Used the Shadow DOM's style encapsulation to move some CSS around.
• Implemented usage of the <dialog> HTML element for LOOT's dialogs.
• Moved the version and CRC values inline with the plugin name on each plugin's card.
• Added a tick next to the plugin name for active plugins.
• Re-enabled the flip effect, with fixes for menu overlap and control inaccessibility.
• Improved hover text handling so that the text doesn't change position based on where you entered the element.
• Editor fields are now filled with masterlist and userlist data.

I have run into a Chromium bug though, which causes elements with shadow roots to be undraggable.

I think that's now almost all the UI initialisation done - the only things that still come to mind are:

• Current game name in title bar.
• Current game highlighted in menu.

[Ortham]

I've just realised that the new UI is missing one feature compared to the 0.6 release, that being the ability to view and edit multiple content strings for messages.

It's a difficult thing to have a good UI for, the 0.6 one isn't particularly great. I can't really think of a better way than a dialog box that gets displayed when the message content input element is displayed though.

In light of the difficulties, I've decided to drop this feature.

[Ortham]

Hmm, although I've now implemented the callbacks for wiping user metadata, they don't update the UI completely: the reason for this is that the following properties of the plugin object are partially derived in C++ from the userlist, and so need to be re-derived too:

• modPriority
• isGlobalPriority
• messages
• tags
• isDirty

Also, the card's editor panel gets filled out when the card is created, but it should probably be done when switching to the editor panel. Either way, the plugin observer needs to update the content for when the userlist property or any of the above properties get changed.

Edit: This should now be done as of cefdc91

[Ortham]

@Freso: as resident UI critic, do you have any suggestions on how plugin priority display in edit mode could be improved?

[Freso]

Can you post a current build to Dropbox? I'm not sure what the UI implications of c251f60 or 178ed24 are, so not sure if they'd affect anything. :)

[Ortham]

Can you post a current build to Dropbox? I'm not sure what the UI implications of c251f60 or 178ed24 are, so not sure if they'd affect anything. :)

I just uploaded one before reading this. ;)

[Freso]

Are priorities being displayed in the UI at all at the moment? Loading up LOOT, I see this:
- trying to sort I get #252.

My initial thought is having the raw priority numbers shown just left of the "mod menu" to the right, italicised and in grey text. Possibly with a slightly smaller font size. Possibly with "Priority: " prepended, though I don't think that would be needed. Perhaps as a hover text though.
It would be enough to show the priorities' relationship to one another and be able to verify that setting a given priority actually puts a mod the proper place relative to other/conflicting mods. Doing it this way, there should probably also be a filter to hide the priorities, like there are for CRCs, version numbers, etc.

[Freso]

Oh. In edit mode. D'oh. Let me take another look.

[Freso]

I'm not sure what you mean by "how plugin priority display in edit mode". The current text field seems proper for the job. Showing the priority in the general UI would give more of a hint how to weigh it in the editor though (e.g., you need to have it be less than -100 if you want to sort above fasttravelfromindoors.esp - but there's no current way to tell this except for either reading the masterlist.yaml directly or trial-and-error). It would also show which plugins actually have a priority set, and which ones don't. You could have user-defined priority values be marked with bold text in addition to the gray italic standard text of my former proposal, to indicate it being non-standard.

[Ortham]

The UI is clearly so bad you don't know what I'm referring to. 😢

Go into edit mode, and hover over the plugins in the sidebar to see what their priority values are. Clearly this needs to be done better...

[Freso]

Haha. Yeah. I see it now. :) That would have never occurred to me on my own, though it's not a bad thing. I still think displaying the priorities right there smack-in-the-face on the list would be good. If you think it'll clutter up the UI too much, make the filter default to not showing them. As a masterlist editor, I would appreciate the overview of the (raw, no global priority filtering, please) priorities directly in the list.

[Ortham]

What about this instead:

The globe and exclamation icons could be only shown while there is an editor open, since that's the only time you'd want to know about priorities.

I may be going icon-mad, but it does solve the problem of showing mostly zero priorities and so making it more difficult to see non-zero priorities.

[Freso]

As a masterlist editor, I think I would still like to be able to see the priorities directly in the list, though the icons do seem to be an improvement (based on the screenshot - I don't have time to try it right now). As I said, this could be with a filter that defaults to being off, to not clutter the interface for "regular users", and it could not show the priority for mods that do not have one set (it is 0). But that's just me, and I won't start a crusade if you don't want to do it. ;)

[Ortham]

based on the screenshot - I don't have time to try it right now

It's not implemented properly yet anyway. ;) I'll go ahead and implement it as above, since I think it's an improvement over the current situation, and I can always go back and try a separate priority column later.

[Freso]

Here is my grand (or perhaps not-so-grand) vision of showing the priorities:

The 5000 is a bit smaller than intended, but something like that is what I meant. Not a new column in the list on the left, more like a new <div/> in the mod display that can be shown/hidden like the other info there (CRCs, tags, version, ...) and which wouldn't show for mods where no priority is set (ie., mods that are set specifically to priority: 0 would still have a "0" shown).

[Ortham]

Ah, OK. That looks quite good, though it might mean a fair bit of scrolling if you're trying to set a priority value against others.

[Freso]

Yeah. I think this should be added in addition to the priorities being displayed on the left. This would mostly be for giving hints at a glance as to why LOOT has sorted plugins as it has (e.g., when showing only conflicting mods) and to verify that LOOT has picked up the priority from the masterlist (as I said before, this would probably mostly be useful for masterlist editors, and as thus could probably be hidden by default).

[Ortham]

Note for later: the current section highlighting is commonly known as scrollspy, here is a non-jQuery implementation.