Distraction free plugin does not work on OSX

[Enrico68]

I have just installed Zim 0.74.3 using homebrew on OSX 10.15. I have tried to use the distraction free plugin with no success. When I press F11 I have no effect. Even from the menu-bar -->Fullscreen.

[dehesselle]

While I don't use it personally, there's definitely a difference in fullscreen when I enable that plugin. Can you test our app https://zim-wiki.org/downloads.html ?

[Enrico68]

Just tried but still cannot get this option working. It behaves in the same way as the brew version with eventually more problems (not recognizing R, Gnuplot, LaTex for equations, DiTaa, seqdiag). I will remain with brew version using Emacs with zim-mode (perfect integration).

[introt]

Could you post a screen recording and debug logs?

[Enrico68]

Here you get the debug logs and here the screen.
P.S. the F-11 key on OSX (like the other functions keys) are not available.

[introt]

Thank you! The plugin seems to lack any and all logging, but your log also shows a concerning lack of DEBUG: Action: toggle_fullscreen(True) (which should show up whether you toggle via the function key or the menu item, regardless of the plugin).

The window seems to be maximized in your recording. Could you try resizing the window to be tiny and then triggering the menu item?

[Enrico68]

The window seems to be maximized in your recording. Could you try resizing the window to be tiny and then triggering the menu item?

Minimizing and maximizing the window is working correctly using the window frame button. But the menu item is not responding.

[introt]

Seems there is a larger (not limited to the plugin) issue here. Are you using some window management related software? The menu item is really basic, so there might perhaps be an upstream issue. I can only extrapolate so much, as I don't have a Mac to test with :/

[Enrico68]

could be interesting but with the Zim Markdown version is working. Here is the debug

[introt]

Doesn't look like toggle_fullscreen is present there either. I'm not familiar with the fork's code base, but hope it offers clues for the devs with OS X.

[dehesselle]

This is a comparison of "normal mode" and "distraction free mode":

(Don't pay attention to some artifacts, especially around window borders, that's the GIF compression.)

Is this not what it's supposed to do?

[introt]

I was under the impression that the menu item didn't make the window go full screen at all - thus the inquiry upon the usage of window management software. Might have something to do with the window decorations -- didn't 0.74 introduce client side decorations? @dehesselle has them disabled, you might want to try that @Enrico68

[Enrico68]

@introt window decoration ? I am not aware that is possible under OSX. @dehesselle under which version of OSX are you testing ?

[dehesselle]

The GIF was recorded on High Sierra since that was the easiest thing for me to do (=my test system). I've also tested on Monterey.
Decorations can be disabled by enabling the toolbar plugin and unchecking the first item there ("show elements in title bar" or something, I don't have the English version in front of me right now). If people miss out on this option, I can add a note to the readme (I already have instructions on how to enable plugins with external dependencies).

[Enrico68]

I cannot see any toolbar plugin. Are you referringto the Tray Icon?

[dehesselle]

If you don't have that, you can't possibly be on 0.74.3, it's part of Zim.

For the sake of testing, please use our app (Homebrew is unsupported at this time). I'm not convinced yet that there is even an issue with distraction free editing.

[Enrico68]

Thanks @dehesselle it is working. I have installed the HEAD version and everything is in Ordnung

[introt]

Glad that the issue got resolved 👍

@dehesselle would you mind checking if toggling fullscreen works with the decorations enabled? If not, that's a separate issue not related to the plugin and needs its own ticket.

[dehesselle]

Fullscreen in general does not work with CSD enabled, regardless of distraction free mode. Clicking the menu item simply doesn't do anything. I wasn't aware of that.

@introt I'll create an issue and link it here later.
Also, please don't assign issues to me. I prefer to do that once I'm really working on something, not before.

[introt]

@dehesselle Roger that! (sorry!)

@jaap-karssenberg Could we get operating system labels for platform-dependant issues?

[jaap-karssenberg]

Please use a prefix like "[OS X]" for the subject for platform specific issues. I try to use the labels for status tracking and I think this is relevant info to see in the subject line when scanning new issues / emails about issues.

…

On Wed, Jan 19, 2022 at 4:35 PM introt ***@***.***> wrote: @dehesselle <https://github.com/dehesselle> Roger that! @jaap-karssenberg <https://github.com/jaap-karssenberg> Could we get operating system labels for platform-dependant issues? — Reply to this email directly, view it on GitHub <#1864 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQYHWE7NR6DSVFR5TXPIDUW3K5TANCNFSM5L72DVWA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[introt]

Roger. Triagers can't edit titles, so some cooperation is required -- unless you want to complicate things by introducing GitHub Teams to assign issues to (and then have the team member assign themselves when taking it up). Not sure whether that's worth the hassle given our active contributor count, but it could help new devs find stuff to work on (eg. issues assigned to GTK/UI team vs. packaging vs. OS integration etc) or non-devs find issues which need investigating (reproducibility & writing clear(er) steps).

[jaap-karssenberg]

Ah, I wasn't aware of that limitation in triage. In that case it indeed makes sense to add tags for OSX and Windows specific issues.

…

-- Jaap

On Wed, Jan 19, 2022 at 5:30 PM introt ***@***.***> wrote: Roger. Triagers can't edit titles, so some cooperation is required -- unless you want to complicate things by introducing GitHub Teams to assign issues to (and then have the team member assign themselves when taking it up). Not sure whether that's worth the hassle given our active contributor count, but it could help new devs find stuff to work on (eg. issues assigned to GTK/UI team vs. packaging vs. OS integration etc) or non-devs find issues which need investigating (reproducibility & writing clear(er) steps). — Reply to this email directly, view it on GitHub <#1864 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQYHUKBWJDWC434KNOFSLUW3RKXANCNFSM5L72DVWA> . You are receiving this because you were mentioned.Message ID: ***@***.***>