Skip to content
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

Window size and dock positioning is 1 pixel off #288

Closed
Stephan-P opened this issue Oct 16, 2018 · 24 comments
Closed

Window size and dock positioning is 1 pixel off #288

Stephan-P opened this issue Oct 16, 2018 · 24 comments

Comments

@Stephan-P
Copy link
Contributor

What's wrong, and with what software version?

Operating System: Windows 10
CEmu version: CEmu v1.1.1 (git: 11df959)
Describe your issue:
Window size and dock positioning is 1 pixel off at each new start

What are the steps to reproduce this issue?

  1. Arrange your CEmu a TI 84 emulator, with only screen and keypad (80% size or 75% size)
  2. Save calculator state and close the app
    3.Restart the app an notice the keypad dock is 1 pixel off position and hence the window is 1 pixel wider showing white lines left of the keypad and richt of the screen

Any logs, error output, screenshot, other comments...?

See attached screen captures
snipaste_2018-10-16_07-29-27
snipaste_2018-10-16_07-29-56

@adriweb
Copy link
Member

adriweb commented Oct 20, 2018

It's hard to fix and it may simply be a bug in Qt. AFAIK, we don't really have an ETA for a fix, sorry...

BTW:

11:24:41 <@jacobly> also, that's way more than one pixel
11:24:48 <@MateoC> I know what causes it
11:24:54 <@MateoC> If that helps
11:25:14 <@MateoC> It's the dumb dock central divider 
11:26:09 <@MateoC> It should never be shown if edit mode is disabled, but for some reason it is

@mateoconlechuga
Copy link
Member

I believe this has been fixed in the latest development build. (tested on windows 10). Let us know if you have any other issues.

@Stephan-P
Copy link
Contributor Author

This issue is still in Jacobly's latest build
image

@adriweb adriweb reopened this Nov 28, 2018
@mateoconlechuga
Copy link
Member

I have no idea how to reproduce this because it doesn't happen for me.

@mateoconlechuga mateoconlechuga modified the milestones: Any version, v1.2 Nov 28, 2018
@runer112
Copy link
Member

I can't reproduce this, either (v1.2dev, git: e4545c9):

cemu64_2018-11-28_10-30-03

@mateoconlechuga
Copy link
Member

Perhaps an outdated config is messing things up. Try using Extras > Reset CEmu, and then starting from scratch.

@Stephan-P
Copy link
Contributor Author

Okay, I've wiped CEmu from my system, that is: away with C:\Program Files\CEmu as well as C:\Users\username\AppData\Local\cemu-dev.

I've once again created a folder C:\Program Files\CEmu and copied therein CEmu.exe plus a bootable.cemu.

Upon first start, the bootable rom is loaded and I'm presented with the LCD screen with the settings dock alongside of it.
When I adjust the scale to 70% and use the menu "Calculator - Save State", I receive an error message "Saving failed. Check access rights on Installation folder". Apparently, CEmu wants to write something in C:\Program Files\CEmu, which is blocked by Windows.
After I manipulate the access rights for this folder, Save State indeed writes a file cemu-image.ce in C:\Program Files\CEmu. Under Windows regime, this can not be done by a regular user. Only Administrator users have access to this folder level.

Moving on, I enable GUI-adjust mode in order to get away with all docks except the keypad.
I arrange screen and keypad and adjust the window size so that I'm only left with a nice and proper TI-84 emulator. Just to be sure, I use Save State again, to save this configuration. Does it really save the docks configuration?

Investigating further, I find that at some point in time C:\Users\username\AppData\Local\cemu-dev has been created and filled with cemu_config.ini and cemu_rom.rom. The .ini file has a more recent time stamp, so it appears it's being updated. Checking its contents, I notice the Screen scale is indeed 70%.

I also notice that two different styles of local paths are used.

  • savedImagePath=C:/Users/Stephan Paternotte/AppData/Local/CEmu/cemu_image.ce
  • savedDebugPath=C:/Users/Stephan Paternotte/AppData/Local/CEmu/cemu_debug.ini
  • romImage=../../Users/Stephan Paternotte/AppData/Local/CEmu/cemu_rom.rom
  • current_directory=C:/Users/Stephan Paternotte
  • rom_path=C:/Users/spaternotte/AppData/Local/cemu-dev/CEmu/cemu_rom.rom

Windows uses two different styles of usernames, in my case "spaternotte" is the low-level name, with it's higher level visible name "Stephan Paternotte". I don't know if this is an issue, but the two different ways of path addressing could become one at some point in time.

CEmu all setup the way I want it, I shut it down and restart it again.
O dear, I do not get my ready prepared emulator setup. Instead I'm welcomed with a brand new unconfigured CEmu. I can do all my settings once again. I've been here before. What was that cure again?

Let's try again, but now using "portable configuration".
cemu_config.ini is now saved into C:\Program Files\CEmu.
Again, this really not done for regular Windows users who do not have write access to anything in C:\Program Files.
Yes, now the emulator starts in (almost) the configuration I saved.
Conclusion: regular configuration is NOT picked up from C:\users\username\appdata. Portable configuration IS picked up, but regular users do not have write access to that folder. Catch 22.

But, after all this the 2-pixel positioning offset remains:
image

What is so special with my system, that I'm the only one who is experiencing this? ;-)
Or is it that the bootable-rom.cemu, my bootable-rom.cemu, contains this fluke?
What's in a .cemu?

@runer112
Copy link
Member

Silly question, but can you just drag the right edge of the window and make it smaller, thus eliminating the white space?

@Stephan-P
Copy link
Contributor Author

Yes, something IS in the .cemu.
I setup my TI-84 emulator as I like it and then exported a bootable rom.

I then wiped the config.ini and .ce file from c:\program files\cemu, as well as did I wipe c:\Users\username\Appdata\cemu-dev.

I then started cemu again and Lo and Behold, Cemu started with the proper ROM and the window settings I prefer: LCD screen + keypad only. No initial welcome, no settings window.
The keypad windows DOES have its 2 pixel offset again, I'm sorry to tell.
Just to be complete: C:\Program Files\Cemu now contains a file cemu-image.ce. No config.ini.
C:\users\username\local\cemu-dev\ has been created again, including config.ini and cemu_rom.rom.
Closing CEmu and restarting it again gives me the same setup, including 2pix offset.

Another thing, was it not the plan to suppress or at least minimize the Windows Console during CEmu startup?

@runer112
Copy link
Member

Also, does this problem occur at other scale factors? I'd be interested to see if it goes away at a larger scale like 80% (or normal 100%), or if it gets worse at a smaller scale like 60%.

@Stephan-P
Copy link
Contributor Author

Silly question, but can you just drag the right edge of the window and make it smaller, thus eliminating the white space?

Yes, I can take the window side and reduce its width so that the 2pix offset is gone.
After closing CEmu and restarting it the 2pix offset for the keypad is back again.

@adriweb
Copy link
Member

adriweb commented Nov 28, 2018

I then started cemu again and Lo and Behold, Cemu started with the proper ROM and the window settings I prefer: LCD screen + keypad only. No initial welcome, no settings window.

Correctly handling multiple configs, including portable ones, is hard ; these kinds of issues might never be fully solved :P

Another thing, was it not the plan to suppress or at least minimize the Windows Console during CEmu startup?

That's actually a setting (for Windows builds) if I remember correctly - what if you toggle it, is it gone or still there on the next restart?

@runer112
Copy link
Member

Whoops, I just skimmed the issue originally and didn't pick up on the fact that the positioning gets messed up only after a restart. Yeah, I can totally reproduce that. CEmu definitely has some issue that pushes docks around a tiny bit (usually making them slightly bigger) on startup.

@Stephan-P
Copy link
Contributor Author

Also, does this problem occur at other scale factors? I'd be interested to see if it goes away at a larger scale like 80% (or normal 100%), or if it gets worse at a smaller scale like 60%.

Unfortunately, I cannot try this with a higher screen scale.
When I set the screen scale to 80% and adjust the height of the window, I can only extend to a certain point, not far enough so that the keypad width corresponds with the LCD-width.
My work notebook is only 1366x768 and only at 70% will LCD and keypad fit the screen height.
Can it be that the max height of the CEmu window is limited to the screen height?

At a smaller scale (60%) the keypad also receives its 1-2 pixel offset.

@Stephan-P
Copy link
Contributor Author

Stephan-P commented Nov 28, 2018

That's actually a setting (for Windows builds) if I remember correctly - what if you toggle it, is it gone or still there on the next restart?

I enabled the Windows console, reduced it to a really small size AND positioned it underneath the CEmu window. Then I disabled it again. Upon the next start, the Windows console window opened in full size again, not under the CEmu window.

@adriweb
Copy link
Member

adriweb commented Nov 28, 2018

That's actually a setting (for Windows builds) if I remember correctly - what if you toggle it, is it gone or still there on the next restart?

I enabled the Windows console, reduced to a really small size AND positioned it underneath the CEmu window. Then I disabled it again. Upon the next start, the Windows console window opened in full size again, not under the CEmu window.

Alright, that might be a bug for @alberthdev then. That said, I'm wondering if it's build-specific too (maybe not there for release versions?)

@Stephan-P
Copy link
Contributor Author

Whoops, I just skimmed the issue originally ...

When I write a substantial story, it's usually worth reading all of it ;-)
Sorry

@runer112
Copy link
Member

Through some discussion on IRC, we're pretty sure we pinpointed the cause of the issue. It's a result of part of UI edit mode sneaking its way into the layout on startup even if you have UI edit mode disabled.

We're not sure how to fix it (yet).

@adriweb
Copy link
Member

adriweb commented Nov 28, 2018

... and apparently something related to the central widget spacer. It looks indeed like a pain to fix considering what we've tried already.

@Stephan-P
Copy link
Contributor Author

Yeah, it does look like the LCD screen is positioned left aligned, wheras the Keypad is positioned at the center. Mix in some clever maths and rounding and the necessary window width needs some upward adjustment and the gap is created.

@mateoconlechuga
Copy link
Member

I deleted the line that fixed it. Can someone add it back in:

155f1eb#diff-ef62af2c016b9e0bc79e7a0a752151e8L71

@adriweb
Copy link
Member

adriweb commented Nov 28, 2018

Well, my commit closed the issue but I guess you can wait for a few minutes and try jacobly's build again.

@runer112
Copy link
Member

Yup, looks like that fixed it to me.

@Stephan-P
Copy link
Contributor Author

Dito. It looks like this morning's download of Jacobly's build does away with the pixel offset.
Keypad is properly aligned with LCD now. I'm very happy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants