Recent

Author Topic: Problem with TrayIcon: mantis 35723  (Read 3378 times)

bonmario

  • Sr. Member
  • ****
  • Posts: 296
Problem with TrayIcon: mantis 35723
« on: September 30, 2019, 07:54:09 pm »
Hi,
this is the mantis link: https://bugs.freepascal.org/view.php?id=35723

Quote
Ah, thanks Mario. I tested against so many Distros, I did not even know that Ubuntu made a Cinnamon one. What is it called ?

I'm using Ubuntu 19.04 64 bit, and i have installed Cinnamon from Synaptic.



Quote
Mario, can you please tell me if it has libappindicator.so or libappindicator3.so installed ?

Code: Text  [Select]
  1. bonmario@bonmario-desktop:~$ ldconfig -p | grep libapp
  2.         libappindicator3.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libappindicator3.so.1
  3.         libappindicator.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libappindicator.so.1
  4.  


Hi, Mario
« Last Edit: September 30, 2019, 08:14:42 pm by bonmario »

dbannon

  • Hero Member
  • *****
  • Posts: 774
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Problem with TrayIcon: mantis 35723
« Reply #1 on: October 01, 2019, 12:30:11 am »
Ah, well done Mario. Much easier here.

Your system has both libappindicator and libappindicator3, so prior to release 61820 it would load libappindicar3 and be happy. If you remove libappindicator3, then it would fall back to the old SystemTray model. Few OS now support that model, even less will as time goes by. While we could spend days discussing why thats a bad thing, no point, its happening. See -

https://goodies.xfce.org/projects/panel-plugins/xfce4-statusnotifier-plugin

https://blog.linuxmint.com/?p=3795

https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html - "gtk_status_icon_new has been deprecated since version 3.14 and should not be used in newly-written code. Use GNotification and GtkApplication to provide status notifications"

https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/


To see what the current state of play is, please See my table here - https://wiki.freepascal.org/Talk:How_to_use_a_TrayIcon#Linux_Problems

In particular, note that the changes made recently have disabled any system tray in both what I consider mainstream Linux distros. Its mainly about Wayland, I found you could get sensible menu placement if you disable Wayland but am reluctant to suggest my users do that. And, whether you like it or not, Wayland is apparently the way we are heading.

So, I have to ask, what is it you like about the old SystemTray model ?  Is it being able to detect left clicks separately from popup menu ?  Even if you can do it now, the evidence is, it won't be there in the next few years.

Davo
« Last Edit: October 01, 2019, 02:08:06 am by dbannon »
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3647
  • I like bugs.
Re: Problem with TrayIcon: mantis 35723
« Reply #2 on: October 01, 2019, 04:35:59 pm »
In particular, note that the changes made recently have disabled any system tray in both what I consider mainstream Linux distros. Its mainly about Wayland, I found you could get sensible menu placement if you disable Wayland but am reluctant to suggest my users do that. And, whether you like it or not, Wayland is apparently the way we are heading.
Then we must test for more desktops than just Unity. Maybe also Cinnamon?
Wayland is not a desktop, it is an X-Window system replacement. Do the desktops behave differently when they are under Wayland?
Here is my latest note in issue:
 https://bugs.freepascal.org/view.php?id=35723
---
r61758 in 0035983 solved the issue on my Manjaro Linux with KDE. It now works with both GTK2 and QT(5) bindings.
What should be tested in function UnityAppIndicatorInit to make it work in every distro?
Now it tests for "GetEnvironmentVariableUTF8('XDG_CURRENT_DESKTOP') <> 'Unity' ".
Should we test for Cinnamon?
My Manjaro has libappindicator3.so installed but apparently it is not needed with KDE. Instead, loading it screws things up.

dbannon

  • Hero Member
  • *****
  • Posts: 774
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Problem with TrayIcon: mantis 35723
« Reply #3 on: October 01, 2019, 10:14:56 pm »
JuhaManninen, sorry, perhaps I am confusing you.
Unity is dead (thank the Lord), Ubuntu abandoned it several releases ago.

The Gnome developers decided that the SystemTray was too complicated and stopped (just like that) supporting it. While RedHat ewent along with that decision (as you would expect) Cannonical and KDE both decided they could at least find a solution that would get people over the transition to the newer approach. In Ubuntu they ported their own Libappindicator over to the Gnome Desktop. KDE came up with something similar, I suspect KDE went first ....

Meanwhile people started making things like TopIcons, probably just for Redhat flovoured system ?

Maybe this history is a bit out of order but basically OK.

I suspect Cinnamon  that Mario is using is 'just' a Cinnamon package installed on top of an existing Desktop. Not a tested and fine tuned complete package.

When you say r61758 in 0035983 solved the issue on my Manjaro Linux with KDE". what problem ?

All the System Tray need do is pop up a popup menu ?  it worked before 0035983 !

Davo




Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

bonmario

  • Sr. Member
  • ****
  • Posts: 296
Re: Problem with TrayIcon: mantis 35723
« Reply #4 on: October 02, 2019, 08:18:17 am »
I suspect Cinnamon  that Mario is using is 'just' a Cinnamon package installed on top of an existing Desktop. Not a tested and fine tuned complete package.

Cinnamon is the principal desktop environment of the Linux Mint distribution and is available as an optional desktop for other Linux distributions and other Unix-like operating systems as well.
https://en.wikipedia.org/wiki/Cinnamon_(desktop_environment)

I've installed it from Ubuntu's repositories


dbannon

  • Hero Member
  • *****
  • Posts: 774
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Problem with TrayIcon: mantis 35723
« Reply #5 on: October 02, 2019, 11:49:43 am »
Cinnamon is the principal desktop environment of the Linux Mint distribution and is available as an optional desktop for other Linux distributions and other Unix-like operating systems as well.
https://en.wikipedia.org/wiki/Cinnamon_(desktop_environment)

Yep, I have tested Linux Mint, (please) see my table at https://wiki.freepascal.org/Talk:How_to_use_a_TrayIcon#Linux_Problems. It works with the pre 61821. And it works with the post 61821 too, probably because it has not yet adopted wayland. The Linux Mint people were discussing this last year, not very positively.

Given that Gnome (and wayland as its Display Server) is the default desktop on Ubuntu, RedHat (inc Fedora) and Suse, my guess is that its far more common than any other particular desktop and probably represents about half of installed desktop Linux systems. Personally, I don't use it (much prefer Mate) but my users do. And there can be no denying its the a very important part of the Linux (and FreeBSD etc) world. Next most popular is KDE I suppose.

I am still unsure why the change in 35983 was made, any hint ?

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3647
  • I like bugs.
Re: Problem with TrayIcon: mantis 35723
« Reply #6 on: October 03, 2019, 04:46:12 am »
When you say r61758 in 0035983 solved the issue on my Manjaro Linux with KDE". what problem ?
All the System Tray need do is pop up a popup menu ?  it worked before 0035983 !
No, the System Tray also needs to call its OnClick handler when left-clicked.
I reopened the relevant issue:
 https://bugs.freepascal.org/view.php?id=35983
Please test with the provided demo application.
An uploaded patch gives special treatment for KDE only. Works for me. Do we need the same treatment for Cinnamon?
« Last Edit: October 03, 2019, 05:08:55 am by JuhaManninen »

dbannon

  • Hero Member
  • *****
  • Posts: 774
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Problem with TrayIcon: mantis 35723
« Reply #7 on: October 03, 2019, 09:14:42 am »
Quote
No, the System Tray also needs to call its OnClick handler when left-clicked.
Ahh, finally I understand.
Looking at my table, there seems to be a number of combinations. Note that Mate gives you System Panel menu, some give us a popup menu with either left or right click, some pass back to a click handler. I guess thats the "complicated interface" that Shuttleworth and the Gnome developers complain about.  :(
I always ensure both left or right click give me the popup menu because thats what I believe users expect. Maybe ....

Juha, my table says Cinnamon does work in both SystemTray mode and LibAppIndicator3 mode and yes, I see how its a touch more useful in SystemTray one. So, good idea for now. However, thats just the immediate problem. But from what I have read, the trend is going to be away from the SystemTray, did you read the XFCE blog for example ? And even libappindicator3 is just a transitional thing....

So, if programmers do write code that depends on being able to both trigger a Popup Menu and detect, separately, a left click, they will have a diminishing number of possible Linux OSs that will do so. And we'll have the situation where end users will upgrade their OS and find something no longer works. And more Distros might drop SystemTray without supporting the transitional LibAppIndicator3 (as RedHat and Suse have done).

I will keep testing and add a note on the wiki page that warns programmers about this situation. Trying to get a release of my app out right now too !

The real solution is, I am afraid, a new model for Linux depending on the AppNotifier instead. But the AppNotifier appears to be very poorly documented and, obviously there are not yet any Pascal bindings to it. It works through DBus but I cannot workout if we talk directly through dbus of if there is a common API closer to user spaces. Sigh ....

Thanks Juhu, sorry we are giving you a hard time !

Davo

EDIT: OK, I really understand now. If you don't assign a popup menu, then there are cases where 61820 does not show its icon !  And they can join the other cases where that icon is not visible. Sigh, what a mess. Juha's method of filtering out on a desktop by desktop basis seems an even better one now. 

Sorry, I never thought to test when there is no popup menu assigned.

If it was not just a temporary fix, I'd suggest it needs to be made some sort of compile time option because we need different rules for applications that will assign a menu compared to ones that want to deal with the click in their own code. I have altered my table to and will start mapping that extra behaviour. Sigh.
« Last Edit: October 03, 2019, 01:36:08 pm by dbannon »
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3647
  • I like bugs.
Re: Problem with TrayIcon: mantis 35723
« Reply #8 on: October 03, 2019, 02:04:38 pm »
EDIT: OK, I really understand now. If you don't assign a popup menu, then there are cases where 61820 does not show its icon !  And they can join the other cases where that icon is not visible. Sigh, what a mess. Juha's method of filtering out on a desktop by desktop basis seems an even better one now. 
I guess there is no perfect solution but we should commit something to make it work with as many distros as possible. My patch essentially reverts r61758 except for KDE. What else is needed?
I must confess I have no deep knowledge of this issue. I have not really used SystemTray in my apps. I haven't even read the XFCE blog (yet). I must trust you guys for a valid solution.

dbannon

  • Hero Member
  • *****
  • Posts: 774
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Problem with TrayIcon: mantis 35723
« Reply #9 on: October 04, 2019, 01:58:37 pm »
Juha, I have tested a few distros today and I confess to be quite unhappy. Truth is, it all depends on what the programmer wants to achieve. If all they want is a popup menu ist pretty easy to sort by distributions. But if the programmer wants to see that LeftClick event and maybe a right click menu, wow, the combinations possible is way out of scope.

I have data from six or seven distros at present, will need a lot more before coming up with a conclusive answer but I don't think whatever we do is likely to be pretty.

A wild card, how would you react to bringing out a new (Linux only) property for TrayIcon, allows the programmer to decide what is more important -
  • Unset, we'll do the default
  • Prefer the OldSystemTray except where we know it won't work - Good choice when we want to handle LeftClicks.
  • Prefer the LibAppIndicator3 except where we know it won't work - Good choice is all we want is a popup menu.
?

Neither Windows not Mac need such fussing.

Anyway, perhaps you need to wait until I have tested a few more distros.

Davo

Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

kupferstecher

  • Sr. Member
  • ****
  • Posts: 324
Re: Problem with TrayIcon: mantis 35723
« Reply #10 on: October 04, 2019, 02:47:36 pm »
Hello,
I ran into the same problem with Linuxmint 19.2 Mate. Under Lazarus 2.0.4 the left click wasn't firing and the icon had rendering issues (Looked like aliasing or wrong size bounds). I went back to 2.0.2 where it worked correctly.
I guess its what you already know, I just wanted to tell in case there is a further helping detail.

The left click behaviour is quite important for me. I sometimes implement a "tray mode" in my apps. I.e. when the tray mode is activated, the app will appear when clicking on the tray icon. Taking the focus away from the app, e.g. by clicking outside the app, the app window will disappear together with the taskbar item.


A wild card, how would you react to bringing out a new (Linux only) property for TrayIcon, allows the programmer to decide what is more important
Perhaps a setting for the target desktop environment would be more self explanatory. Different fall-back mechanisms still could be possible.

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3647
  • I like bugs.
Re: Problem with TrayIcon: mantis 35723
« Reply #11 on: October 04, 2019, 05:11:45 pm »
Juha, I have tested a few distros today and I confess to be quite unhappy. Truth is, it all depends on what the programmer wants to achieve. If all they want is a popup menu ist pretty easy to sort by distributions. But if the programmer wants to see that LeftClick event and maybe a right click menu, wow, the combinations possible is way out of scope.
I applied the test for KDE and Cinnamon in r61980 which I plan to merge for Lazarus 2.0.6. I understand the issue depends also on other things than desktop and LibAppIndicator3 lib so my commit is not perfect but improves things.
What else does the issue depend on?
You should update the wiki page:
 https://wiki.freepascal.org/Talk:How_to_use_a_TrayIcon#Linux_Problems
Now you have the revisions wrong. I guess you meant r61620 and r61621.
There are now other revisions affecting, namely r61758 and r61980. Maybe you should just list what the current trunk does and then plan for a more robust solution.

Quote
A wild card, how would you react to bringing out a new (Linux only) property for TrayIcon, allows the programmer to decide what is more important -
A property cannot be "Linux only" in a cross-platform component. It can be documented to have effect only on Linux though.

Quote
  • Unset, we'll do the default
Default means not to load any LibAppIndicator libs, right?

Quote
  • Prefer the OldSystemTray except where we know it won't work - Good choice when we want to handle LeftClicks.
This means to load LibAppIndicator (v1) lib, right?

Quote
  • Prefer the LibAppIndicator3 except where we know it won't work - Good choice is all we want is a popup menu.
This is the current situation. Not loaded for KDE and Cinnamon where it does not work.

Take your time and then please provide a patch for a robust solution with a new property. It is a new feature and will not be backported.

dbannon

  • Hero Member
  • *****
  • Posts: 774
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Problem with TrayIcon: mantis 35723
« Reply #12 on: October 05, 2019, 05:31:21 am »
OK Juha, I have made extensive (far too extensive) additions to https://wiki.freepascal.org/Talk:How_to_use_a_TrayIcon

It includes a summary of how we got here and some suggestions to a programmer intending to use TrayIcon. This probably needs to make it on to the main page. My raw data is also there and it needs to be enlarged with data from more distros but I think there is enough now for us to see whats happening.

....
What else does the issue depend on?
It is primarily about what the programmer wants to do. If they just want to popup a menu its quite a different solution from someone who wants to get a LeftClick handler called. Further complicated by potential to use (eg) TopIconsPlus to force new Gnome system to do a real SystemTray. Messy install will make many end users uncomfortable.

Quote
You should update the wiki page:
 https://wiki.freepascal.org/Talk:How_to_use_a_TrayIcon#Linux_Problems
Now you have the revisions wrong. I guess you meant r61620 and r61621.

61820 and 61821 is the change that prevents loading LibAppIndicator3.  I understand you have made changes since then but people like me need to wait until those changes make it int at least Fixes. Trunk is a bit too scary for people trying to make production quality software.
Quote
....
Take your time and then please provide a patch for a robust solution with a new property. It is a new feature and will not be backported.

Yeah, will involve some work. Have to decide if its justified given that this whole approach is wrong, maybe we need to put what ever effort is available into AppNotifier ?  Personally, I'm happy to manually edit UnityWSCrls.inc but thats an unproffesional approach. And it means apps like mine cannot make it into any repository that needs a source build.

We'll see !
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3647
  • I like bugs.
Re: Problem with TrayIcon: mantis 35723
« Reply #13 on: October 05, 2019, 08:39:53 am »
61820 and 61821 is the change that prevents loading LibAppIndicator3.  I understand you have made changes since then but people like me need to wait until those changes make it int at least Fixes. Trunk is a bit too scary for people trying to make production quality software.
Ok, r61821 merged trunk revision 61758 into fixes_2_0 branch.
r61820 is an unrelated revision in trunk:
 "Translations: Slovak translation update by LacaK, bug 36050"
All branches in the Subversion server share the same number space.

Trunk r61621 (issue #35723) was merged to fixes branch in r61634, together with 4 other trunk revisions.

Your wiki page says:
Quote
In this section, '820' means using Lazarus Fixes_2_0 release 81620 or earlier. '821' means 61821 or later up to a (soon) future release that tidies up this issue. Confused ?
Yes, it is partly wrong and very confusing. The fixes branch will become release 2.0.6 soon, maybe end of this month. You should refer to it instead of the merged revisions. The latest KDE/Cinnamon commit will be merged soon.

BTW, the wiki page talks about "Linux Problems" while actually the problems are with GTK2 bindings on Linux. UnityWSCtrls.pas is part of LCL-GTK2 binding code.
With QT(5) bindings everything works fine at least here. You could test it with your distros, too.

I still don't understand what makes the differences between distros that use the same desktop system, but I guess nobody does.
My common sense says that a desktop system + LibAppIndicator3 determine the behavior but apparently not.
« Last Edit: October 05, 2019, 09:32:25 am by JuhaManninen »

dbannon

  • Hero Member
  • *****
  • Posts: 774
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Problem with TrayIcon: mantis 35723
« Reply #14 on: October 05, 2019, 01:26:44 pm »
Ok, r61821 merged trunk revision 61758 into fixes_2_0 branch. r61820 is an unrelated revision in trunk:
Yes, of course, I was thinking how I isolated (what I saw as) the problem, it was not there in r61820, was there in r61821. Very careless wording on my part, will correct.

Quote
The fixes branch will become release 2.0.6 soon, maybe end of this month. You should refer to it instead of the merged revisions. The latest KDE/Cinnamon commit will be merged soon.

That I don't understand. "You should refer to it ..." - how do I refer to "it" without using revision numbers ? 

Quote
qt ?

I have, some time ago, tested against the QT libraries, from memory the results I achieved where disappointing, but I know a bit more  about the issue now, time I repeated those tests I guess. Yes, I agree, problem should be restricted to GTK.

Quote
I still don't understand what makes the differences between distros that use the same desktop system, but I guess nobody does.
My common sense says that a desktop system + LibAppIndicator3 determine the behavior but apparently not.
Most integrate their own ideas into a Desktop, Ubuntu for example add what ever is needed to make it work with libappindicator3. Redhat, because it works so close to Gnome, don't change as much. From memory, there is no libappindicator3 in the Redhat repositories. The Gnome Extensions, TopIcons* fill that role.

Davo
« Last Edit: October 05, 2019, 01:29:33 pm by dbannon »
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng