search

debauchee / barrier

Open-source KVM software
Other
27.37k stars 1.51k forks source link

System tray is unavailable #155

Open cccaballero opened 5 years ago

cccaballero commented 5 years ago

Operating Systems

Server: Ubuntu 18.04 (amd64)

Client: Ubuntu 18.04 (amd64)

Barrier Version

2.1.0-snapshot-773a0081

Steps to reproduce bug

  1. Open Barrier
  2. An error dialog is oppened saying: "System tray is unavailable, don't close your window"
  3. The app open and works ok, but the system tray icon does not appear.

Other info

johnny-mac commented 5 years ago

I put sleep 10s or sleep 25s infront of barrier --config ~/.barrier.sgc (or wherever your config file is)

cccaballero commented 5 years ago

Ok, I am not able to find any .sgc file in my home, I just find a reference to a inexistent ~/barrier.conf file. Should I create it? And how should I include the sleep option? just includding sleep 25s in the file?

Forage commented 5 years ago

The system tray does not exist any more in Ubuntu 18.04, at least if you use the default Shell. Simply ignoring the message and closing the main window, only to launch the app again when needed, does not cause any problems for me. It simply keeps running as it is supposed to do.

You could install https://extensions.gnome.org/extension/615/appindicator-support/ if you feel the need to have an icon bothering you. It will probably get rid of the message as well.

In the end Barrier should be adapted to no longer rely on a system tray icon concept.

cccaballero commented 5 years ago

Hi @Forage, thanks for your answer, the thing is that It was working and some "random" day stop working. I have another two Ubuntu 18.04 installations and it is working. Ubuntu 18.04 uses by default an app indicator extension.

As you say, the app works, but the error message and the delay opening (there are about 30 seconds between launching the app and the error message) is really annoying.

Forage commented 5 years ago

You are right about Ubuntu having an app indicator extension, but I did not know you came from a clean install, upgrade or clean GNOME Shell.

The delay can be a bit annoying indeed.

erenfro commented 5 years ago

Seems that elementary OS has also removed systray support totally. Even if you patch it back in using some methods I'd found, that only adds appindicator support, which Barrier does not seem to actually use. (nor honestly anyone should. appindicator IMHO is one of those garbage things Canonical tried to push, and the concept was worse than systray itself).

Anyway. Dependency on system-tray support itself should be optional and an additive, not a warning. The ability to specifically close the app while the server or client remains running, and be able to re-load the GUI app to see logs, stop/start/configure, should be the primary functionality. An option for the client to minimize itself on launch when no systray support is detected could eliminate some issues while retaining backwards and future compatibility I think.

AdrianKoshka commented 5 years ago

If anyone is willing to write the code and make a pull-request we're more than happy to accept it.

TafThorne commented 5 years ago

I have started to look at this under my fork. As I have not worked on this code base before I expect it will take some time for me to complete anything more than very basic changes.

See the progress here: https://github.com/TafThorne/barrier/tree/run-without-system-tray-support

Presently I have reduced the timer and changed the error message to a warning in the logs.
(Well I think that is what I have done. As I am still trying to resolve the issue where I cannot run natively I am going to need to get flatpak generation working so I can perform local tests. All good new skills to pick up.)

If the rudimentary changes I have so far sound good enough for a start I would be happy to generate a merge request. Other wise I shall continue to check that the the following acceptance criteria are met:

Forage commented 5 years ago

Thanks for picking this up.

Points 3 and 4 are already the case. In the current release you can safely close the UI and the server keeps on running nicely.

I don't see the point in point 5 though. I'd even consider it a bad idea, as it leaves you with no way to return to the UI. If you run vanilla gnome shell, you'll have no visible running process in your application bar after you close the UI, there is no concept of "minimizing". If you do see a valid use case for the option, it should be considered outside of the scope of this issue.

What I do miss in the checklist is a check for (essential) loss of functionality by getting rid of the system tray. What did it offer to begin with and do parts of it need to be replaced somehow? As I've never used the systems tray I can't say I'm missing something, but that might be different for those who kept clinging to it for way too long by using hacks and replacements.

TafThorne commented 5 years ago

Thanks for picking this up.

You are welcome. Hopefully I can give something back by getting this issue resolved.

Points 3 and 4 are already the case.

That is handy. It could mean that my rather simple changes so far as sufficient for the more basic interpretation of this change to be Done.

I don't see the point in point 5 though. I'd even consider it a bad idea, as it leaves you with no way to return to the UI.

Reading this contradicts your statement about 4 being done. To return to the UI you open the application again using your Operating System's / Desktop's standard methods. When the UI part of the application picks up that either the server or client is running it becomes the front end of that instance just as if it was never "closed".

What did it offer to begin with and do parts of it need to be replaced somehow?

It offered a set of shortcuts to:

In addition, it was a visible clue that the Barrier application was being executed in the background.

AFAIK, that was all that happened. IMO opening the main GUI to perform these operations is OK. Some Linux users have a little less functionality that Windows users (who keep the Notifications area applications).

I was attempting to replicate the essence of @erenfro 's statment in the 5th bullet point. Perhase they could check what I wrote there and here and see if they agree with my summary. It is possibly a wider project decision as to whether there is a need for futher action to be taken to replace the systray elements when they do not exist.

dregimbal commented 5 years ago

I get this error when I have Barrier installed through flatpak, but not when I've used the source from github and built it myself, on Ubuntu

Zazaaaa commented 4 years ago

I have started to look at this under my fork. As I have not worked on this code base before I expect it will take some time for me to complete anything more than very basic changes.

See the progress here: https://github.com/TafThorne/barrier/tree/run-without-system-tray-support

Presently I have reduced the timer and changed the error message to a warning in the logs. (Well I think that is what I have done. As I am still trying to resolve the issue where I cannot run natively I am going to need to get flatpak generation working so I can perform local tests. All good new skills to pick up.)

If the rudimentary changes I have so far sound good enough for a start I would be happy to generate a merge request. Other wise I shall continue to check that the the following acceptance criteria are met:

  • [x] Application has reduced delay at start
  • [x] No error message is given for missing system-tray support in OS
  • [ ] GUI starts the server or client but leaves it running when GUI is closed
  • [ ] Starting the GUI will cause it to check if a server or client is already running and reconnect with it
  • [ ] Add option to have GUI minimise itself on launch when no systray support is detected

Hello @TafThorne. Sorry to bother you, but do you still have solution to the system tray problem?

TafThorne commented 4 years ago

No @Zazaaaa I did not do further work on the issue besides taking part in the discussion under #236 about a more complete solution.

jvanheugten commented 3 years ago

Using https://extensions.gnome.org/extension/615/appindicator-support/ worked for me. If you don't use this extension, there is no way to open the barrier GUI for the running instance. Otherwise, opening barrier results in starting a new instance. This makes it hard to change the settings on the fly using the GUI, without resorting to pkill barrier. Ideally, opening barrier results in showing the GUI if an existing barrier instance exists.

adaminbanks commented 3 years ago

Switching my client side Fedora machine from "Gnome" to "Xfce" fixed my connectivity problems. Barrier debug1 outputed no errors and showed successful switching from monitor to monitor, but with no mouse appearance. Keyboard worked and eventual disconnect occured. Barrier debug1 reads no errors and works at intended now, I hope this helps someone.