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

Conemu does not "snap" properly #284

Closed
musm opened this issue Aug 20, 2015 · 22 comments
Closed

Conemu does not "snap" properly #284

musm opened this issue Aug 20, 2015 · 22 comments

Comments

@musm
Copy link

@musm musm commented Aug 20, 2015

I'm using windows 10. Open up conemu hold down windows button and then hit left or right. You will see that ConEmu does not fully snap the the edges and that there is a small gap between the sides of the screen.

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Aug 20, 2015

Microsoft bugs must be fixed by Microsoft, don't they? But the bug was ignored for months...

http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_desktop/desktop-coordinate-system-is-broken/9e6fd9ab-6d27-45e0-bb55-4c868cd6ac45

@musm musm closed this Aug 20, 2015
@musm
Copy link
Author

@musm musm commented Aug 25, 2015

I'm going to reopen this until MSFT fixes it or something. It's interesting that if you drag the conemu bar and snap it via the mouse it will actually snap properly but no via WIN+ left or right

@musm musm reopened this Aug 25, 2015
@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Aug 25, 2015

When you drag the window - Windows do calculations internally.
When app call Move(0,0) - Windows put it in wrong position.

@musm
Copy link
Author

@musm musm commented Mar 9, 2016

Is there any fix yet from MS or workaround yet. I love conemu but this bug really bugs me :)

@kuttor
Copy link

@kuttor kuttor commented Apr 3, 2016

Yes, I have this same issue -- very annoying. Basically when snapping the window using Windows 10 hotkeys, it leave gap around the left or right side, depending on snap, and the bottom.

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Apr 3, 2016

The Windows bug is known and reported. But all you, folks, coming back here again and again, instead of forcing MS to fix it? Does this make sense?

@kuttor
Copy link

@kuttor kuttor commented Apr 3, 2016

Apologies. Microsoft or not, it seems strange that it's isolated to Conemu.

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Apr 3, 2016

@mbikovitsky
Copy link

@mbikovitsky mbikovitsky commented Oct 15, 2016

@Maximus5, I'm not familiar with the codebase, but why not let Windows handle the snapping instead of doing it manually? Seems to me this is one of those things Microsoft does not want developers doing programmatically.

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Oct 15, 2016

  1. Windows does not snap windows without caption.
  2. Quake mode.
  3. Windows snapping is not available for "calling". GuiMacro would not work.
  4. What about restoring window position and state on starting new instance?
  5. And some more things.
@mbikovitsky
Copy link

@mbikovitsky mbikovitsky commented Oct 15, 2016

Assuming the inability to programmatically invoke snapping is by design (I'm not a Microsoft employee, so I don't know for certain that this is the case), wouldn't it be best to let Windows handle it and document that you can't do it manually?

Restoring position, however, might still work. For instance, on my system the top-left corner of the screen is at (-7, 0), and when setting this position from the Settings screen the window moves correctly. Still, this isn't "true" snapping.

Also, when I disable the title bar, snapping still works when using the mouse to do it.

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Oct 15, 2016

If you restore such snapped window, it would not be snapped.
Application can't determine if it's snapped.
Titlebarless windows doesn't snap. By keyboard. Also, don't forget there are other versions of Windows, the 10 is not the one.
Fullscreen windows.
I can remember much more problems...

@mbikovitsky
Copy link

@mbikovitsky mbikovitsky commented Oct 15, 2016

These are all valid points, but what I'm saying is that perhaps the solution is to make snapping work correctly where Windows allows it, and document that it is unsupported for the rest of the cases. Better to have a feature that works in some well-defined cases, than a feature that half-works in all cases.

@Maximus5
Copy link
Owner

@Maximus5 Maximus5 commented Oct 16, 2016

At last. User may specify in ConEmu setting 100% width and limited height in cells (and vice versa). And what they will have? Gaps!

@musm
Copy link
Author

@musm musm commented Oct 16, 2016

Considering the pros and cons: I tend to agree with @mbikovitsky points here.

@miniksa
Copy link

@miniksa miniksa commented Oct 31, 2016

Hey @Maximus5,

@bitcrazed, our PM, found this SetWindowPos issue being discussed on Twitter the other day and filed it as a bug in my system. I followed up with the team responsible for rendering window placement and got the following answers to some of your questions:

  • Is it a confirmed bug? Is it a feature?
    It's somewhat in the middle. I asked the team responsible for the window framing and they said they consider the invisible frame to be By Design. I personally believe by some technicality, the frame still exists but is just invisible for theming/styling reasons, so they don't consider it a bug exactly.
  • Is there any workaround to put the window at the edge of the monitor working area?
    This is where I got you an answer. :) The team says that you can use the DwmGetWindowAttribute function (https://msdn.microsoft.com/en-us/library/windows/desktop/aa969515(v=vs.85).aspx) with the parameter DWMWA_EXTENDED_FRAME_BOUNDS to find the "visual rect" of the window as known to the window manager. A little calculation between that RECT and the one you already have for your window will let you know how many invisible pixels there are outside your bounds and let you compensate accordingly for the invisible border.

I hope that helps you out!
--Michael

Maximus5 added a commit that referenced this issue Feb 27, 2017
…dow size changing on show/hide the frame.
@musm
Copy link
Author

@musm musm commented May 12, 2017

I think this has been fixed?

@Maximus5 Maximus5 closed this May 12, 2017
@RReverser
Copy link

@RReverser RReverser commented Feb 3, 2019

@Maximus5 I thought I was still running into this issue on Quake mode (and I've been using ConEmu for years now), but, on a fresh setup, decided to give it another go, and only after finally reading through various discussions almost accidentally found out that it goes away if I:

  1. Set window width to 100% (this is understandable part).
  2. Set Quake Style -> Frame width from -1 to 0 - this is also sort of understandable, but maybe worth specifically highlighting in docs?
  3. After that you need to slightly drag the quake ConEmu window after which frame does disappear. This part was quite surprising to find out, and this is where I was usually giving up thinking that the option didn't have any effect. Is this a bug / do you need a repro screencast?
@mystrdat
Copy link

@mystrdat mystrdat commented Aug 22, 2019

I'm trying the 190714 version through Cmder and it seems the bug isn't fixed. The window sizes are not saved properly, or perhaps they're not re-applied properly. If I save the window size as 100% height, it resets to 98% height on next start and is padded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.