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

enhancement: Snap window to actual dimensions of the 3270 dimensions after font resize #59

Open
swhobbit opened this issue Dec 4, 2022 · 2 comments

Comments

@swhobbit
Copy link

swhobbit commented Dec 4, 2022

After dragging the window to a new size to change the font, it's impossible to get the size exactly right. Thus Snap Window Size should be executed automatically.

Note:: Manual use of Snap Window Size requires opening a menu, finding the action, clicking, and moving the mouse out of the way; this is when the mouse is usually no where near the top of the window when resizing (for example, on MacOS, the mouse has be in the lower right corner of the window to resize it). Thus Snap Window Size is a expensive action.

Note: I don't see where the behavior (or even ability) to drag the window bigger is defined in the documentation. Thus the ol (undefined broken) behavior should be safe to change. The page https://x3270.miraheze.org/wiki/X3270/Main_window is simply labeled as under construction. The old manual page only describes dragging the mouse to select text, not to resize the window.

If the font size cannot be changed, the original window should restored. Such a failure may be optionally reported with a pop-up reporting why it didn't change. (I would strongly prefer there is no pop-up; this behavior should be deferred to the documentation. Repeated pop-ups only stress the user.)

If the old (screen wasting broken) behavior is desired, a boolean option/resource should be provided: Recommended default is the new behavior.

(I am dismayed that this behavior has to be listed as enhancement rather than a bug. Any resizing of the x3270 window that leaves blank chrome around the terminal window text is useless behavior that blocks valuable screen real estate.)

@swhobbit
Copy link
Author

DL;DR: Do Issue 60 first.

NOTE: While I consider this and Issue 60 (to step font by Cntrl+/-) compliemntary, I think that one may considered less of a duplicate and more useful since it allows an incremental font step (the most likely desired operation) without using the mouse.

@pmattes
Copy link
Owner

pmattes commented Dec 31, 2022

This is largely a matter of taste rather than an obvious misbehavior. The current policy (well-documented or not) of adapting to the resize while leaving the window with exactly the dimensions requested is entirely reasonable and not at all uncommon in other apps.

I agree that Issue 60 is a much better alternative, since the intent and desired result are obvious, rather than having the resize logic guess that you really didn't want the window that size.

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

No branches or pull requests

2 participants