Un-register an LCL Component ?

[dbannon]

As near as I can tell, its not possible to unregister a component after it has been registered. Please tell me I am wrong.

TTrayIcon can be created in one of two different modes on GTK2 Linux, its determined at Registration time. As some modes work with some Distro/Desktop combinations, it would be cool to try one, get an AV, try the other. But once one is registered, LCL always goes to the original.

I looked in WSLCLClasses and found the list of registered components but the list is private and the search functions available return details of the component, not the node in the list.

There is a 'DestroyReference' method but its virtual and unimplemented.

Any advice ?

Davo

[dbannon]

OK, I guess I have to admit defeat here. I added a procedure to WSLCLClasses that allowed me to remove an entry from WSClassesList list but the creation of a new TrayIcon (in the other mode) still bypasses the registration process, clearly still using information about the first TrayIcon and generating an AV.

To do this properly would, I suspect involve dropping the "two mode" approach and making two distinguishable Components that would not interfere with each other.

While I might do that, its definitely not going to happen before release of Lazarus 3.0

Davo

[JuhaManninen]

TTrayIcon can be created in one of two different modes on GTK2 Linux, its determined at Registration time. As some modes work with some Distro/Desktop combinations, it would be cool to try one, get an AV, try the other. But once one is registered, LCL always goes to the original.

Would it be possible to delay the checks for a later time (first usage maybe) and then use a try ... except block?
Then you would integrate all code from TUnityWSCustomTrayIcon into TGtk2WSCustomTrayIcon.
This would have an extra benefit of not spending time for loading libraries etc. for applications that do not use a TrayIcon.

Anyway this must happen in "main" branch. Lazarus 3.0 should be released already. I don't know why it isn't.

[dbannon]

Thanks Juha. Registration happens component.create() stage. So, its impossible to do sufficient testing before that happens. And once registered, it stays registered. In terms of 'delays', decisions need to be made before the mainform.create() if using the object inspector but creating the TrayIcon dynamically lets you do it whenever you like.

I do have code that, for example, checks for the presence of and attempts to load the libayatana library and I use that in my own app but its too maintenance intensive to ship with Lazarus.

And now that I find in every 32bit linux system I have tested, loading Libayatana is fine, trying to display an icon triggers a Access Violation. While easy to catch that AV, its far too late to prevent registration so cannot try the alternative mode.

I have built a new component, TOldTrayIcon and if the default one AVs, its possible to call TOldTrayIcon.Create and get just the old one without any tests for libayatana. It works and I'm testing right now one a wide range of platforms but its  79 changed lines.

Like you, I'd like to see Lazarus 3.0 released. But with the deb package broken in RC2 and apparently no fix yet, seems a problem. I'd like to get my first, simplified patch in (or the 79 liner!) but the good stuff in 3.0, particularly with Qt5 and Qt6 is more important to me.

David
 

[JuhaManninen]

And now that I find in every 32bit linux system I have tested, loading Libayatana is fine, trying to display an icon triggers a Access Violation. While easy to catch that AV, its far too late to prevent registration so cannot try the alternative mode.

Why would you need different components for loading different dynamic libraries?
Use boolean flags or similar to keep track of what works and what does not in the specific system.
If using Libayatana triggers Access Violation, set a flag LibayatanaOK := False; and then use another way to show an icon.
There is also function SafeLoadLibrary() available. It is used in some places in Lazarus sources.

[dbannon]

Why would you need different components for loading different dynamic libraries?

Because they are, effectively different Components, think of it as an overload if you like.

When the TTrayIcon is registered, a whole lots initialization is done in the Unity module. And only done once of course. But once it is done, any attempt to create a new TTrayIcon reuses the existing "template" (for lack of a better expression). I don't see any other Component do that.

There is also function SafeLoadLibrary() available. It is used in some places in Lazarus sources.

No, the particular problem is not with loading the library, the Unity module does a good job of loading and seeing if everything it needs is there. The AV shows up much later when TTrayIcon.Show() is called. The AV is happening inside the Ayatana library. I have reported it but no response. I suspect 32bit problems may not have a high priority these days.

Anyway, lets cut to the chase. I have prepared and tested to death the very simple version my idea, all it does is bring out a Global Var from Unity that the programmer can play with at run time. A couple of changed lines in gtk2wsfactory to make the TrayIcon registration dependent on that Var. It does not make the problem go away but makes it manageable for those who care enough to do so.

I'll post that patch and a tiny demo project later today (to bugs) and will, time permitting spend more trying to understand that issue of how Unity's initialization locks in the Unity TrayIcon.  Overall, I think a complete redo of that module is needed, its called "Unity" because it was built to work with that terrible Unity Desktop, I believe Ayatana  and KSI have evolved the API a lot since then, maybe there some "hey, I'm working" signals we can get back now ?

David

[dbannon]

OK, posted my bug report, details, patch and demo app.

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40629

Davo

[JuhaManninen]

OK, posted my bug report, details, patch and demo app.
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40629

Thanks. Will be merged to 3.0 as well.

[dbannon]

Thanks Juha, thats good progress.
I will document how to use it on the wiki and speak to Don about getting detail into official docs.

David