Sublime Forum

3.2: Linux save_on_focus_lost setting still partially broken

#1

@wbond

I first reported this bug in the post: Build 3183 ‘save_on_focus_lost’ and ‘About’ problems.

The save_on_focus_lost setting is still partially broken in build 3200, at least on Linux. [Linux Mint 17 Qiana, Cinnamon 64-bit 2.2.16, based on Ubuntu 14.04.5 LTS, Trusty Tahr.]

When ST is started and usually for one to three hours the save_on_focus_lost setting works as expected.

Subsequently it stops working when focus is lost to another window. It works when the buffer/view loses focus within the same window; e.g. switching buffers or group, opening the console or the Command Palette, Show Files, Goto, or any other overlay. But when the focus is lost to another ST window, or to any other application, the desktop, system menu, etc., then saving does not automatically take place.

In a (failed) attempt to fix this bug I wrote the following plugin:

import sublime
import sublime_plugin

class BugFixSaveOnFocusLost(sublime_plugin.EventListener):
    def on_deactivated(self, view):
        if view.is_valid() and view.file_name() is not None and view.is_dirty():
            view.run_command("save")

Some additional print logging statements established that the plugin works as expected.

HOWEVER at (presumably) the same time that the save_on_focus_lost setting stops working properly my plugin also stops working. I think this shows that there is a problem with the on_deactivated() method of the event listening system.

Could this problem be due to the Linux move to GTK3?

Although it is of very little consequence the About bug which I also reported here is still present in build 3200. It is of little importance and I mention it again only because it might be related to the save_on_focus_lost setting problem and might help in diagnosis.

I now simply restart ST when the save_on_focus_lost setting problem reappears which acts as a 1-3 hour fix, but it would be nice if the problem were to be resolved.

P.S. Might this be related? Active window not being updated on view selection. Build 3200 Linux

0 Likes

Active window not being updated on view selection. Build 3200 Linux
Active window not being updated on view selection. Build 3200 Linux
Active window not being updated on view selection. Build 3200 Linux
#2

Probable diagnosis in this post.

0 Likes

#3

This would be great to post at https://github.com/SublimeTextIssues/Core/issues so it isn’t lost in the forum activity.

2 Likes

#4

I have the same problem on 32-bit Fedora 20, Cinnamon 2.6.7. Yes, I know, upgrading the OS would be great, but it’s out of my control

I have only noticed the problem since build 3200; it wasn’t present in build 3176. I similarly observe that the problem starts after a few hours, and is fixed by restarting ST

1 Like

#5

Fedora 20 is even older than Ubuntu 14.04.

I’m almost certain that the problem started in dev build 3181 when ST moved to GTK3.

It’s definitely not present in 3176 which was the last stable release before the current (3200) one.

I’ve reverted to 3176 until I can spare the time to do a full system upgrade.

0 Likes

#6

I’ll write it up sometime in the next few days.

0 Likes

#7

We switched from GTK2 to GTK3 with version 3.2. That would be my hunch, especially since you are on a really old version of GTK3/Gnome.

0 Likes

#8

@wbond @hey_blinken @Phidica

Re: Dev Build 3205 - Change Log: Fixed compatibility with old Linux distributions

Just to let you know that Dev Build 3205 has NOT fixed the save_on_focus_lost, and the related window ID, problems. At least not on Linux Mint 17, Cinnamon 64-bit 2.2.16, based on Ubuntu 14.04.5.

It seems reasonable to assume that is was intended to do so given the change log item (quoted above) and recent discussion here.

The save_on_focus_lost setting ceases to work and window IDs are incorrectly reported a few hours (1 to 3 ish) after ST is started.

Hope this helps.

0 Likes

#9

No, the fix was for glibc version compatibility.

1 Like

#10

Okay, thanks.

0 Likes