Ah, thanks Mario. I tested against so many Distros, I did not even know that Ubuntu made a Cinnamon one. What is it called ?
Mario, can you please tell me if it has libappindicator.so or libappindicator3.so installed ?
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?
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)
When you say r61758 in 0035983 solved the issue on my Manjaro Linux with KDE". what problem ?No, the System Tray also needs to call its OnClick handler when left-clicked.
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.Ahh, finally I understand.
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?
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 importantPerhaps a setting for the target desktop environment would be more self explanatory. Different fall-back mechanisms still could be possible.
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.
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.
Default means not to load any LibAppIndicator libs, right?
- Unset, we'll do the default
This means to load LibAppIndicator (v1) lib, right?
- Prefer the OldSystemTray except where we know it won't work - Good choice when we want to handle LeftClicks.
This is the current situation. Not loaded for KDE and Cinnamon where it does not work.
- Prefer the LibAppIndicator3 except where we know it won't work - Good choice is all we want is a popup menu.
....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.
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.
....
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.
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.
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.
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.
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.
qt ?
I still don't understand what makes the differences between distros that use the same desktop system, but I guess nobody does.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.
My common sense says that a desktop system + LibAppIndicator3 determine the behavior but apparently not.
That I don't understand. "You should refer to it ..." - how do I refer to "it" without using revision numbers ?Just explain that Lazarus 2.0.6 behaves so and so compared to earlier versions like 2.0.4 and 2.0.2 etc.
OK, Juha, here is my suggestion, have a look at it and see if you want me to make a patch.Ok, I committed a modified version in r62003. Will be merged to 2.0.6.
Add this function within "function UnityAppIndicatorInit: Boolean;" As a seperate function its easy to add more exceptions, as I am sure we will need to -
...
Sure. Should a new patch be based onNo, the trunk branch in svn.freepascal.org server is the master where all commits go. Graeme's GitHub mirror follows it with a small delay (15 minutes or something).
https://svn.freepascal.org/svn/lazarus/trunk/lcl/interfaces/gtk2/unitywsctrls.pas
which does not show the most recent patch or on
https://github.com/graemeg/lazarus/blob/upstream/lcl/interfaces/gtk2/unitywsctrls.pas
which does incorporate the recent patch.
Sorry, I do not understand the process ....You should concentrate on trunk when testing changes from other people or when creating patches yourself. The development always happens in trunk.
Are we making any progress here ? Be really nice to get this fixed in 2.0.6.It will be there. See:
And I am still puzzled as to where the authoritative 'trunk' version is.Yes trunk is there:
https://svn.freepascal.org/svn/lazarus/trunk/lcl/interfaces/gtk2/unitywsctrls.pas
has Juha's 'fix kde and Cinnamon only' fix from several weeks ago. But Graham's github has my suggested "fix em all as best we can" model and has had it for several days. The real trunk should always be fresher than Graham's but that does not appear to be the case.
Am I looking at the wrong svn server for trunk ? If I checked out trunk with SVN, would I get Juha's, mine or one of Alex's version ?
Ahh sorry, missed one.I added it in r62020. Will be merged.
We have to add 'Debian' to the list of distros whose Gnome requires us to load the libappindicator3.
So, the list is now 'mageia', 'Red Hat', 'SUSE', 'Debian'
So, I was looking at the 'wrong' trunk ! I will bookmark the right one and sure won't make that mistake again !No, you looked at the right trunk but your web browser had cached the file and showed an old version. Pressing F5 helps as I wrote.
I do struggle with svn, reasonably confident with git, use it for my own project, have used it professionally in the past. But I figure that svn is what FPC/Lazarus uses so I should make the effort.You can use Git if you prefer it, either through a Github mirror or through git-svn link. We take Git formatted patches, no problem.
But Github sure does make looking at revisions easier! Happy at the command line...No, Git makes looking at revisions easier. You confuse things. IMO Github is overrated. Doing a pull request there is no way easier than creating and uploading a patch.
I added it in r62020. Will be merged.Excellent !
I also optimized the code. /proc/version needs to be read only for Gnome.
BTW, has anybody tested how the TrayIcon works with GTK3 bindings? Our changes affect only GTK2 bindings.
No, you looked at the right trunk but your web browser had cached the file and showed an old version. Pressing F5 helps as I wrote.I had been pressing F5, made no diff. I just manually emptied my Firefox cache and now do see you most recent modes. Thats pretty strange. I'll trust what I see on github in future.
I am afraid that I have also found that Enlightenment should also be listed as a desktop that requires the LibAppIndicator3Don't be afraid. Just add it into your coming patch. :)
I am not sure what patches look like at the moment, Alex's suggestion is dependent on a separate patch providing a function to read the proc filesystem, complicationing the issue a bit. I would consider Juha r62020 best bet but it need another line referring to Enlightenment.No, Alex's suggestion does not complicate anything because it is not applied to trunk or anywhere. He is working on non-issues or "nothing-burgers" as Americans say, which is a little irritating when there are so many open bugs.
What is the best approach ? A new patch assuming r62020 is applied ...Assuming ... WTF! r62020 is already applied, that is why it has a revision number. It will even be merged to the fixes_2_0 branch.
... or a modified patch that extends 662020 ?That is far far future, maybe in year 22019. :)
I am getting so excited I am starting to stutter.Quote... or a modified patch that extends 662020 ?That is far far future, maybe in year 22019. :)
BTW, your environment variable LAZUSEAPPIND sounds like a good idea. If not found, the behavior would revert to what it does currently, thus making the change backwards compatible.OK, I am on it. I have been using that idea in my own app so its tested and found useful already. Will have that patch ready soon, I understand time is important right now ....
OK, I have posted my patch on https://bugs.freepascal.org/view.php?id=35723Thanks. In future please also reopen the issue. Then I will notice it for sure in Mantis. I would have missed it without this forum post.
EDIT: Note I have rearranged things a little, no point in doing file i/o if we don't need it, even /proc takes some time. And I have relocated the NeedAppIndicator function.NeedAppIndicator function is now nested inside UnityAppIndicatorInit although not using its parameters or local variables. As you know it imposes an extra frame pointer and a small performance penalty.
I did not know nesting a function like that incurred a performance penalty ! I did it like that to reduce its scope, sorry, next time, and I am certain there will be a next time, :-( I will pop it back outside again.
Hmm, I do that 'nesting' quite a lot in my own code, guess I should review that.
I have updated the wiki page to expose that env var.
Davo
There is no need for you to stop using nesting subroutines in your program. The performance penalty is minimal at least.AFAIK the extra frame pointer is comparable to a Self pointer in methods of classes. Some people avoid object oriented programming because of the overhead caused by it.
I have just, finally, got around to testing the newly released Ubuntu19.10 against the patches to keep TrayIcon going. I am afraid it too is now on the hit list of an distro that must be forced to use LibAppIndicator3.No need to hurry with that. Let's keep it in trunk. Then it will be in the next major version 2.2.0 at some day. The environment variable LAZUSEAPPIND can solve problematic cases now, right?
Right now I am guessing that the 'other' Ubuntus will be OK, but we really won't know until each one is individually tested. I will start now and post a patch to Mantis as soon as I can. If I can get it all together before 2.0.6, well and good, at least we have that debugging capability in there now that does allow us to override at run time.
The default install of Ubuntu also has a lot less GTK2 in there now too, creating a dependency problem for any Lazarus app. Fun eh ?GTK3 is the standard now. Even the desktop XFCE in version 4.14 got finally ported for it.