Impossible to read texts with "breaks are fullscreen" on Elementary OS 4.1 (Loki)

[kuramaluka]

Hello,

I'm sorry if my bug is poor of details. I've just installed stretchly 0.14 in Elementary os 0.4.1, 64 bit.

As you can see opening the attached image, messages and images of the app are almost impossible to read. It seems that the image is unaligned ... with the window itself.

In settings "breaks are fullscreen" is checked (everything works well if it's unchecked).

Does it depends on my system or is it really a bug?

[hovancik]

Hi,
it looks like bug. I have just tried on debian and have the same problem with fullscreen. Thanks for reporting.

[hovancik]

So this is electron's bug. Reported it here: electron/electron#11632

[kuramaluka]

Thanks for your super fast reply :) Let's see if someone can help with the electron's bug! :)

[dbankmann]

This bug began to annoy me, so I wrote up a small workaround, that creates screen-sized windows. Works for me on i3wm. Not tested on multiple screens, though.

[jgisde]

This bug began to annoy me, so I wrote up a small workaround, that creates screen-sized windows. Works for me on i3wm. Not tested on multiple screens, though.

Thanks a lot for the workaround! This Electron-bug is annoying me for a long time.
I would like to test it on Manjaro as well. Any way to get anytime soon an update on the linux/pacman installers? Or should I just try to compile it myself for the time being?

[hovancik]

This is somewhat related to #454 (didn't work for me). I haven't tried the code from @dbankmann as I am busy with working on new UI/UX.

There is also: https://www.electronjs.org/docs/api/browser-window#winmaximize which should maximize window

I wanna do bigger refactoring of windows with UI/UX work I am doing. There are so many hacks I used and I would like to check which of them are still needed...

Ideally, someone fix this in electron ;/

[jgisde]

Well, I tried the code from @dbankmann simple way through 'npm start' and it works almost perfect. It stretches the background while keeping the text centered, but It just fails to bring it completely to the bottom.

I really don't know why, but since the letters are properly placed in relation to my screen, I guess it has to do with the background code (?). Or is it again a Electron bug?

[dbankmann]

Ideally, someone fix this in electron ;/

Sure, but it's been open for over 2 years now. Cannot wait any longer.

How do you debug the application @hovancik ? In particular the electron.screen.getAllDisplays() object?

I tried it on a different setup with multiple monitors of different sizes and apparently only, the smaller ones worked.

@jgisde: Indeed, that is what's happening on Xfce for me, too :/ What DE do you use?

[jgisde]

@jgisde: Indeed, that is what's happening on Xfce for me, too :/ What DE do you use?

1/ @dbankmann: Gnome. I have no bottom taskbar, so that cannot be in my case. Does it make a difference in Xfce with autohide on/off for the taskbar?

Edit: I've just increased to 40px the bottom distance from the '#pospone' css line. Now at least it looks neat, almost as it's not some annoying bug :)

2/ @dbankmann: What did you use to recompile/repack/install your workaround?

Ideally, someone fix this in electron ;/

3/ @hovancik: Since this beautiful app fully depends on Electron, and they aren't most likely gonna fix this in the near future... Would there be any chance in future releases to let linux users custom-define the app frame size?

That way we wouldn't be dependant on how Electron wrongly deals with the full screen code and fails to get it right. Instead, you would only need to enter your screen size to define your background on full screen. Is that an idea?

[hovancik]

Just checking maximize() and

maximizable Boolean (optional) - Whether window is maximizable. This is not implemented on Linux. Default is true.

@dbankmann what do you mean by debugging? If I wanna check what I get, I print it in output. You can also run npm run dev and then open http://localhost:9222 in your browser and debug opened windows there. Haven't tried but you should be able to get to electron.screen somehow.

@jgisde yep, I was thinking about it. 800x600 is only because it's default electron window size :D. It's on my todo, to have this as item in config file. It won't help with dual screens, thought.

BTW, I think that extra space on bottom is electron thinking there is some bar. Or DE returning the value. That's probably one of the reasons electron folks rarely fix Linux issues, each DE behaves differently.

[dbankmann]

@jgside: I just ran npm run dist, then also the pacman archive gets created.

@hovancik : Can you point me to somewhere, where you do this with output?
In the console I can only see the electron and the screen object, not electron.screen and screen does not have the getAllDisplays method.

[hovancik]

@dbankmann I just noticed that https://www.electronjs.org/docs/api/screen#screen says Note: In the renderer / DevTools, window.screen is a reserved DOM property, so writing let { screen } = require('electron') will not work.

So you will have to use this in main.js

  console.log(require('electron').screen.getAllDisplays())

somewhere where app is loaded, so for example in startPowerMonitoring function.

You will see output in console.

[jgisde]

@dbankmann: Gnome. I have no bottom taskbar, so that cannot be in my case. Does it make a difference in Xfce with autohide on/off for the taskbar?

hovancik: BTW, I think that extra space on bottom is electron thinking there is some bar.

@dbankmann @hovancik: Well, I found and sort of solved the problem. Once the workaround is applied, the other problem It's indeed totally related to the linux panel-bar code, as suspected.

Somehow, even if the Gnome DE works primarily with a top bar, it's seems still to be a DE tweak from the core linux bottom bar object. Or that's how Electron thinks about it.

So, I looked for a gnome panel-control extension...

... and voilá :)

So, for the time being it is solved for me. Any DE allows to tweak the bar, so there's a potential solution for everyone till it gets officially patched.

Thanks a lot for this great app and all the support!

[jgisde]

@jgside: I just ran npm run dist, then also the pacman archive gets created.

@dbankmann: That's what I was trying yesterday but I got only errors. Today after cleaning both Electron caches I tried again and it kind of 'worked', still got some errors about missing stuff.

'Dist' folder was created with .tar, .deb and AppImage packages, but no the .pacman ones.
Then the AppImage gave the option to 'Install', but then it didn't, only the program did run.

I read about some Arch users complaining about 'npm' builder in our architecture, but right now I have no time to find a solution. So for the time being I just created a stretchly.desktop file to integrate it as an app.

Anyhow, thanks again for the great workaround!

[dbankmann]

@jgisde: I think I was missing rpmbuilder. I removed the rpm target in package.json and the remaining builds went through.

@hovancik: Thanks, that worked. Apparently, GNOME and XFCE somehow alter the workSpace value of screens according to the taskbar size.

[
  {
    id: 8564615341547078,
    bounds: { x: 0, y: 0, width: 2560, height: 1440 },
    workArea: { x: 0, y: 18, width: 2560, height: 1422 },
    accelerometerSupport: 'unknown',
    monochrome: false,
    colorDepth: 24,
    colorSpace: '{primaries:INVALID, transfer:INVALID, matrix:INVALID, range:INVALID}',
    depthPerComponent: 8,
    size: { width: 2560, height: 1440 },
    workAreaSize: { width: 2560, height: 1422 },
    scaleFactor: 1.5,
    rotation: 0,
    internal: false,
    touchSupport: 'unknown'
  }
]
{
  autoHideMenuBar: true,
  icon: '/home/daniel/projects/stretchly/app/images/windowIcon.png',
  resizable: false,
  frame: false,
  show: false,
  backgroundColor: '#478484',
  skipTaskbar: true,
  focusable: false,
  title: 'stretchly',
  alwaysOnTop: true,
  webPreferences: { nodeIntegration: true },
  width: 2560,
  height: 1440,
  x: 0,
  y: 0
}

Probably window size is limited to workArea width and height.

If you use the workArea property instead of the bounds property, it's also working for XFCE and GNOME (except for the taskbar still being visible), see dbankmann@f3dc102 .
And indeed, this is very similar to the linked PR.
My local Dual Screen setup works perfectly, btw.

[jgisde]

If you use the workArea property instead of the bounds property, it's also working for XFCE and GNOME (except for the taskbar still being visible)

@dbankmann: Tested: now in Gnome the top bar remains indeed visible, instead of the 'invisible' bottom one. 'Pospone' line gets still cut on the lower side, so I changed the css to 40x again to get it right. At least now anyone could choose to let the bar always visible during breaks, if desired.

Also, if you choose to keep the top bar on full black (or any other color) it looks just great. Somehow this bug opens some unexpected extra 'custom' settings to this app ;) Nice to be able to integrate the basic system info on full-screen mode, as well as the app menu :)

@jgisde: I think I was missing rpmbuilder. I removed the rpm target in package.json and the remaining builds went through.

Now it's working, thanks!

[dbankmann]

Another note:
I had some troubles on another machine with dual screen, where the second and larger screen would only create a window of the smaller monitor's size.
This only applied, when the smaller monitor was left of the larger.

Have a look at the following log:

monitors [
  {
    id: 4693782672817732,
    bounds: { x: 1280, y: 0, width: 1920, height: 1200 },
    workArea: { x: 1280, y: 0, width: 1920, height: 1200 },
    accelerometerSupport: 'unknown',
    monochrome: false,
    colorDepth: 24,
    colorSpace: '{primaries:INVALID, transfer:INVALID, matrix:INVALID, range:INVALID}',
    depthPerComponent: 8,
    size: { width: 1920, height: 1200 },
    workAreaSize: { width: 1920, height: 1200 },
    scaleFactor: 1,
    rotation: 0,
    internal: false,
    touchSupport: 'unknown'
  },
  {
    id: 21442169663798852,
    bounds: { x: 0, y: 0, width: 1280, height: 1024 },
    workArea: { x: 0, y: 0, width: 1280, height: 1024 },
    accelerometerSupport: 'unknown',
    monochrome: false,
    colorDepth: 24,
    colorSpace: '{primaries:INVALID, transfer:INVALID, matrix:INVALID, range:INVALID}',
    depthPerComponent: 8,
    size: { width: 1280, height: 1024 },
    workAreaSize: { width: 1280, height: 1024 },
    scaleFactor: 1,
    rotation: 0,
    internal: false,
    touchSupport: 'unknown'
  }]
monitors id 0
monitors windowOptions {
  autoHideMenuBar: true,
  icon: '/home/daniel/tmp/stretchly/app/images/windowIcon.png',
  resizable: false,
  frame: false,
  show: false,
  backgroundColor: '#633738',
  skipTaskbar: true,
  focusable: false,
  title: 'stretchly',
  alwaysOnTop: true,
  webPreferences: { nodeIntegration: true },
  width: 1920,
  height: 1200,
  x: 1280,
  y: 0
}
microbreakWinLocal.Bounds after creation { x: 1280, y: 0, width: 1279, height: 1023 }
microbreakWinLocal.Bounds after reapplying bounds { x: 1280, y: 0, width: 1920, height: 1200 }
monitors id 1
monitors windowOptions {
  autoHideMenuBar: true,
  icon: '/home/daniel/tmp/stretchly/app/images/windowIcon.png',
  resizable: false,
  frame: false,
  show: false,
  backgroundColor: '#633738',
  skipTaskbar: true,
  focusable: false,
  title: 'stretchly',
  alwaysOnTop: true,
  webPreferences: { nodeIntegration: true },
  width: 1280,
  height: 1024,
  x: 0,
  y: 0
}
microbreakWinLocal.Bounds after creation { x: 0, y: 0, width: 1279, height: 1023 }
microbreakWinLocal.Bounds after reapplying bounds { x: 0, y: 0, width: 1279, height: 1023 }

Apparently, not all properties in windowOptions where applied to the BrowserWindow object.
Reapplying the correct height and width settings via window.setBounds(...) solves also that problem, see dbankmann@65cc646 .

So, at least for my i3 multihead setups, this is working.

[hovancik]

Thanks for the work, guys. Will try to test,but as I am working on new designs so not a lot of time.

[hovancik]

@dbankmann I am trying your branch.

Your branch without any changes: microbreaks seems good, breaks hide "skip/postpone"

Your branch on my master: microbreaks seems good, breaks hide "skip/postpone"

Your branch on my redesign branch (higer electron version) does not seems to work, covers only parts of screen.

monitors [
  {
    id: 1707216913938242,
    bounds: { x: 0, y: 0, width: 1476, height: 923 },
    workArea: { x: 20, y: 23, width: 1457, height: 860 },
    accelerometerSupport: 'unknown',
    monochrome: false,
    colorDepth: 24,
    colorSpace: '{primaries_d50_referred: [[0.6587, 0.3332],  [0.3206, 0.6135],  [0.1508, 0.0527]], transfer:IEC61966_2_1, matrix:RGB, range:FULL}',
    depthPerComponent: 8,
    size: { width: 1476, height: 923 },
    workAreaSize: { width: 1457, height: 860 },
    scaleFactor: 1.2999999523162842,
    rotation: 0,
    internal: false,
    touchSupport: 'unknown'
  }
]

monitors id 0
monitors windowOptions {
  autoHideMenuBar: true,
  icon: '/home/conta/workspace/hovancik/stretchly/app/images/app-icons/trayMonochromeInverted.png',
  resizable: false,
  frame: false,
  show: false,
  backgroundColor: '#478484',
  skipTaskbar: true,
  focusable: false,
  title: 'Stretchly',
  alwaysOnTop: true,
  webPreferences: { nodeIntegration: true },
  width: 1476,
  height: 923,
  x: 20,
  y: 23
}
microbreakWinLocal.Bounds after creation { x: 20, y: 22, width: 1459, height: 864 }
microbreakWinLocal.Bounds after reapplying bounds { x: 20, y: 21, width: 1477, height: 924 }

From version that works:

 monitors [
  {
    id: 1707216913938242,
    bounds: { x: 0, y: 0, width: 1476, height: 923 },
    workArea: { x: 20, y: 23, width: 1457, height: 860 },
    accelerometerSupport: 'unknown',
    monochrome: false,
    colorDepth: 24,
    colorSpace: '{primaries_d50_referred: [[0.6587, 0.3332],  [0.3206, 0.6135],  [0.1508, 0.0527]], transfer:IEC61966_2_1, matrix:RGB, range:FULL}',
    depthPerComponent: 8,
    size: { width: 1476, height: 923 },
    workAreaSize: { width: 1457, height: 860 },
    scaleFactor: 1.2999999523162842,
    rotation: 0,
    internal: false,
    touchSupport: 'unknown'
  }
]

Not sure about the numbers I see, my monitor is 1920x1200. If I put x1.3 (scale factor), I get numbers that look right, but window size does not change.

monitors id 0
monitors windowOptions {
  autoHideMenuBar: true,
  icon: '/home/conta/workspace/hovancik/stretchly/app/images/app-icons/trayMonochromeInverted.png',
  resizable: false,
  frame: false,
  show: false,
  backgroundColor: '#478484',
  skipTaskbar: true,
  focusable: false,
  title: 'Stretchly',
  alwaysOnTop: true,
  webPreferences: { nodeIntegration: true },
  width: 1919,
  height: 1200,
  x: 26,
  y: 30
}
microbreakWinLocal.Bounds after creation { x: 25, y: 30, width: 1460, height: 863 }
microbreakWinLocal.Bounds after reapplying bounds { x: 24, y: 30, width: 1920, height: 1200 }

I am not sure if it's worth trying to fix this as every electron version seems to work differently. I will probably hide fullscreen option on Linux.

[jgisde]

I am not sure if it's worth trying to fix this as every electron version seems to work differently. I will probably hide fullscreen option on Linux.

Please don't remove the fullscreen option on Linux. For me it works perfect now (on @dbankmann last version) whether it's integrated with the gnome top bar or completely fullscreen with the "hide top bar" extension on.

Truth is, non-fullscreen window is not that efficient for detaching yourself from other tasks and take a real break (mainly for workaholics like me :).

Linux users we are used to continuosly having to tweak apps or the system itself to get it our way, so as long as there's an open option to solve it, that's all we need. Electron bugs are there and always will be, but on linux we can find a workaround.

On my Windows 10 office laptop, after one of the last system updates, I also had to install the Electron-6 version you posted, and now works as intended, even on 'Don't disturb' mode. It looks Electron 7 is suffering from some bugs on all platforms.

[dbankmann]

That looks strange, seems like they messed up something with the scaling factor. Can you point me to a commit hash of the failing version? I don't see any problems with my setup.

[hovancik]

@jgisde what I meant was to hide the option UI, as it does not work anyway.

@dbankmann I've pushed https://github.com/hovancik/stretchly/tree/fix/linux-fullscreen, but it's only your code merged to my latest code in redesign branch

[dbankmann]

hmm, seems its just the kiosk mode. I could replicate your problem, and without kiosk mode it's working again. see the latest commit 2ae98ae

Also, a sideremark. Electron>=8 apps are currently not compatible with i3status bar, see i3/i3#2088

[hovancik]

@dbankmann thanks, you are totally right ;]

testing on my single monitor and looks good, thought normal window size option gives error.
I've created PR and will check the error

[hovancik]

btw that problem with tray, in XFCE, electron >= 8 solves the tray issues :D

[hovancik]

If anyone is willing to try test the PR, I would be glad. Testing on Debian XFCE and works nice with 2 displays. Also tried on mac and no issues.

[smith558]

Is there a workaround for this to implement on Ubuntu?

[hovancik]

@smith558 the fix has been merged and will be out with upcoming 1.0 release. Works fine for me on Debian with KDE/XFCE so I guess Ubuntu will work as well...

[smith558]

@hovancik Awesome! Is it possible there is a delay for me because I am running on Wayland?

[hovancik]

@smith558 it has not yet been released and can't really guess when I will release it, but hopefully not much longer :D

[hovancik]

closing as I have merged changes to master and hopefully make new release today