New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mainmenu Improvements: "Join Game" tab + code cleanup #9505
Conversation
I am 👎 for combining the game mode icons in this way. If done, this needs discussion in an issue first of what information needs to be shown, then how to display that in a single column, probably by using a new set of icons with superimposed elements. |
Well, here goes my (disagreeing) reply:
|
The problem is that creative is a concept that is defined by minetest game. Creative, damage, and PvP is perfectly valid in certain games - the server may not have a way to heal using creative. I can imagine a PvP game where you can place infinite blocks whilst attempting to knock people off their blocks - like spleef |
A spleef server should be marked as just PvP. There shouldn't be three flags at all. |
In which case, the order of your priorities in this pr is wrong |
Let me rephrase: A server should have one gamemode. Current common gamemodes are creative, survival and PvP, so they are supported by the serverlist & my mainmenu improvements. |
Minetest has no concept of a game mode |
Well, servers which fall outside of the common categories can just set none and get no image at all. |
The flags are set using the setting which control the various things. It's not possible to set none and retain the functionality |
In my fork I use |
Your X to clear the search looks so disgusting. Sorry, but it’s better to remove it. |
I won't. I will probably replace the texture (with a trash bin or the like, this one has ugly scaling artifacts). Note that I have taken the "X" and the magnifying glass from the creative mod of MTG.
Done. |
Thanks for your review. I'll address your points by their numbers:
So summarized: I will address point 4 and reduce the empty space next to the icons. I will also tweak the lag indicator, addressing point 6. All other points are still to be discussed. |
Points addressed, screenshots updated. Feedback is welcome. The lagometer now shows a combination of lag + ping, where lag is weighted twice as much as ping. |
self.tablist[self.last_tab_index].tabdata, | ||
self.tablist[self.last_tab_index].tabsize | ||
) | ||
formspec = formspec .. tab_content | ||
end | ||
return formspec |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is more potential in this function:
- invert the
if not self.hidden and (self.parent == nil or not self.parent.hidden) then
condition andreturn nil
early - store
self.tablist[self.last_tab_index]
in a variable since it's often used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do when I have time
end | ||
|
||
table.insert(details, ",") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since ,
is the field separator, shouldn't this be
table.insert(details, "") table.insert(details, "")
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I originally had it this way, but it doesn't matter - because table.concat({"whatever", "", "", "whatever"}, ",") == table.concat({"whatever", ",", "whatever"}, ",")
- and this way, it should be better for performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that, but for correctness I consider it better not to mix the separator into the real data just because it gets the right result.
std::string topush = server["name"].asString(); | ||
lua_pushstring(L,topush.c_str()); | ||
lua_settable(L, top_lvl2); | ||
for (const auto& string_member : {"version", "description", "name", "address", "port"}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please declare the array explicitly on a separate line (the others too)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this defeats the purpose of shortening the code; if the arrays are only used at one place, why explicitly declare them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For readability?
I disagree here, it's fine for one tab to have a colored sidebar.
Hmm, this might be an issue though. Would it be detrimental to the design to expand the servers tab to be sized consistently with the other ones? |
@@ -15,7 +15,7 @@ | |||
--with this program; if not, write to the Free Software Foundation, Inc., | |||
--51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. | |||
|
|||
-------------------------------------------------------------------------------- | |||
local server_lookup |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
almost forgot: why does this need to be global variable and which purpose does it serve?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
server_lookup
is a local variable I introduced. It basically represents the table rows. It is used while generating the table & when to identify selected entries.
It is inconsistent for one tab to add this color, and it adds nothing |
Is it really? None of the menu tabs have matching layout, so there is barely any consistency you can take as a measure what is allowed to be different and what isn't.
Increased visual appeal is definitely not "nothing" |
I'm in favour of adding a distinction to the sidebar - this exact same background is in my mainmenu tabs redesigns (ignore the global sidebar experiment) I'm don't like how this is done as part of this PR, or without doing other tabs. I was under the impression that it was three tabs - this one, start Game, and content - that have full sidebars, but it's actually just content I'm not going to oppose it in this PR, but you should at least use the correct spacings. The space between elements is the most important thing to determine how the user perceives hierarchy and grouping. There needs to be 0.375 padding and 0.25 spacing. Padding is the padding from an important container to its contents. In most cases, this is the formspec window, in this case the two important containers should be the server list and the sidebar. Spacing is the distance between not directly related elements, such as the search bar and the server table. Directly related elements should be touching, like the search bar and the search button. These values of padding and spacing are done semi automatically by the formspec code when you don't have real coordinates on. See the design I linked for an example. Tldr: add more space been sidebar and the serverlist, use consistent space throughout. Put a gap between the refresh and search bar as they are not directly related It would be good to document this somewhere, and create design guidelines. The values I gave for padding and spacing are arbitrary and could be tweaked - the important thing is to have different amounts of spacing to show hierarchy Tabs need to be the same size.
The content tab does. The start game tab could be layouted to match it, but doesn't currently |
Ok I've changed my mind-go ahead with the sidebar but use consistent spacing |
I've currently worked with a consistent spacing of 0.25, the sidebar however has 0.125. Will increase that to 0.25. Edit: done.
Yes, I think so. Forcing all tabs to have the same size doesn't work well. Regarding PR structure, I'd like to save me the hassle of creating multiple PRs/commits. Is this possible, at least if I get my design improvements accepted? |
I don't understand your question but having commits as useful "units" is a hard requirement either way. Depending on which of your current commits touches what, it may be sufficient to squash a few to get some organization into them. |
I have the impression many people misinterpret “Rebase needed” as “Please squash into one commit” … Note sure if I'm right. |
Opinions needed: What about having all tabs of equals size, but not fully using up the available width (leaving free space). The free space won't be as noticeable, as it will have no background there. |
I think the current tab size is fine, i.e. the tabs are as large as they need to be. This tab design is pretty standard across the board in software UIs, as far I can tell. So, no change to the tabs is needed in your PR IMO. The real problem with Minetest tabs IMO is that they're forced to be semi-transparent, but that's completely off-topic. |
Any progress? I think these changes are good and would like to see then in 5.4.0. |
Closing this. The mainmenu has to be redone entirely. |
Who knows when that will come. I'd still prefer these improvements in the meantime. |
Before
After
To do
This PR is Ready For Review.
How to test
Fire up Minetest.