Replies: 4 comments 7 replies
-
|
I assume you are using the vanilla GUI scale setting equivalent of the old "Large" setting then, which I think is now called 3 (on my resolution at least, it depends on the resolution you play at as well). The mod screens are designed at and for GUI scale 2 in a 1280x720 window. Using GUI scale 3 in this resolution everything looks horribly cramped and you "only see one button at a time" as a slight exaggeration. The new malilib also has an option to only use a different GUI scale in the malilib-based screens, if you don't want to change the overall game GUI scale. This is what it's "supposed to look like": These screenshots are from the 1.12.2 LiteLoader branch, which is still the main development branch of all the client mods, where have been rewriting and cleaning up tons of the code base over the last couple of years. You shouldn't put any effort in any of the current 1.13+ branches, those are complete "abandonware" once this branch gets ready to be ported forward. As one of the changes, the config options now don't show the internal config name anymore, but instead they now have localized "human-readable" names. Also all of the previous spread out options that are actually the same option now are on the same line, since malilib now supports custom config types. I'm still thinking about also adding a config group that would also collect the related config options for each feature toggle option and add it as a small config button next to it. Also the search functionality has been improved a lot, and it can now for example find stuff from any category. And the search has always been set up such that you can just start typing to search, without having to click the search open first. The tooltip overlay is one thing that I'm kinda undecided on. Sometimes it might be nice if it was anchored somewhere, but on the other hand, at least with short tooltips, I think it's nicer if it follows the cursor and is nearby and not across the screen, so that your eyes don't have to scan for things across long distances if you want to read it for every option in turn for example. But for longer tooltips it can get awkward: although that issue is more pronounced on the right side of the screen when the tooltip can't fit on the right side of the cursor. I'll at least need to still adjust the cursor avoidance logic a bit to put it below the cursor in this case for example: |
Beta Was this translation helpful? Give feedback.
-
|
The version that masa showed is at the moment only for liteloader 1.12.2 , so different loader and much earlier minecraft version @kcrca |
Beta Was this translation helpful? Give feedback.
-
I don't know what you mean by this? Do you mean that the config editing widgets wouldn't be on every row next to the name, but you would click on the name and then you would get the editing widgets somewhere in a single place? Personally I don't like the sound of that, it would break the "flow" of the menu for me (and also being able to see the value without clicking on it...). And the only thing you really gain by doing that is to be able to cram more options on screen at once, if you could make each row less tall. Well I guess it would also solve the screen width issue for the config menu. But most of the other mod screens would still have the same issue anyway, since they are designed for this resolution. Also changing to a checkbox would only gain you maybe 10 pixels of width, which is pretty insignificant and would IMO just make the toggle options more difficult and more annoying to click on the smaller widget, plus the checkboxes usually aren't that "fast and easy to scan visually" to check which options are enabled while scrolling through the list. At least I personally really like these new ON/OFF buttons for that.
I think this would again just "add more visual noise" to the screen if there would be options in two columns. Plus with the larger GUI scale it would mean that you would entirely miss half of the options, not even seeing their name, if they would completely go off-screen on the right. |
Beta Was this translation helpful? Give feedback.
-
|
First, I want to be clear that I really respect and appreciate this whole thing. It's really amazing work, which is why I care. And second, I am totally aware that I get to have opinions, but you who do the work own the decisions. I don't mistake my ideas for mandates, I hope that's coming through. As you know there are many things to prioritize in UIs, and they often conflict. To me the primary issue is that I changed some setting to "12" and now I want it to be "17", and it's way down the list. And I don't know what's possible to play with. So I look to optimize these issues. You seem to prefer a spaced out, calm layout. I appreciate that goal, but if I were the one doing the work, I would prioritize compactness up to -- but not beyond -- being cramped. So yes, with one exception, my ideas are about squeezing pixels without being too cramped to the point where one can fit two columns. And I really respect lack of noise, I have a whole texture pack about that (claritypack.com). I'm just thinking it could two columns short of that. But it does require choosing things that are smaller where you can. I was not suggesting a separate editing window from the list of values, I agree that's not very natural. I was suggesting taking the icon you hover over to get details, replacing it with a region at the top that just showed that info for whatever you're hovering over. I think that would still net out some space. But I respect that you prefer to keep things uncramped, so that probably wouldn't work for you. The one idea I had that might fit your approach is to have a "recently used" tab for N values, where N is the number that fits on the screen. That would address my "where was that setting I just tweaked?" problem. Again, I really appreciate the work, even though I'm running on 1.19.3 with the older stuff. |
Beta Was this translation helpful? Give feedback.
-
I can totally understand that viewpoint as well. Like I already explained and you said I prefer the current layout and "level of compactness", and I don't want to change the default layout of the menu. However as I often tend to do, I prefer maximum flexibility with my mods and their customizability (as evidenced by the vast amount of configs in them...), so now I am thinking about how might it be possible to have a config option in malilib to have a "compact mode" of the config screens. The main "issue" with that, I think, is that the new code supports custom config types, and it's the individual per-config-type config widgets that need to be aware of that option and change their layout and elements to match the preferred style. It's not really a big issue, mainly just that the compact mode layout needs to be supported in a lot of different widgets, i.e. in a lot of different places in code. However the bigger issue (kind of) would be the two columns of stuff. That would be a rather big conceptual difference to the current situation, where there is a list widget that has a list of the configs, and a factory that can make the entry widgets for each config, and it lays out those produced widgets in a linear list, and the search functionality can filter items from that config list. Now again ofc it would be fairly simple to just lay out the filtered list of widgets in two columns. But what is the scrolling behavior with a two columns list? Would both of the sides scroll simultaneously, so it's basically two items on each row? Or would the two columns essentially be separate lists?
Again I can see how this could be useful. But again the main issue is just the "additional mess" it would probably make in code, in this case mainly to detect which configs should be on that list. I'd need to check how things work again, maybe there is already some method that is often used to update stuff that might be able to be abused for this, but then again it would probably not be nice and clean and clear code doing things that way. I'm mainly concerned that every config widget type will again need to remember to call some method somewhere to mark when a config was "interacted with". Another thing that has been suggested is simply having a "favorites category". That would probably be simpler because there could be some common way in the base entry widget to add that config to the favorites list. But ofc this wouldn't be automatic, and if you want to access the same config a few times in a row without remembering to (or wanting to) add it to a favorites list, then it's kinda of no use.
In general for wanting to change a particular config, I would really recommend learning the habit of "just type (the config name)" to search for it. (And like I mentioned, you don't need to open the search thing first - typing in any of the config menus opens it automatically.) It is pretty much the fastest way to find it in most cases, as you don't have to visually scan a (long?) list of configs in any category... depending on the config name ofc and how unique it is. |
Beta Was this translation helpful? Give feedback.
-
Forgot to reply to this... I still don't understand this point? Which icon are you referring to? The config description/tooltip is from the config name label widget. So that is (or could be) already the thinnest thing in the widget height-wise. Or if you meant the advanced keybind settings widget/icon, then like I think I mentioned earlier, that would make that icon too small to convey any meaningful info (it's already pretty obscure and even I rarely see/try to read any info from the icon itself, rather than from the hover info). Oh and also you mentioned somewhere making the hotkey buttons narrower. That's not really viable, as they already kinda are a bit too narrow in some cases for longer key combos like |
Beta Was this translation helpful? Give feedback.
-
|
Ah, well, that’s the thing then. Because I have to ask “what’s liteloader"? Which probably shows how well I’m connected into the latest hotness. :-)
On Jan 31, 2023, at 11:07 PM, vacla ***@***.***> wrote:
The version that masa showed is at the moment only for liteloader 1.12.2 @kcrca <https://github.com/kcrca>
—
Reply to this email directly, view it on GitHub <#296 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHBMQZBYM2CE35ZIAYHCADWVIDUJANCNFSM6AAAAAAUNCZSYM>.
You are receiving this because you were mentioned.
Ken
健
|
Beta Was this translation helpful? Give feedback.
-
|
Well, "latest hotness" as far as the code and features in the mods go, but not he latest hotness as Minecraft versions go. 1.12.2 here means Minecraft version 1.12.2. And for that version the mods are mainly targeting the LiteLoader mod loader. (Fabric got its first public releases during the MC 1.14 snapshots.) The reason for the main development still being in 1.12.2 is that for some time large parts of the technical minecraft community stayed on 1.12.2, and also my personal server is still running 1.12.2 even now. And on the other hand there is over 3 years worth of development now in the 1.12.2 code base that isn't yet in the 1.13+ versions. And it doesn't really make sense to port things forward while things are incomplete (leaving 1.12.2 with an incomplete version of the new code). And IMO porting things forward is easier than porting backwards in MC versions. So basically I just continue developing in 1.12.2 until things are ready to be ported forward. |
Beta Was this translation helpful? Give feedback.
-
|
Here is a link where you can find more info about liteloader http://www.liteloader.com/ |
Beta Was this translation helpful? Give feedback.
-
|
However the bigger issue (kind of) would be the two columns of stuff.
Huh, I would think the reverse was true — having to have each option have two modes was bigger. But two column isn't that uncommon. The normal answer is that one scrollbar governs both columns — the window is on a two-column list, not two windows on two one-column lists. (It also takes up less horizontal space, which is a bonus.) (This is why I suggest the other things, the whole list is below.)
The only other question is whether you sort vertically or horizontally. In this case I would think that horizontally is best:
A B
C D
E F
Not
A D
B E
C F
That puts related options visible at the same time.
"recently used" tab for N values
... the main issue is just the "additional mess" it would probably make in code
My first approach would be to look at the widget change listeners. I don’t know if you use mixins, but if you do, you can add one after the return of the widget’s method that invokes the change listener. If not, maybe you create the superclass for the change listeners, your superclass can do stuff after invoking the subclass’s code. A custom addition would need to use your classes, which isn’t a terrible burden. (Many assumptions here may be wrong, I know.)
(On a totally unrelated subject, why are the color swatches to the right of the “Advanced” button? It looks odd that the button goes left and right as you go down the list?)
(TUS #2: “Info Lines” made me think of drawn lines, not lines of text, maybe “Info Text”?)
All narrowing thoughts:
Reduce the length of text for “Overall Rendering (Main Toggle)”, which seems to be the long pole making the label column wide). Plus some other shortenings (e.g., “Enable” isn’t usually needed, and if you could invert any “Disable” setting.)
Checkboxes (also more familiar to users, if less cool)
Narrower shortcuts window — The box on the “Key Bindings” page seems smaller, and that seems like a good standard.
Narrower “advanced” button icon (I have no specific suggestion, but it would be … narrower :-)
Some smaller RESET button, but I don’t have a suggestion
|
Beta Was this translation helpful? Give feedback.
-
The UI is pretty spread out, making it hard to see and find things -- more things are outside of the scroll window, for example. I'd like to volunteer to try to make it more compact, for which I have some ideas. But whether my ideas are the specific right ones, or you have some better thoughts, I'm willing to take a swing at it.
For me, the ideas are basically:
I know I could just start on my own fork, but before I start playing around in the system I'd like to make sure I'm going down a path you are likely to want to pull when I'm done.
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions