UI: Display option

[BacchusFLT]

This is a rather minor thing:

The Display\OSD Key Debugger option turns on and of the feature. It would seem logical to have that as check-marked once the feature is on and unchecked if it's off.

Also, the same checkmark indicating the current mode between the fullscreen/100% and 200% options.

[lgblgblgb]

Not possible to do so with 100% / 200%. The problem that user can re-size the window any time soon. So there is no strict 100% or 200%, ie it's not a setting to have 100% or 200% zoom but a "command" to resize display, but can be resized again by the user. Also in case of advanced VIC-IV functions the window must be resized automatically as well trying to find a nearest user-initiated zoom ratio when PAL/NTSC changes or border emulation for example. So it's kinda a complex stuff, I do without checkboxes by will, so it's not a bug. Also note, that Mac version does not even have checkbox currently implemented in the UI layer, so I don't want to push new checkbox usages once the Mac code is fixed (even if you don't use the Mac version, still the code base should be work on all platforms).

With fullscreen it's a bit tricky, but at least, there can be done in theory (tricky, because the user can use some OS dependent hot key to toggle fullscreen mode, without Xemu menu interaction to do so).

At the other hand, OSD key debugger is a checked item. In branch next. Currently at least you should always check out next first, as master is kinda old, and it's possible that next already has features not in master yet.

[BacchusFLT]

Well if so, I suggest a "user defined" that would be selected as soon as the user changes the size.

And you have convinced me to surrender the obsoleted mater, or I have possible convinced you to merge the stable functions from other branches into the master. :-)

[lgblgblgb]

The problem, that it's hard to tell what caused resize. Since VIC-IV emulation itself needs to "crop" areas like PAL/NTSC differences, but also user need to resize, both boils down that the window size will change, and from point of view of windowing events are about the same. Thus, by implementing what you suggest would cause to have the anomaly very often that it will jump for "user defined" even if the user hasn't done anything like that.

Well, for branches, I really don't want to merge "features" only, it's very much work, sometimes more work than doing the actual emulation, since a given feature needs to be rewritten in the scope of the "acceptor" branch. Surely, merge a full branch is another story, but often it's not possibility, since master needs to be stable as name suggests, so I would not merge something which is material of active development. But that's true that master is very old now, and in fact it's already planned since a while to call a given state of next as the new master and then continue evolving next as it should be. In fact, there is even an kept-open pull request for that: #222

But things like merge together the VIC enhancements with other Xemu developments are much more complicated topic, but that's already happening as well in the "not so public" merger branch (which in some form will be merged back to next at some pont which then as master after some another of unknown time). Information: #29

But, back to the original topic of the issue :) Hopefully you don't mind that I marked this issue as "cosmetic" since frankly, it does not change things if it works, just kind of "cosmetic" if something needs to be checked item to look "more nice" :) In an ideal world this is also important, but looking the status of the project in general, I must define a kind of "priority list", and surely some emulation misbehaviour (or lack of emulation of something) seems to be more serious issue.

[lgblgblgb]

Closing this now, too specific (hehe, and old ...). #383 has been opened instead. OSD key debugger checkmark should work for now, btw.