Yune GUI Rework

[Geeene]

Hi, as mentioned in this PR https://github.com/lushen124/Universal-FE-Randomizer/pull/406

I wanted to do some reworking of the UI to try and make it more scaleable long term.

The current UI just displays everything one screen and scales itself based on the Screen size, like this:

My Goal would be to rework the UI to a tab based system similar to how the Universal Pokemon Randomizer works:

The UPR uses Swing & AWT for it's UI while Yune currently relies on SWT.

Assuming we don't want to swap to a completely new Gui library, the best option for this would be to use the CTabFolder widget from SWT.

A CTabFolder lets you add a number of CTabItem

One Goal would be for me to Move a lot of the UI Composition logic out of the MainView class and into dedicated smaller UI Portions:

Here a roughly implemented Mockup

There is still a lot that can be changed to better utilize the space ofcourse, especially in this tab as an example:

The Rom Selection Group, Seed Group, and Rom Info Group are equivalent to these parts of the current UI:

To move the code of constructing and layouting the content of these groups out of the MainView, my intention would be to have these groups be implemented as extensions of a new Base Class "YuneGroup" which is basically just a wrapper around a Group Widget.

Similarly for all the CTabItems that are necessary:

They would extend a class called YuneTabItem which is an extension of the default CTabItem

doing it this way constructing the CTabFolder is as easy as this:

(though ofcourse these would have to be saved to be able to populate the options from them)

This is the concept that I would go with at the moment.

Will have to see how well this works, especially if I have to do some adjustments to the Views, and with your request to have a summary page.

(probably needless to say but in the current state the randomizer isn't functional)

[lushen124]

Seems reasonable enough as a start, though we probably have to rethink what the categories are for these. Some of these settings might cross boundaries like changes that affect both playable characters and enemy characters. But I think the use of the CTabFolder and CTabItems works out fine for our needs, UI-wise.

[Geeene]

I think the only setting that really applies to both enemies and Player unit are the two checkboxes in the ClassRandomizer View? Other than that I can't really think of anything.

I had just gone with these groupings for now:

Stats -> Bases, Growths, Mov / Con / Affinity Characters -> Recruitment, Shuffling Items -> Weapons, Statboosters, Item Assignment Enemies -> Bosses / Minions Misc -> English patch, Misc View Classes -> Class Randomization, Promotions

For now I had just reused the current View Classes, but I'll see what I can do for improving the layouting a bit more.

[Geeene]

Small update:

Initial Structure FE9

I would go with 3 tabs

Characters: -> Growths, Bases, Classes, Enemy Buffs, Other Character Traits

Items: -> Weapons, Misc Settings (in FE9 this is basically just further item settings)

Skills: -> FE9SkillsView

(no screenshot yet, due to how tall it is, the layouting freaks out, I'll first have to rework that view to be more horrizontal)

This way it really doesn't take that much space.

w/ 1920x1080 Monitor There are still two issues with the top panels

1. If there is an abnormally long seed generated initially, then the shell becomes much wider than it has to be (due to the text input scaling with the text I guess)

2. Rom Info group doesn't distribute itself throughout the surrounding group properly

[Geeene]

GBAFE:

I think merging the Enemy Buffs View with the Stats view makes sense:

This way all but Misc, make decent enough usage of the space that is available.

once again, not much screen space used:

Looking to the future:

• Statboosters would obviously belong into the Items tab.

• If I ever manage to cleanup my implementation, then something like GBA Random Promotions could be moved into a Classes Tab alongside the Class Randomization

• I've also played with the thought of terrain bonus randomization (which does sound really painful to play), and sounds like something for the Misc Tab.

• Maybe Randomized Rewards and Enemy Drops could be moved to the Items Tab and Misc would be more about Game Mechanics (EXP Modes, Casual mode, Fog Of War, 1RN etc.)

[lushen124]

Yeah, I think the rewards and drops can definitely be in the items tab. I think overall, the grouping makes sense, and I think separating it between Stats and Characters is probably the best way to handle that. Game specific stuff would then go into additional tabs as necessary as to not need to deal with conditional layout based on game.

I think I took the easy way out before by just hard coding the expected width, instead of having it size to content, because that was apparently more difficult to do, at least before any content had loaded in. It's been a while, but I wouldn't be surprised if the layout code is just tacky to begin with.

The only thing with screen size, is that I know there are people that don't necessarily have 1080p screens, so I made the entire thing scrollable. We could probably still have individual tabs scrollable inside so as to not need to stretch the window size to accommodate taller boxes. Alternatively, as you said, reflowing the items to be more horizontal is a good solution too.

[Geeene]

Yeah, I think the rewards and drops can definitely be in the items tab.

Okay, I would move them into separate Views / Options then, and I would rename the MiscOptions -> GameMechanicsOptions as that is a bit more descriptive.

I think overall, the grouping makes sense, and I think separating it between Stats and Characters is probably the best way to handle that. Game specific stuff would then go into additional tabs as necessary as to not need to deal with conditional layout based on game.

It works perfectly fine to have game specific setings in one of the "default tabs", as it can just be it's own Tab class:

(These variables are saved as YuneTabItems, so they are agnostic of what the child class is, but they also are just plain not used at the moment, they are only accessed from the tab list, that they will be added to with the addTab method)

F.e. for FE4 I have the Holy Blood settings in the Stats Tab, as holy blood is definetly connected with growths / Stat boosts atleast to me.

with my current code structure having different stats tabs is no issue as they both extend the YuneTabItem, which provides overloads to work with all of fe4, fe9, GBAFE:

and the tab just has to override the appropriate one.

Then this is how the Randomizer / OptionBundle would be constructed in the main view:

Each tab is responsible for adding it's selected options to the bundle, which is as simple as this:

The only thing with screen size, is that I know there are people that don't necessarily have 1080p screens, so I made the entire thing scrollable. We could probably still have individual tabs scrollable inside so as to not need to stretch the window size to accommodate taller boxes.

I'm fairly sure that for PCs 1080p is by far the most common resolution, but I'll make sure that I atleast also test it when reducing my resolution to 1280x720p

Alternatively, as you said, reflowing the items to be more horizontal is a good solution too.

This is how I would change it, the only issue I could see with this is that unlike how it was before there are no header elements for

"Allow", "less likely", and "more likely" though I did instead add the information as a tooltip on the checkbox / radio buttons

I think I took the easy way out before by just hard coding the expected width, instead of having it size to content, because that was apparently more difficult to do, at least before any content had loaded in. It's been a while, but I wouldn't be surprised if the layout code is just tacky to begin with.

There is some more complicated resizing logic currently which decides the width / height hint based on the screen size. I do still have the resize method, but it doesn't do much so far.

ofcourse I haven't tested this as extensively as the old UI has been tested by now, so could very well happen that this will run into some of the issues from before. Will have to see

[Geeene]

Hi,

Update since last time:

I did some testing on 720p, and the way the layout built itself was basically unusable, so I added back the resize() logic from the current version, and it looks much better:

(@720p)

Additionally, as you might be able to see, I moved the randomize button to the top, above the Tabs, that is mainly due to a new feature.

By pressing (currently) CTRL + 1 or CTRL + 2, you can swap between the current Layout, which displays all settings at once, and the tab based one. (1 = All Settings, 2 = Tabs).

The Settings are seamlessly tranfered between the two views, and there is only currently some distortion when it does the rendering, which I think the current version would have too (when swapping games), but fixes it by setting the things visible / inivisible (?) So I'll look into that.

Any time the user selects a different layout, I'm currently saving this to the Preferences.userRoot() similarly to how the Option Bundle logic works, so that the next time the randomizer is started it will keep the same layout.

This could be moved, for example to after pressing the Randomize Button, so that this value is written less frequently, though I wouldn't assume that an enduser will constantly swap between these layouts, but rather pick which they prefer and then stick to that (for the most part).

This does require a bit of refactoring of the current Main View display logic, so that it can be treated the same way as the Tab based layout (with regards to saving / preloading options).

Technically this could be extended for more layout variations, though the more layouts there are the more effort it will be to add new Options to the UI. So I will stick to these two for now.

One more small things I have thought about:

• Create Matching Prf Weapons
• Make Prf Weapons Unbreakable

These settings I feel should be moved out of both the Class and Recruitment View, into their own (or the WeaponsView). This could also benefit the CharacterShuffling feature, in that the options don't also have to be added there, so that you can have prfs for your Lords if you don't randomize classes and Recruitment (which is a setting that I have been using a lot)

[lushen124]

Additionally, as you might be able to see, I moved the randomize button to the top, above the Tabs, that is mainly due to a new feature. By pressing (currently) CTRL + 1 or CTRL + 2, you can swap between the current Layout, which displays all settings at once, and the tab based one. (1 = All Settings, 2 = Tabs).

Looks good to me! Those hotkeys seem a bit hidden, but I think that's fine for the time being. I was thinking of adding a file menu at the top to hide away some miscellaneous things like Credits (since I'm no longer the only one working on this now 🙂) so I think we can add some layout controls there as well.

These settings I feel should be moved out of both the Class and Recruitment View, into their own (or the WeaponsView). This could also benefit the CharacterShuffling feature, in that the options don't also have to be added there, so that you can have prfs for your Lords if you don't randomize classes and Recruitment (which is a setting that I have been using a lot)

I agree. I put them with class/recruitment randomization because I was thinking of those settings when I implemented it, since they really come into play when lord classes change, but it is technically more of an item option (or indeed some miscellaneous section). I'm also thinking of adding some fun mods sections for either mechanics changes or bulk changes that aren't technically randomization, but can be interesting ways to play.

[Geeene]

Hi, good to hear from you again :)

You are certainly right, with the current build you would have no idea that you can swap the gui if you weren't explicitly told. Adding some kind of info menu certainly makes sense.

Do you have any more ideas than the following?

1. Layout Selection Radio Buttons
2. Credits
3. Link to the github
4. Update check?

I'm also thinking of adding some fun mods sections for either mechanics changes or bulk changes that aren't technically randomization, but can be interesting ways to play.

any specifics?

I was thinking about being able to add custom music, probably wouldn't be tooo challenging, and there is a lot of possibilities that users could get from the FEU Music Repository: https://drive.google.com/drive/folders/13pobpxAF6BjyBy4OpJhrIQJ1xGejxvi0

Also fyi, I did post a jar containing most of the features that I have added so far on the FE subreddit in hopes that I get some feedback, though while I know a couple people are playing some runs with it, not much interms of feedback has reached me so far other than some bugs I saw from lurking on the discord

[lushen124]

Those seem like the most we have right now, but it gives us room to add stuff once it's built out so I wouldn't be surprised if more things in the future found their way up there. But certainly, normal randomization functionality would remain in the main window.

Update check is something I would like to have but I also don't know how I'd go about doing it. At a base level, I'd imagine we'd need a way to know what the latest version is published (maybe Github can tell us that directly?) and have the application make an API call to check. Then it'd have to download the new executable and overwrite the old one somehow.

Custom music falls squarely into the fun stuff category and I wouldn't be averse to it. I know OoT Rando does this and I'm sure other randomizers do this too.

But as far as bulk changes are concerned, there's an interesting run I found from a youtuber that adds a flat 10% crit on all the weapons, which makes the game a lot more tense and interesting, and makes luck an actual useful stat. I believe they're manually making that change, so it would be interesting to share that kind of experience to more people without needing them to make manual edits.

Feedback is always appreciated, and I think we are due for another release soon. I think I want to make those changes I listed above and finish out the changes to the character shuffler before I do, and ideally merge all of the outstanding pull requests, because there are a lot of good fixes there. That would include this one, but I don't know how close you are to finalizing the UI here.

[Geeene]

Update check is something I would like to have but I also don't know how I'd go about doing it. At a base level, I'd imagine we'd need a way to know what the latest version is published (maybe Github can tell us that directly?) and have the application make an API call to check. Then it'd have to download the new executable and overwrite the old one somehow.

I haven't implemented something like this before, but I'm sure it's not that difficult,

But as far as bulk changes are concerned, there's an interesting run I found from a youtuber that adds a flat 10% crit on all the weapons, which makes the game a lot more tense and interesting, and makes luck an actual useful stat. I believe they're manually making that change, so it would be interesting to share that kind of experience to more people without needing them to make manual edits.

Makes sense. Obviously it is nothing particularly difficult to add.

Feedback is always appreciated, and I think we are due for another release soon. I think I want to make those changes I listed above and finish out the changes to the character shuffler before I do, and ideally merge all of the outstanding pull requests, because there are a lot of good fixes there. That would include this one, but I don't know how close you are to finalizing the UI here.

I am finished with the implementation, though I do see some small issues from looking over it right now, so I will fix those and mark it as ready for review :)

[lushen124]

I resolved the conflicts and merged master into this branch. Can you double check to make sure I didn't break anything? I had to integrate the stat boosters view into the new tab layout so this was a good test to see if I understood how to add views properly 🙂

[Geeene]

@lushen124 merge looks perfect to me :)

There is only one thing we should change back (not related to the merge), the mainshell title:

You did mention above

Looks good to me! Those hotkeys seem a bit hidden, but I think that's fine for the time being. I was thinking of adding a file menu at the top to hide away some miscellaneous things like Credits (since I'm no longer the only one working on this now 🙂) so I think we can add some layout controls there as well.

I did implement this yesterday & today, so we can still include in this PR if you want:

[lushen124]

Oh, great! I had a version stashed but if you already have it ready, go ahead and add it to this (along with the window name, which can be bumped to 0.9.4 now) and we can merge all of it together. 👍

[Geeene]

Done :)

[lushen124]

By the way, do you see a longer than expected delay when switching tabs? I don't know if it's a quirk with the Mac version of SWT, but it sometimes takes a while to change tabs for me. Like I have to wait for the tooltip to update the bottom area to redraw it.

[Geeene]

When Switching Tabs I never noticed any significant delay on windows, no.

Obviously when swapping layouts there is like a max 1 second delay, though I don't think it's that bad.

Could certainly be a quirk of macOS, I have no way of testing it, and actually also never managed to build a functional jar file for feedback distribution :/

I know you need a cocoa / macos specific swt library but I couldn't get that to work

[lushen124]

Yeah, I'll look into it on my end, but we can probably go ahead and merge this now and follow up if we find a fix later.