Added hide to tray option

[Devenor]

Added hide to tray option

Pull Request Type

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue

closes #59

Description

Adds optional hide to system tray behaviour on closing and/or minimizing the main window. The settings have an option to enable or disable it in the general section. The tray icon has a small menu for closing the app or opening the window again, and it can be opened by clicking on the icon too.

Screenshots

https://imgur.com/a/1TVWBJp

https://imgur.com/a/xvBEqFe

Testing

• Go to Settings -> General and enable Minimize to system tray.
• When minimizing a window, the window will hide and a tray icon will appear.
• [Only on Windows] If there's only one window in the tray, left clicking the tray will open the window and the tray will disappear.
• Right clicking the tray will show a menu with an option to quit the app, and one submenu for each minimized window.
• Clicking the submenu will show one option to open the window and another to close it. When clicking an option, the submenu will disappear.
• If there are no more windows minimized, on Windows the tray will disappear, and on Linux it will remain with just the quit option.
• When a window is shown from the tray, it will retain its original size and position.
• When disabling the setting, if there are minimized windows they'll appear minimized in the taskbar.
• This setting is not avaliable for MacOS.

Desktop

• OS: Windows
• OS Version: 10
• FreeTube version: v0.23.2 Beta

Additional context

[absidue]

Please fix the build and revert all unrelated changes such as the dependency additions, there is no need to manually extract anything from the asar file and the translations are overkill at the moment (especially pulling in multiple dependencies just to translate 2 strings).

Even after the corrections there are still open questions such as how to handle multiple windows.

[Devenor]

Thanks for the review, I reverted the new dependencies (I didn't know you could read asar directly from node fs! It's much better now). About the i18n, if needed maybe we could send the translated text via IPC and recreate the tray.

As for how to handle multiple windows, I didn't know you could have more than one, is there some kind of setting for that?

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[absidue]

Looks like you may have mistakenly used npm instead of yarn to install the dependencies and pushed a package-lock.json file, additionally there seem to be changes to the yarn.lock file which shouldn't really be there as the dependencies are no longer changing in this PR.

[Devenor]

I'm not able to reproduce that behaviour in my Ubuntu, when I click the window it stays there. It's weird too because, as far as I know, there's no handler for that type of events, so it should behave normally. Does it happen in previous builds too?

There's a small adjustment I had to make that I'd like to test more thoroughly, but it's specific to the tray code, so feel free to merge this and I'll do some more testing afterwards.

I would like to know what you had to adjust and why.

There was a check in createWindow from the very first commit, that would destroy the tray if it already existed. Now that logic is handled in manageTray, so I had to remove it from createWindow because it was destroying the tray when it shouldn't.

Also like Pika already mentioned, we would like to see the testing section of the PR updated so we generally know what to test.

You mean like listing the things we've been testing so far?

[efb4f5ff-1298-471a-8973-3d47447115dc]

Also like Pika already mentioned, we would like to see the testing section of the PR updated so we generally know what to test.

You mean like listing the things we've been testing so far?

Taken from our recently made changes to the PR template:

Please provide instructions so that others can ensure that your pull request would produce correct results. For examples see, #5743, #7349, #5125, #7338

[efb4f5ff-1298-471a-8973-3d47447115dc]

I'm not able to reproduce that behaviour in my Ubuntu, when I click the window it stays there. It's weird too because, as far as I know, there's no handler for that type of events, so it should behave normally. Does it happen in previous builds too?

Its weird i can reproduce this on the very first commit you made. I'll spin up my other vm's to check if this is consistent

[efb4f5ff-1298-471a-8973-3d47447115dc]

Created a fresh ubuntu vm and its still happening

[Devenor]

@efb4f5ff-1298-471a-8973-3d47447115dc I'm afraid you'll have to add some traces again. Please add this in the minimize handler (under line 976 in src/main/index.js):

• dialog.showMessageBoxSync({message: 'minimize'})

That should be the only place where the tray logic is called, so let's start by checking if it's invoking the handler. The message should pop once when you click the minimize button (that's expected), and then let's see what happens.

I've updated the testing section of the PR too.

[efb4f5ff-1298-471a-8973-3d47447115dc]

@Devenor something to note is that when i minimize you can see on the left hand side that it thinks a new window has been opened. So when i minimized the first time it showed 2 dots indicating that there were 2 windows. This will be more apparent later in the video

VirtualBoxVM_5pISWqdcc1.mp4

[Devenor]

The two dots seem ok, one is the main window and the other one is the dialog, but the four dots and multiple windows in the tray in the end is not... let's focus on why the handler is being invoked, please try again after moving the dialog above line 976 and disabling the tray setting.

[efb4f5ff-1298-471a-8973-3d47447115dc]

So only comment out this part https://github.com/FreeTubeApp/FreeTube/pull/6915/files#diff-f4ca67281c6be819c2166841d7631ffd5316d4c3a3b40e01a512c4113a537b2cR975

[Devenor]

I mean like this, and disabling the Minimize to system tray option to see if it continues invoking the handler:

    newWindow.on('minimize', (event) => {
      dialog.showMessageBoxSync({message: 'minimize'})
      if (trayOnMinimize) {
        newWindow.hide()
        manageTray(newWindow)
      }
    })

[efb4f5ff-1298-471a-8973-3d47447115dc]

@Devenor i dont see any difference to what you have provided vs the actual code?

[Devenor]

It's in the showMessageBoxSync placement, in the code you tested it should be after the if (trayOnMinimize) {, now i'd like to try moving it outside the if statement, to check if the message appears even when the setting is disabled.

[efb4f5ff-1298-471a-8973-3d47447115dc]

VirtualBoxVM_FMpJTxsZc3.mp4

[Devenor]

After doing that, if you activate the setting again and click the title bar, does it breaks or it keeps working?

[efb4f5ff-1298-471a-8973-3d47447115dc]

Behavior still happening

VirtualBoxVM_HohBNUc96s.mp4

[Devenor]

That's an interesting test though, I thought the problem might be when starting the app, but now we know that it seems to happen precisely when hiding or showing the window. There's a couple of things we can try, let's start by removing some stuff and see if there's any difference, please do:

• Delete setIgnoreDoubleClickEvents (line 710)
• Comment maximize and minimize handlers (lines 983 to 989)

Gotta sleep, I'll check it out tomorrow.

[efb4f5ff-1298-471a-8973-3d47447115dc]

Do you also want me to revert the changes i made previously?

[Devenor]

Ok, then the lines to comment will be 982 to 988, line 710 remains the same.

[efb4f5ff-1298-471a-8973-3d47447115dc]

will do have a good night!

[efb4f5ff-1298-471a-8973-3d47447115dc]

Same results

VirtualBoxVM_Xxuf7AG0Dg.mp4

[Devenor]

Let's test two more things:

• Try the same with the window not maximized before clicking on minimize
• Try the same after changing newWindow.hide() to newWindow.minimize() in line 976

The second test won't minimize the window to the tray, but will let us now if there's a problem with the hide method.

[efb4f5ff-1298-471a-8973-3d47447115dc]

Try the same with the window not maximized before clicking on minimize

VirtualBoxVM_JKGvFM4dbu.mp4

Try the same after changing newWindow.hide() to newWindow.minimize() in line 976

Seems promising

VirtualBoxVM_ZEwK4XOdik.mp4

[Devenor]

Mmm... but this means it's happening when calling Electron's hide method, that's unsettling. I'd like to know if it started happening after some of the recent changes or if it's always been there and we didn't notice, could you test it in one of the first commits ? Maybe eb34595?

[efb4f5ff-1298-471a-8973-3d47447115dc]

I'd like to know if it started happening after some of the recent changes or if it's always been there and we didn't notice, could you test it in one of the first commits ? Maybe eb34595?

@Devenor didnt i already answer your question here?

I'm not able to reproduce that behaviour in my Ubuntu, when I click the window it stays there. It's weird too because, as far as I know, there's no handler for that type of events, so it should behave normally. Does it happen in previous builds too?

Its weird i can reproduce this on the very first commit you made. I'll spin up my other vm's to check if this is consistent

[Devenor]

Yeah sorry, that's what I needed to know.

If there's an issue with the hide method we have a problem, because that's essential for the tray to work. I've managed to reproduce the issue in a VM, but it's too clunky to do anything, I'll try to set it up in a better way and see if I can find a workaround.