Bikeshed: The thread.
GUI: Graphics Window Renaming and Sort - Hacks, Advanced and Debug Tabs
|
Over the weekend I did some experimenting and came up with this, made somewhat of an attempt to make the underneath settings code actually work but probably not yet.
While I tried to keep unrelated changes to a minimum, but it has to have some key necessary changes to make it all work, there's a bit of renaming going on you see in the "More" group box as I couldn't resist it in this case. The acceptable implementation of such a thing would probably come in more stages as it operates with different logic, but this what you see here is one branch and one commit, some of the technical nature of this at least in my logic requires quite a bit more than just strictly one new combo box, so the removal and shuffling of some other settings is a good idea to make the change have a practical sense and without non-working builds in between. That's why I demoed it here and not even attempted a PR. Not worth a serious attempt while Wx is still here, when it's going it should make a big difference. It was a great learning curve on top of that, in many areas for me being very unfamiliar with the code, but the one that I should point out is Wx, Qt and the whole GUI improvements would suffer or slow down just because of Wx presence, I support the speedy removal of Wx, at least prioritization, the arguments against a speedy removal are absolutely valid as well, however everyone could come to an understanding which things have more weight, a valid argument can still have lower weight if a group of people decides it will treat it differently, it would work like this, if Wx is removed quicker, temporairly there would be some loss of overall functionality/quality but that removal might encourage faster than usual completion of Qt, and an earlier beginning of the improvements which change things a lot under the hood not only visually, it's just a tradeoff, and if that sacrifice is worth it, a few weeks of lack of functionality/polish that Wx still has over Qt - but being a total new guy my opinion obviously does not have to be taken with a lot of weight, I don't expect that at all. EDIT: By just posting this here, not even 30 seconds have passed and I already see the first thing I would change, "Fullscreen - Borderless" should say "Fullscreen - Borderless Auto" because it would still decide the resolution automatically as I meant it from beginning. Additionally I went over some terminology several times before going with "Adjustable" - the earlier version were ".. User Scalable", ".. User Scaled", ".. User Sizable", "Windowed, Resizable", "Windowed, IR-Bound" etc. EDIT2: Oh, the key distinction with borderless ofcourse is that it's not exclusive, that means "Fullscreen - Auto" could say "Fullscreen - Exclusive Auto" or "Fullscreen - Auto Exclusive" (and reorder others for consistency) to make it even more clear and accurate.
I really don't like this.
Those are way too many fullscreen options, many of which also interact and depend on IR settings. We are not bringing back custom resolution to the UI in any form. Let it go. Not to mention your implementation is straight up worse than what we originally had. IR is an enhancement that can (in rare cases) break things. Do not move that. Please don't try to PR this.
I did put some thought into this and at the time I didn't see a conflict with these ones (still don't until I would have to see how exactly in the code), however if the pure amount of choices is a problem, the adjustable ones under Fullscreen could be replaced with one checkbox in the Advanced tab to activate/override with custom values (this does look like a shortcut of having to go to advanced but I didn't do it with that in mind, I just wanted to list all the options in existance that I saw possible)
I'm not part of the Custom Fullscreen Resolution crowd as I didn't had problems or used old CRTs yet to put research and have an opinion into it, but I saw recent talk about it so I included that. I was more coming from the fact that Custom Fullscreen Resolution was removed only due to user confusion, while straight removal might have done the trick, a more optimal solution might be discovered if there is more time and effort put researching it that would in the end not involve complete removal of the feature from the GUI, while still achieving the original goal of removing confusion, one of those things is already obvious and mentioned, to not mention it on most configuration windows but the last, including other ways. As for the IR, the reasoning behind that was that it happens to be the primary thing by which resolution is set in this program, personally I've never viewed it as an extra enhancement how much it really is purely technically, and I don't think I've ever had it below 1080p for any practical use, I have it "for 1440p" these days and the only time I changed it to Native was when testing for a few minutes, these ideas are ofcourse based partially on personal preferences as well while trying to keep it acceptable as a standard. As always, there is no need to take any of these draft talks serious, it's normal for these to be scrapped, or eventually parts of it being the roots of final solutions, it's all part of creating a good idea of the position and opinion of a person with the help of actual examples.
Disregarding my Display Mode idea ... Looking at IR. So it's a rule that if something has potential to break it's not on General tab? Fine but that rule could get renegotiated if it has the votes and maybe IR gets an exception, I just feel like it would make sense replacing the place of FR and other reasons, but I just don't like jumping to conclusions, which the example below will show well.
Maybe if someone could figure out how to fix those IR rounding errors (lines), that's a fair compromise I'd say. (05-14-2018, 04:25 AM)Helios Wrote: We are not bringing back custom resolution to the UI in any form. Let it go. Not to mention your implementation is straight up worse than what we originally had. Actually you said you're fine with it in the Advanced tab. Multiple times: https://github.com/dolphin-emu/dolphin/p...-345534134 https://github.com/dolphin-emu/dolphin/p...-347230041 My implementation wasn't really meant as a serious PR, so I think it would be unfair counting that as weight on the counter argument side. Not something I would want to interfere with, I just meant to show one possibility, but that it would create and open up more thinking and eventually someone may hit it right where everyone could agree. The reason why I'm even talking about this is ... there wasn't really that much opposition to completely remove it, but you are actually right that I was confused about it, just never asked on the forums, so there is validity that sometimes people and myself keep forgetting to raise an issue about something even tho we should, so there could be more hidden confused people out there. To clear up, I'm just talking, like a janitor would come and do some mopping, I don't have strong personal opinions one way or the other on FR, but when the mop sees something it has a tendency to get it mopped up. 05-23-2018, 12:42 PM
I couldn't agree with Helios more!
AMD Threadripper Pro 5975WX PBO+200 | Asrock WRX80 Creator | NVIDIA GeForce RTX 4090 FE | 64GB DDR4-3600 Octo-Channel | Windows 11 23H1 | (details)
MacBook Pro 14in | M1 Max (32 GPU Cores) | 64GB LPDDR5 6400 | macOS 12
05-23-2018, 12:52 PM
That was back when it looked like I needed to compromise. So I considered the least bad option.
Now I don't with this. Also, JosJuice's implementation was way better. |
« Next Oldest | Next Newest »
|
Users browsing this thread: 1 Guest(s)