The StatusIcon protocol for the XApp is an unnecessary overwork and a divergent project.

[lestcape]

Is there any special reason of why is needed a new API, or is just because it's fun have something different? With this, the shell programmer of other environments will need to be worried about the new XApp implementation and i think this is not fun then. If i understand correctly the XApp idea was to provide a commons place for programmers to not duplicate the work just because they want to target a different Human Interface Guidelines (HIG) and that is always good. But the new protocol seem to be the opposite of the initial idea. Here I think that is adding more work and is creating a different philosophy to be worried about. So, in my opinion this is NOT NICE!

What is the idea of add another protocol to Linux? Can not be used some current API and avoid the overwork? I think that this new protocol create an overwork in the client side (the application) and in the server side (the shell that want to support the new protocol for the XApp).

In the server side:
In the server side the are alternatives like the ApplicationIndicators that resolve the problems that have the StatusIcon implementation of Gtk. Why don't use it then?

Also there are people in GNOME trying to find with the KDE people an unify mechanism that not add more overwork to Linux (https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014). Maybe the best idea is join to that initiative and all together find the best thing to do for all sides?

In the client side:
Create another specific API for the XApp seem to be not to much problematic as could be the case of the server side. This is because the problem here will reside in the specific programmer that want to use the new API only. Anyway, this seem to be also unnecessary, because can be used the same API of Gtk.StatusIcon and behind the scene implement a different behaviour that resolve that problematic. This have the advantage that can be apply to all applications, also if they are not an XApp and it can be complete transparent and platform specific. So, if the platform want that behaviour it can be used it, but if not, the current behaviour will be continues applying to all app, so the standard Gtk.StatusIcon, will continues be working.

The idea can be implemented changing the Gtk implementation (the Gtk.StatusIcon implementation) in the environment where this is need (example: The LinuxMint distribution). Another alternative is the creation of a GtkModule to internally override in execution time the Gtk.StatusIcon implementation. Also another way more that also work on real time is hack the Gtk application launch environment and modifying the LD_PRELOAD environment variable in that launch context with the path of some shared library, as that library will be loaded before any other library, for example:

$ LD_PRELOAD=/path/to/my/gtkStatusIconImplementation.so

Read more info here.

All in all:
There are alternatives like add a patch to Gtk and intercept all calls to create a Gtk.StatusIcon and then convert it in an instance of an AppIndicator behind the scene, without a developer intervention. If you don't want to modify Gtk, you can also launch your application in an environment where you can modify the call to the Gtk library in real time and also convert it to a AppIndicator API.

I hope this help to find a better way than create more divergence in Linux.

[clefebvre]

Every new project is a lot of work. You make it sound like we're only doing this for fun. If we invest time and resources into doing this it's because we need it. It's because we're not happy with the current alternatives and we don't want to use them.

Gtk.StatusIcon is broken by design:

• 16px blurry icons in HiDPI
• resizing issues, some icons scale others don't.
• rendering issues, cropping, missing icons if the client app lags a little bit.. it's a real mess.
• relies on Gtk.Plug/Socket which are getting killed by GNOME

AppIndicator tackles some of these issues but it is also broken by design:

• missing functionality (you can't change the icon, you can't activate the app etc... I mean seriously)
• relies on dbus-menu to serialize Gtk menus (that means you're limited in terms of what you can do.. say you need a custom widget in your menu)

We needed something:

• That exists (I'm glad GNOME is thinking about it, but they don't really care about stuff like that, there's no place for it in Shell, Gtk.StatusIcon never evolved in GTK3, they will kill it, they probably don't even know what we're doing here and I'm not sure it's something they need on their side)
• That is actively maintained (libappindicator and dbus-menu are not)
• That looks good in HiDPI (Gtk.StatusIcon doesn't)
• That lets applications do what they need (libappindicator and dbus-menu drastically restrict what an app can do with Gtk.StatusIcon. We're not even doing advanced stuff, yet even in our simple use cases we find libappindicator to be a problem in that regard)

The technology behind all of this is also quite simple. Look at the use case.. an app wants to show an icon, a tooltip and handle click events on it. It's extremely simple. There's no excuse for this not to work after so many years. Why do you want us to use broken stuff we're not happy with? We've had access to Gtk.StatusIcon and libAppIndicator for years, we've been using both for years also, and what's the net result?

• Broken tray icons since the start of Cinnamon
• indicator support so bad (and I'm not judging your work here lestcape, it's not the support which is bad, you did an awesome job on this, it's the lib behind it) we actually get better results with the Gtk fallback and ship with support disabled by default.

Cinnamon is a really good DE, among the few things which really aren't working well enough is the tray. It's just not good enough. I'm glad we're tackling it. I don't really care if this is seen as a new standard or not, it's a solution which works right now. If GNOME wants to like it, they'll like it. If they want to to fork it, they'll fork it (and we might switch to theirs then, who cares), if they don't really care, well they don't really care. In the meantime we'll have crisp and well rendered icons, thank you very much.

[lestcape]

I think the issue met the objective of reporting, is fine if is closed then. But i think that you throw a lot of ideas about AppIndicator that have not foundation in my opinion. Also, I'm not only critique the selected way, I also propose an alternative that i think is perfectly fine and also it cover a lot more of what can resolve that new protocol that was create. But anyway, please don't feel forced to respond, the issue is closed to me, as it won't fix.

I can only reiterate my discontent with that and outside here I will promote the non-use of a single-sided protocol like this, because as i say it create divergence on Linux as a whole. This is because I'm only in favor of Linux, not in favor of an specific distribution, environment or anything else that is a subset of Linux.

Every new project is a lot of work. You make it sound like we're only doing this for fun.

Ohh no, sorry... All I make for Linux is for fun and you know that, so... Anyway, I think is clear in my message that this is not the intention. Make something different = FUN, that is a commons place for programmer always. So, this is not any particular thing against anyone here.

Gtk.StatusIcon is broken by design

Nothing to add, this is fully true.

AppIndicator tackles some of these issues but it is also broken by design

In my opinion this is fully false. This is only what GNOME will always said to all things that they not make by them self. Some one in KDE is thinking that some how this can be true? The KDE people was who create the protocol. They could be interesting to know your personal opinion to grow up and make the things better. Also the Ubuntu developers have a different opinion, they like and use that protocol in all desktops.

missing functionality (you can't change the icon, you can't activate the app etc... I mean seriously)

The implementation of AppIndicator that Cinnamon use need a fix if this is the case. This not seem to be a problem in the specification of the AppIndicators, so it can be fixed. I will see if i can help in that part, regardless of this currently issue.

relies on dbus-menu to serialize Gtk menus (that means you're limited in terms of what you can do.. say you need a custom widget in your menu)

Well this is not a bug, is a conception problem. Anyway i will seriously recommended you to avoid the usage of custom widgets in your menus, because Gtk have a plan to deprecate the GtkMenu API and fully swap to the GMenu model. When this will landing, you will have also not the chance to create a custom widget in the menu...

That is actively maintained (libappindicator and dbus-menu are not)

StatusNotifierItem (AppIndicator) is a freedesktop (cross desk) specification make by KDE, is not something that can or not be "actively maintained". One implementation outside the KDE desktop is the ubuntu one and this one is actively.

dbus-menu is another specification. How you pretend that an specification will be "actively maintained"? Sorry, but i don't understand you point then, because what i understand is impossible, because change the specification means break the API and the ABI. The implementation of that specification IS ACTIVE MAINTAINED, by Ubuntu, by KDE, by MATE and by all desktop that already use that specification to create a Global Menu or to use an AppIndicator. I don't want to mention the number of project that already use and maintained the dbus-menu, because is huge, but here another from the creators called kwin.

That lets applications do what they need (libappindicator and dbus-menu drastically restrict)...

This is impossible if you want a cross desktop/cross gui toolkit implementation. But you can add more things if you considered it needed and you can convince "freedesktop" (the huge amount of users that use the current specification of KDE) about it.

Why do you want us to use broken stuff we're not happy with?

No at all, like anything else i want that broken stuff will be fixed... But i don't see a broken specification here. I only can see a broken implementation in any case. Fix the implementation without change the specification is a perfectly fine and is something that any client of the AppIndicator can do without create a divergence in the specification or create a new unnecessary protocol. Again, i have not any problem with fix things.

We've had access to Gtk.StatusIcon and libAppIndicator for years, we've been using both for years also, and what's the net result?

I'm not talking of the implementation here. You are really free to change the implementation and not one will be affected because of that. If you change the specification or create a new one is when a lot of peoples can be affected. In fact the real question is why you has not intervened before. The AppIndicator code of Cinnamon seem untouched in years. How you pretend that things will be fixed in that way?

Cinnamon is a really good DE, among the few things which really aren't working well enough is the tray.

Fully agree... I will add to this just the fact that use only one thread (performance), but nothing more.

If GNOME wants to like it, they'll like it. If they want to to fork it, they'll fork it (and we might switch to theirs then, who cares), if they don't really care, well they don't really care. In the meantime we'll have crisp and well rendered icons, thank you very much.

I don' t care what GNOME want. I care about to have a good Linux system, where all applications that come from whatever place can be integrate good in the environment that we as a user select. This was the promises of the XApps some time ago. But apparently and unfortunate this is not anymore in that way... As we all can read here.

Finally but not less important, probably I do not explain things properly before or you don't understand me. In my comment, the intention was to propose a way to have a way to integrate ALL application in a good way in the environment. What you have right now is ONLY a way to integrate the XApps in a good way in the environment. But the question will be how many XApp there are in comparative with the whole Gtk application ecosystem? Just think it about, you resolved the problem of the XApp, but what you win with that? A lot of effort and just now 10 applications are working good? My target was try to resolve much more than that, but with much more less effort and reusing a cross specification protocol.

[clefebvre]

This is because I'm only in favor of Linux, not in favor of an specific distribution, environment or anything else that is a subset of Linux.

This is an Xapp project. It works everywhere, in any distribution, any environment and any application. Using it is a breeze and it gives the same functionality as Gtk.StatusIcon. Making an applet for it is also a breeze (there's a lib for that too), you don't need to mess with Dbus. We've got applets for MATE, Cinnamon and Xfce already. Any interested DE can implement this really easily.

libAppIndicator isn't an interesting solution. It's not just its implementation (which to be honest isn't bad at all), it's its feature-set which isn't interesting. It's a step down from what GTK provides.

GTK has the power to fix StatusIcon, to pull its backend away from Xembed and if they do it without breaking the client side API, they can fix this much better than anyone else involved. If you don't believe in people taking the initiative and working on something new (like we did here), then your main interlocutor and the people you need to work with are the GTK devs.

I think right now we're the only working solution but we're also the smallest and newest so yes, until other people realize what we did and find it interesting, this only solves things for a handful of apps. Get the GTK guys to fix StatusIcon and we'll be happy to drop this. If somebody else comes up with something better, we'll also consider dropping this and adopting it. We don't think like you, we want solutions and it really doesn't matter if they are ours, someone else's, if they're evolution of old or if they're brand new. Tingping mentioned he'd have a look if I'm not mistaken. We need stuff to work, I can't make this any clearer...

My advice is don't waste time with libAppIndicator and if GTK isn't interested, then come support us, or Tingping, or anyone else, or work on your own, I don't know... but be part of the solution, not the opposition force. We all care about the same problem apparently, so do give us a cheer for the awesome work we've already done here.

[lestcape]

libAppIndicator isn't an interesting solution. It's not just its implementation (which to be honest isn't bad at all), it's its feature-set which isn't interesting. It's a step down from what GTK provides.

I disagree. The AppIndicators are platform and toolkit independent and in my opinion this is the only way to go in Linux, because the number of different toolkits that Linux have. Any solution that involved a toolkit specific widget will look like out the place, like occurs with the XApp "solution". Also the Appindicator was implemented in more than one desktop, by more than one developer, what said something good about it.

your main interlocutor and the people you need to work with are the GTK devs.

I don't think so... The Gtk devs break more things. But that not means that creating a new protocol without agreeing with anyone is fine. In that specific case and apparently the Gtk devs are trying to speak and find a solution in a consensus, something that i can not see here.

I think right now we're the only working solution...

No, this is not what i see. The XApp solution is only good for Gtk desktops. Cinnamon, for example, is not one Gtk desktop. Build a Gtk menu in a Clutter desktop is to me just a mix of toolkits and then is nothing well done and specially is nothing nice. If you add that is something that was make without any consensus and that only can be used for the Gtk applications, all is worse then. Well this solution have then to me the same problem than the Gtk.StatusIcon, but only is worse, because not one external will really use it, at less i hope will be in that way.

Get the GTK guys to fix StatusIcon and we'll be happy to drop this.

Yes, this is another thing more to add to the problem, you can not promise stability or anything also... If people believe in this "solution" and port his applications, they will need to port it again in the future if Gtk make something new, as they already promise.

My advice is don't waste time with libAppIndicator...

My advice is don't waste time reinventing the wheel. You use Gtk, you use Clutter and you are not creating any toolkit... So, you should not add more divergence to the already splitted Linux desktop.

[clefebvre]

Cool lestcape. Then keep us in the loop of potential libAppIndicator improvements. I hope you manage to turn it into something good.

[lestcape]

I'm not the developer of anything, so i really can not change anything... I'm sorry if i have a different conceptions about what is needed as a solution.

Anyway, as the AppIndicator is used by Cinnamon already and as you know that it have problems. I think is good if you can write in a issue (in Cinnamon or here), with the deficiency that you notice with the Appindicator protocol. I think that this will help to understand the problematic and then some one can try to find a solution to the specific things you notice. There are not software without a problem and also some one can see a problem where others can not. For that reason the issues session exist in git, to help us to be organized. That is also the reason of why i opened an issue here, to express and shared what i think about that. I do not need to have the reason to do that, just i need to have a different idea. But i need to express it or otherwise is really nothing.

I agree in some of the problems that you notice with AppIndicator and i also have probably more inconvenient than you (but in general i think this is the way to go). To help, i will shared my perception (but i think it will not help in a closed and hide issue like this one):

1. The Appindicator protocol can not warranty a result. The actions on click are suggested to the client, but not imposed and that cause an arbitrary behaviours between applications. It can be fixed in the implementation, forcing a default action instead of suggest one to the client. But please note that Gtk is moving on to have client side app as a whole and in a client side applications the decisions model is delegate the things to the client. The referencing protocols are the global menu for appmenu and menubar, where the decision of export something or not is in the side of the client in Gtk, while is in the side of the shell in Qt. Also note that to do a default action, we need to know about the client specifications and this is impossible in the Wayland protocol, because the clients are isolate and there are not a common API like occurs in X11. So, probably the only solution reside in to have one client implementation per toolkit and not one implementation to all applications not matter the toolkit.

2. In the DBusMenu protocol, build a menu from a serialization have a performance implication that can be notice (flickering) in a shell with a monolithic process architecture like is gnome-shell and Cinnamon. It can not be notice in desktops with a multi-process architecture. It also can be improved, forcing an update when the mouse hovered a menuitems, to anticipate the action, and then avoid that the user can notice the update (The popup menu of Nemo have a similar problem also. It can change depending of the items that was clicked and it can be notice by the user as a flickering).

3. The AppIndicator is not a really unify protocol, because GNOME reused to use it.

4. The AppIndicator protocol don't assumed the possibility of have different orientation in the panel (vertical orientations). So, with some not homogeneous images it can look like really wrong (example: indicator-multiload).

5. The Appindicator protocol can send an image as streams with an encode that is not specify in the protocol. The stream that Qt app can send have the problem that Cairo have not support for it: https://gitlab.gnome.org/GNOME/gjs/issues/220. Lucky to us ClutterImage have support for it.

6. In the DBusMenu protocol we can not serialized custom widgets and then it have not space for custom behaviours (This is not a problem to me, but was already mention by you). It is not to much problematic, because already KDE, Qt, GNOME and Gtk are moving to have menus that can be serialized (that means, not custom menus).

7. The AppIndicator have not strong implementations. So, some clients use the Dbus menu API, when they should not used that API directly and instead they should used a well done client API that expose in a good and easy way the functionality to the clients (The clients should never use DBus directly or know anything about DBus).

[clefebvre]

1. Yes. That's something we didn't need. That said, it can be easily added. If there's interest for this in libxapp, we can talk about it and add it. The reasons we didn't add it were that, first, we asssumed it would always work (we fallback to Gtk.StatusIcon which all the DEs we target support), and second we noticed the apps which cause the most problems are apps which are too smart for their own good (ibus comes to mind)... apps which try to identify the DE or the presence of listeners/applets and wrongly assume they should act this way or that way. In practice we find the DE knows best how to show the information and the app knows best what to show and how to react to user events. That's definitely a topic which is open though. @TingPing had a similar comment and was looking at this as an issue when it came to particular use cases such as flatpak. From a technical point of view, this is something that is easy to add. We already have a mechanism in place for the lib itself to know if the DE is listening. We could let the app know, we could even make the fallback mechanism configurable. If there's interest we just need to discuss.

2. Absolutely. That's one of the reasons we prefer client-side event handling (i.e. for the app to show the menu and react to clicks). I would assume GNOME Shell has the same problem as Cinnamon here, it's single-threaded so anything handled outside of it is interesting in terms of performance. We're actually considering retiring some JS core applets and turning them into external statusicon apps. We didn't work on statusicons for this reason, but it could be interesting to use them like that as well in Cinnamon. Now, with that said, the main reason we prefer app-rendered menus is to empower the app. I know you said GMenu wouldn't allow as much in the future, and you have a point about custom widgets, but it's not just that.. an empowered app really controls user events. It can decide to change the menu dynamically, it can decide to interact on say mouse button number 8 on your gaming mouse.. it can do all sorts of things the applet can't predict.

3. I think Ubuntu was ahead of its time and identified the issues with Gtk.StatusIcon very early. So what they came up with was the only solution for many people to get crisp icons and native DE menus (which although they cause a performance issue, look native.. there's both pros and cons associated to this).

4. I didn't know about that. My main issues with it are: 1. it doesn't let you activate the app on left click, 2. it doesn't let you change the icon reliably, 3. menus are rendered by the applet, 4. the app can't handle click events the way it wants, 5. it's implemented differently on different DEs.

5. It's not just menus though.. say I make a timer. I show a label which counts time, when you middle-click it I want to stop the timer. If I'm the app, I know how I want to react to click events, if I'm the applet any attempt at guessing that restrict the app in what it can do.

6. That's because libAppIndicator is tiny, it's only an API for apps, there's nothing there for applets. If you want to write your applet you need to handle DBUS calls, basically write your own StatusNotifier listener, so no wonder they're all different. On the client side, afaik, it's doing a good job.. I'm yet to see an app which taps into DBUS directly.

[lestcape]

1. Yes. That's something we didn't need.

It can be the cause of confusion to the user, but to me is difficult asseverate that is a bug or not. I think is depending of the specific shell's targets. Your timer example is a good one to illustrate that a shell can want to target an application without a windows. So, we will have not windows to be presented as a default action in that case.

2. an empowered app really controls user events.

While you have a point, I think that this can open a discution about if the AppIndicators where the user perform a click are a shell widget or an application widget. In my opinion your consideration is that this is an application widget, but to me they are shell widgets and then the shell need to limited the application to do what the shell considered that is good.

3. there's both pros and cons associated to this

Sure, but behind that will resided the concept that you associate with an AppIndicator. Apparently you see it as an extension of an app, but I see it as a shell feature that are exposed to be used by the applications...

4. I didn't know about that.

If you are talking about the indicator-multiload example, this is because in Cinnamon there are not support for not homogeneous indicators like the indicator-multiload. In kde also there are not support for it and in the gnome-shell implementation of Ubuntu also there are not support. Only Unity have support for not homogeneous indicators right now. It can be added but then what we will do on a vertical panel implementation that Cinnamon have? Probably the only way will be rotate the actor 90 degrees. I asked about that but how this was unclear it was not be implemented finally.

4.1. it doesn't let you activate the app on left click

I don't understand. I think you can do whatever you want. In cinnamon i make a hide implementation to add the possibility to invert the Activate and the SecondaryActivate signal. This is not what you want? The implementation of that feature is here. Note: It won't work ok, because the protocol is incomplete.

4.2. it doesn't let you change the icon reliably,

I also don't understand what that means. This could be some how related with this? The indicator-multiload was working pretty good the last time i test it, with the code to scale the image. It works by constantly changing the image, so there is no better example than this.. There are something more broken in the implementation then?

4.3. menus are rendered by the applet,

Yes, to me this is good. The performance problem is caused by the shell architecture and this is a different bug, but also you can avoid that menu and use your own. The protocol allow also that, but only in the original implementation of KDE. This is a decision of the application that can be taking in the Active and SecondaryActive actions.

4.4. the app can't handle click events the way it wants,

I also don't understand this one. Why not? To me is what already occurs. There are two types of click events in the protocol Activate and SecondaryActivate, both can be delegate to the application if this is what you want, but the Activate is not implemented in the AppIndicator of Ubuntu it need to be include, see the next comment.

5.5. it's implemented differently on different DEs.

Yes, but that is a problem more big than just the indicators... DE always decide what they want to implemented. They also can decide not include the XApp or just change his implementation.

6. It's not just menus though.. say I make a timer.

Yes, again you see the AppIndicators as an extension of a app. This is not the way i personally see it. Anyway the Activate and SecondaryActivate actions are delegate to the application in the KDE original protocol. Nothing say that all applications will need to implement the same behaviours. You can also open an app menu with another toolkit if this is what you want. Activate and SecondaryActivate actions are sending also the mouse coordinate, so you can opened the menu properly if you used that coordinate in the same way that you implemented it for the XApp. In fact you should get the same result.

7. On the client side, afaik, it's doing a good job.. I'm yet to see an app which taps into DBUS directly.

Well, this bug is caused by two type of applications. One are the apps that come from Qt and the another are the apps that implemented his own way to interact with the protocol. This also occurs in Cinnamon as is not fixed yet. The Ubuntu solution was to traverse dbus and filter objects and find the applications that are not observed the DBus interface and then forced it to be reconnected with the protocol. Also please see the next comment, nothing is really good in the implementation, just the opposite in my opinion.

[lestcape]

I have taken a while today to explore a little what it's happening and well, there are a lot of important things that are not in the place they should be...

This are important examples:

• There are a SecondaryActivate signal, but the primary Activate signal is missing. It need to be something like this patch on Arch.

• So, Cinnamon not used the Activate signal, because that signal is missing in Ubuntu. Instead the default behaviour is open the indicator menu.

• In the Ubuntu AppIndicator client they implemented this code, that is supposed that controlled the indicator but is never executed, because the indicator was implemented using a shell PanelMenu.Button and this component in a button press will forced the menu to be toggled not matter what.

I think it's difficult to evaluate in that condition something. The most important action is missing and the Ubuntu implementation is working in a complete different way of what was implemented. I'm wondering if they know about that...

There are something more broken. When i activate the AppIndicator in Cinnamon my computer experimented a big slowdown. This was not happening before it's really noticeable.

[clefebvre]

xapp_status_icon_any_monitors() was added to libxapp. It returns TRUE if applets are running, FALSE otherwise.

I still don't think apps should second-guess the environment, but you never know, in niche cases (you mentioned the windowless timer for instance), it could be useful.

[lestcape]

I still don't think apps should second-guess the environment, but you never know, in niche cases (you mentioned the windowless timer for instance), it could be useful.

Yes, probably it could be useful in some scenarios, but search in all DBus for this, is not to much? That question is the equivalent of: Can you have more than one monitor running at same time in the environment? A transverse Dbus to search it's useful to find client interfaces from the server side, but the usage of this to find the server from the client side is something unusual for me.

[clefebvre]

Yes, you can have multiple monitors running. If for instance you wanted to have a systray on each monitor (using two panels for instance) or if you wanted to have a tray using a different implementation (a GTK dock for instance)... This also opens the door to DEs showing partial info, or showing it in other ways (in the menu, in overview.. who knows). If we were to add a type/role field, you could envision some monitors dedicated to particular roles.

It also opens the door to apps monitoring other apps.. although here, we're going a bit too far into the rabbit hole. I can't imagine a useful use case yet and if we were interested in this, we'd probably want to distinguish between programmatical status info, and the status info we want to show to the user.

Another aspect was to keep things simple and not engage in race conditions. We wanted the info to be available whether or not the DE was fully loaded, whether or not it crashed, whether or not it took time to load, whether or not the app got launched before it... etc.. Basically, the app provides its info and moves on. Monitors render all information, whether that info was provided before or after they themselves launched isn't relevant.

Now, with that said, during the implementation we also worked on fallback mechanisms and we wanted these to be dynamic. So when/if all monitors die, we want all info to be thrown towards the xembed tray. When any monitor comes back up, we want it back.

That works really well as long as the app isn't too smart for its own good. If all it does is provide info, we can handle all of that. If it starts to check things and second guess the environment (like ibus does), it defeats our ability to properly direct its info towards the right place, and we then rely on whether or not it itself is properly handling all these cases (and ibus isn't for instance).

I didn't look into the ibus code yet. appindicator provides a fallback mechanism towards xembed. What I think is happening, is that ibus has its own detection mechanism to see if there is an appindicator monitor and if there isn't, it provides its own fallback towards xembed. Basically, that's something appindicator does, and which the app shouldn't worry about. By doing this, it misses the opportunity to be handled by the lib. In our case, it's missing the opportunity to be rendered by xapp and it's one of the very few apps which forces its way straight into a blurry xembed.

[TingPing]

So when/if all monitors die, we want all info to be thrown towards the xembed tray.

That is an assumption itself, an XEmbed tray may not exist, may disappear, etc.

[clefebvre]

@TingPing Indeed, that's an assumption apps, libappindicator and libxapp all make. It's the responsibility of the DE, and the distribution which configures it for its users, to ship with at the very least an Xembed tray (and while I say that, I know it's not always true on minimalistic DEs, or the latest versions of Plasma).

Neither libappindicator nor libxapp check for that at the moment, they just blindly delegate to Gtk.StatusIcon (which itself doesn't really care).

I know you're worrying about uses cases which we don't necessarily think about. You're running software inside containers. There are layers between the environment and the contained app which you need to take into account. We're probably able to make the fallback configurable, either by users, or by the app itself, we could probably also tell the app if the fallback is used, and if it fails. We haven't seen the need for this yet, but if there is one, it can be added.