Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permanent system tray icon (not only when taking a snapshot) #1370

Open
aryoda opened this issue Nov 22, 2022 · 5 comments
Open

Permanent system tray icon (not only when taking a snapshot) #1370

aryoda opened this issue Nov 22, 2022 · 5 comments
Labels
Feature requests a new feature High Meta

Comments

@aryoda
Copy link
Contributor

aryoda commented Nov 22, 2022

@Anard requested this feature in another unrelated issue so I have added it as new feature request

I would like to have access to BackInTime in systray even if it's not taking a snapshot
as eg. done by TimeMachine on macOS, allowing to launch BiT or take a snapshot instantly without launching the app.

@aryoda aryoda added the Feature requests a new feature label Nov 22, 2022
@aryoda
Copy link
Contributor Author

aryoda commented Jul 16, 2023

I think a permanent systray icon could be shown for the user (and one extra possibly for BiT root) by

  • removing the code that exists when the BiT job is no longer busy:
    def updateInfo(self):
    if not self.snapshots.busy():
    self.prepairExit()
    self.qapp.exit(0)
    return
  • adding a menu item to close the systray icon
  • showing the user name in the systray icon tooltip or menu
  • adding logic to prevent starting multiple instances, e.g. by reusing applicationinstance.py to maintain an extra PID file:
    def check(self, autoExit=False):
    """
    Check if the current application is already running
    Args:
    autoExit (bool): automatically call sys.exit if there is an other
    instance running
    Returns:
    bool: ``True`` if this is the only application instance
    """
  • finding a way to autostart the systray icon on every distro (this looks like packaging/package maintainer task since it depends on the distro and Linux version

@aryoda
Copy link
Contributor Author

aryoda commented Jul 16, 2023

I could add an additional experimental argument to qtsystrayicon.py quite easily (+ a starter script for testing it)...

@buhtz
Copy link
Member

buhtz commented Jul 17, 2023

In the past I investigated different approaches how to upgrade our upstream repo to the current python packaging standards (using src-layout; pyproject.toml without setup.cfg and setup.py; without sys.path hacking; install via Developlment Mode using pip's --editable install; ...). I also discussed this with debian maintainers to take there needs into account.

I'm not finished yet. But I'm quit sure that the best solution is to treat "backintime" (the CLI) and "backintim-qt" (the GUI) as separate packages. It is not very different from what we do currently.

So I ask myself if it might be a good idea to treat the systray component as a separate package, too?
But we also could treat it as part of "backintime-qt". In that case we would just defined an additional entry point (resulting in a /usr/bin starter script like "backintime" and "backintime-qt") in that python package to start the systray.

@aryoda
Copy link
Contributor Author

aryoda commented Jul 17, 2023

So I ask myself if it might be a good idea to treat the systray component as a separate package, too?

Very good point. The code should stay in backintime-qt since it mostly reuses existing code.
A starter script should also be in backintime-qt.

To enable a permanent systray icon a new package could be used to execute the starter script when the user logs in.
This package would depend only on backintime-qt.
We could even introduce multiple packages if "autostarting" the systray icon requires different settings on different distros (but then we would take on the pkg maintainer role again - do we want this at all?).

@buhtz
Copy link
Member

buhtz commented Jul 17, 2023

It is quit easy to have multiple starter scripts for one package. As an example of my demo here a snipped from the pyproject.toml:

[tool.setuptools.package-dir]
bitcli = "src/bitcli"
bitgui = "src/bitgui"

[project.scripts]
bitcli = "bitcli.__main__:main"
bitcli-root = "bitcli.__main__:run_main_as_root_via_policykit"
bitgui = "bitgui.__main__:main"
bitgui-root = "bitgui.__main__:run_main_as_root_via_policykit"

This is not the final solution with two separate packages I have in mind! It is just one distribution package (name d bitdemo) offering two import packages (bitcli & bitgui).

Because of the first section [tool.setuptools.package-dir] you can do import bitcli and import bitgui.

More interesting is the section [project.scripts] offering four entry points. Pip/setuptools (which will be used by debian maintainers, too) do generate four starter scripts in /usr/bin.

I used that demo repo to illustrate our needs in the discussion with Debian maintainers and with the folks from pip and setuptools. I will add the systray aspect to the demo, too. I just stoped with that demo because I realized that it is damn to early migrating BIT to the new packaging standards. There are much more emerging issues. 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature requests a new feature High Meta
Projects
None yet
Development

No branches or pull requests

2 participants