macOS: Fix double-click the title bar to maximize the window does not occupy the full screen and others

[page-down]

• Fix resize_in_steps being applied when double-clicking on the title bar to maximize the window.
• Add comments to explain how to get the services related methods to be called and restore IME pre-edit text after inserting text from the service.

I've found one more annoying issue.

Using launch --dont-take-focus (--keep-focus) to create a new window, the on_focus callback will still be called. And there are four of these, the current window's as well as the new window, in and out.

And the side effect is not only this, it also causes IME composition to be cancelled.

I think any operation that creates, removes, changes the active window of an inactive tab, etc. should not trigger on_focus_changed as long as it does not actually change the current focus.

If you don't have time to debug this, where do you think is the best place to fix it?

I found that the KITTY_VCS_REV exists and is empty in the recent debug_config repots, which leads to kitty 0.27.1 () ... a parenthesis with no content.
The related code has not been changed recently and the issue does not exist in the official release 0.26.5, is there a change in the build environment?

[kovidgoyal]

On Fri, Feb 24, 2023 at 03:53:00AM -0800, page-down wrote: - Fix resize_in_steps being applied when double-clicking on the title bar to maximize the window. - Add comments to explain how to get the services related methods to be called and restore IME pre-edit text after inserting text from the service. I've found one more annoying issue. Using `launch --dont-take-focus` (`--keep-focus`) to create a new window, the `on_focus` callback will still be called. And there are four of these, the current window's as well as the new window, in and out. And the side effect is not only this, it also causes IME composition to be cancelled. I think any operation that creates, removes, changes the active window of an inactive tab, etc. should not trigger `on_focus_changed` as long as it does not actually change the current focus. If you don't have time to debug this, where do you think is the best place to fix it?

I think you would basically need to add another parameter to the window creation functions so that the newly created window is not given focus rather than the current implementation which switches focus back. So essentially tab.new_window() and whatever else it calls down the call chain.

I found that the KITTY_VCS_REV exists and is empty in the recent debug_config repots, which leads to `kitty 0.27.1 () ... ` a parenthesis with no content. The related code has not been changed recently and the issue does not exist in the official release 0.26.5, is there a change in the build environment?

Not that I know of, but I'll take a look at that.

[kovidgoyal]

the VCS rev is showing up in the debug window for me.

[page-down]

the VCS rev is showing up ... for me.

I downloaded the nightly release built from c5149de, ran debug_config and saw kitty 0.27.0 () created by ... .
The version number should be 0.27.1 (better yet, the unreleased 0.28.0, but I don't care) and the VCS REV should not be empty (or without empty parentheses).
And some of the recent bug reports have had this problem.

This can be fixed by a simple check, hasattr(fast_data_types, 'KITTY_VCS_REV') is not enough, but I wanted to let you know first if some inspection is needed in the build environment.

Oh, I saw that macOS nightly is already 3 weeks old, and did not upload the latest nightly version (or build failed), no wonder it is 0.27.0.
I tried the latest linux nightly again, still no VCS Rev.

[kovidgoyal]

On Fri, Feb 24, 2023 at 05:32:59AM -0800, page-down wrote: > the VCS rev is showing up ... for me. I downloaded the nightly release built from `c5149de`, ran debug_config and saw `kitty 0.27.0 () created by ... `. The version number should be 0.27.1 (better yet, the unreleased 0.28.0, but I don't care) and the VCS REV should not be empty (or without empty parentheses). And some of the recent bug reports have had this problem.

Ah, you mean for releases. Yes, for those VCS rev is not set as they are releases with version numbers. Sadly this is also the case for nightly builds, because they are also technically "releases". I would need to add some plumbing to change that, which is rather a lot of effort so I havent bothered yet.

This can be fixed by a simple check, `hasattr(fast_data_types, 'KITTY_VCS_REV')` is not enough, but I wanted to let you know first if some inspection is needed in the build environment.

Done.

Oh, I saw that macOS nightly is already 3 weeks old, and did not upload the latest nightly version (or build failed), no wonder it is 0.27.0. I tried the latest linux nightly again, still no VCS Rev.

Weird, I will need to inspect the logs to see why macOS is not being updated.

[page-down]

I tried the latest linux nightly ...

It turns out that the latest linux amd64 nightly is a week old, which is inconsistent with the others.

... which is rather a lot of effort ...

Yes, while nightly with VCS rev would be useful for identifying problems, I have seen very few reports on nightly versions so far.

... need to add another parameter to the window creation functions ...

I think I found the root cause.
In the previous discussion of kitty @ ls, we already discussed the definition of active and focus.
There is only one kitty window with keyboard focus, i.e. the tab it belongs to is the active tab and the OS window it is in is the currently focused window.
The on_focus event should only be fired on the correct window if this condition changes.

However, currently focus_changed is called in notify_on_active_window_change. This causes an active window change in an inactive tab or OS window to also raise the on_focus event.
I don't think we should mix terms here. If the window active changes it should be the on_active event.

It's not a serious problem, it's just that this big state machine is hard to manage, I just want kitty to not go into the wrong state and trigger unwanted events.
Have revised more than 20 places still not satisfied, please let me know if there is anything else to consider.

[kovidgoyal]

On Fri, Feb 24, 2023 at 03:01:07PM +0000, page-down wrote: > I tried the latest linux nightly ... It turns out that the latest linux amd64 nightly is a week old, which is inconsistent with the others.

Yes, I know I have manually deleted those two from the release. GitHub's intake servers are extremely flakey, those two have each failed with SSL protocol errors with 8 retries. There was a bug in the upload script where the script ignored such errors if all retries failed, now fixed. But if GitHub's upload process remains this flakey I might just have to abandon the nightly releases. It's a real shame github doesnt have an API where you can upload a tarball with all assests for a release in one go.

> ... which is rather a lot of effort ... Yes, while nightly with VCS rev would be useful for identifying problems, I have seen very few reports on nightly versions so far.

Yes, something to revisit someday when I have more time :)

> ... need to add another parameter to the window creation functions ... I think I found the root cause. In the previous discussion of `kitty @ ls`, we already discussed the definition of `active` and `focus`. There is only one kitty window with keyboard focus, i.e. the tab it belongs to is the active tab and the OS window it is in is the currently focused window. The `on_focus` event should only be fired on the correct window if this condition changes. However, currently `focus_changed` is called in `notify_on_active_window_change`. This causes an active window change in an inactive tab or OS window to also raise the `on_focus` event. I don't think we should mix terms here. If the window active changes it should be the `on_active` event.

I agree, it makes sense to bifurcate that event into two events to match the rest of the codebase and usage.

It's not a serious problem, it's just that this big state machine is hard to manage, I just want kitty to not go into the wrong state and trigger unwanted events. Have revised more than 20 places still not satisfied, please let me know if there is anything else to consider.

I will review your PR