The StatusIcon protocol for the XApp is an unnecessary overwork and a divergent project. #1
Comments
|
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:
AppIndicator tackles some of these issues but it is also broken by design:
We needed something:
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?
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. |
|
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.
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.
Nothing to add, this is fully true.
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.
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.
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...
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.
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.
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.
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?
Fully agree... I will add to this just the fact that use only one thread (performance), but nothing more.
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. |
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. |
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.
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.
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.
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 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. |
|
Cool lestcape. Then keep us in the loop of potential libAppIndicator improvements. I hope you manage to turn it into something good. |
|
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):
|
|
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.
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.
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...
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.
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.
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?
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.
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.
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.
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.
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. |
|
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:
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. |
|
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. |
|
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. |
That is an assumption itself, an XEmbed tray may not exist, may disappear, etc. |
|
@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. |
This is something dark to me yet. I think this is not a strong reason to have more than one monitor. This is because it can resolved adding a Indicator Manager to the environment, like was added to Cinnamon in the AppIndicator implementation. The gnome-shell extension implementation (now the Ubuntu one) of AppIndicators have not an equivalent. The Indicator Manager work in the environment as intermediary between the applications and all the systray implementations. So, it receive all the applications information with just one DBus interface and then it can server to all systray what they wants with base on they specific requirements. So, have several DBus interfaces seem to be not necessary in this model. It's really necessary have a lot of monitors working on Dbus at same time in the XApps implementation? |
|
It's a simpler design, there's no service running between the two, and it gives us more flexibility. At the same time all the dbus side of things is handled by the lib, so apps and monitors don't worry about the inner workings of it. In fact, since the start of the implementation, the DBUS addressing already changed, from a unique icon per application to multiple ones, and that had no impact on the interfaces. |
|
I'm a bit rusty on MPRIS, but if I remember well it uses a similar design. |
|
Well, then please develop it. We don't understand the argument about the lack of features for instance (in our book Gtk.StatusIcon provides the features we want, AppIndicator does not). We don't really see the point made about name ownership. And last but not least, we'd want to understand what being "sandbox-friendly" means and how we can work on improving that. |
In my personal opinion the protocol exist and was develop by KDE, so there is not need to create it again. Is called StatusNotifier and here you have a partial implementation made by canonical. I disagree with @TingPing about see the Cannonical implementation as a new protocol. I see it as a variation of the StatusNotifier protocol only.
I think this is probably about of what you want to have. Also the problem could be that you are using the Cannonical implementation, not the KDE original one. Can you please mention what specific things that you want to have are not possible with the StatusNotifier protocol currently? It's difficult try to understand without to know what you want really. All that you have currently can be done with the StatusNotifier protocol, or at less i think it's in that way.
I want to know also. The linux sandboxing (the gnome one) is in develop and is difficult to know what possibility will be added and what possibility no. Sandboxing is isolate the application from the environment. In theory a well isolate application will have not access to any resources and if the application want access, it need to request that access explicit and the user need to agree with that. This is an example: If you force all apps to talk with your DBus interface (an external service), you will need to request that in an explicit way as occurs here, but if this option don't exist in the sandbox implementation the application is not "sandbox-friendly". So to create a "sandbox-friendly" applications you need that things:
Well i don't know the level of integration that @TingPing want in fact, but i think that the second point is not an option to him. In other words if you want integration you probably need to be a flatpak developer :( |
|
That is a very selfish line of reasoning. You very well know other big and noteworthy projects don't support the tray. |
Also that doesn't even make sense, Mint ships support for Flatpaks out of the box. Why would you not be thinking about them? |
|
To be honest, I don't believe you can implement StatusNotifier properly without libAppIndicator getting in the way. Look at Ayatana and the confusion it creates. In my opinion, if we want a functional StatusNotifier implementation, we need libAppIndicator to improve. If that's not enough (and I don't believe it is) we need something new entirely. |
It can be done with both kde and cannonical.
It can be done with both kde and cannonical.
The KDE implementation have two activation events that correspond to mouse click and the events send the mouse coordinate. So, you only can map two buttons. The canonical implementation have only one action.
The activation events have not semantic. So, you can associate the action you want in the client (the app) to show the menu1 for the activation1 and the menu2 for the activation2 without a problem. But have two menus will only be possible with the KDE protocol. One action is missing in the Cannonical protocol. So, you need to add it.
It can be done as the action is generic, but you have only two actions in the KDE implementation and one in the cannonical implementation. So, you can not show two menus and change the icons at same time.
Yes you can with KDE and also with the Ubuntu implementation. See it here.
No you can not, but you can proposed this to the KDE developers. The problem is when you have several systrays one in a vertical orientation and the another in an horizontal orientation. I have not idea how you will solve that problematic anyway.
The canonical implementation support it, but not the KDE one. I think this can be added to the KDE one.
Can be done with both implementation.
Can be done with both, but in the cannonical implementation only in one action as i mention before.
Can be done with both.
??? |
What I mean is you know more about containers than we do so maybe you can help. That's me trying to be nice, but you missed that. Of course we care, why do you think I ask you to explain? Can you move on to the part where you actually explain, and can we stop trying to get the last word? The only reason I provide answers here (to you too @lestcape) is to explain our choices and to learn what can be improved. I do not believe in the other solutions (StatusNotifier/libAppIndicator/Ayatana/GtkStatusIcon), you can talk about them and work on them if you want but you don't really need me for that. In https://blog.tingping.se/2019/09/07/how-to-design-a-modern-status-icon.html you raise many points. There's no point talking about the ones which are wrong. There's no point patting you on the back on the ones we agree on either. What's interesting and what you should develop, are the points which intrigue us and which we want to know more about. Namely, we don't understand what's at stake when it comes to being sandbox-friendly and we don't understand the point about name ownership. Don't get stuck on calling me selfish and questioning my motivation. There's no sarcasm involved here. I'm not here to waste time or jousting with you. Develop these aspects for us. You sound like you know what you're talking about, and we don't understand these two points. If we need to address them, we'd rather do it sooner than later. |
I wasn't "trying to get the last word". I was randomly pinged on a very long issue thread and kind of just left a quick comment.. which I didn't intend on doing since this probably isn't the best forum for such a discussion.
I agree with you there I think we need a new one and my post was just disappointed that the mistakes of the past were repeated. I'd love to help point the project in the right direction.
Flatpak (and Snap) does not grant applications the permission to own any DBus well known name outside of their app-id and sub-names. So for example
I don't want to fight but surely you understand that we cannot have a discussion about this new API in good faith when you start the discussion saying you do not care about all desktops without a tray. |
Yes, but i don't think that you need something entirely new, just for some missing details. I think is preferable evaluate what is more important to you:
There are things that to me are clear, a protocol with all feature you want can only be create by you and if you create your personal perfect project then this not means someone will prefer to use it or see it as perfect as you see it. |
Ok that's good. I'm sorry it sounded like this then and I didn't mean to say I didn't care. I do care. I don't think any lib can work for a developer if it only works on a handful of DEs. We made it easy to write monitors so that any DE could have support for this. When you mentioned the fact that we assumed it was enough to fallback to Gtk.StatusIcon, I agreed. We did make this assumption, and I'm sorry it sounded like this was sufficient and I didn't care. I think you successfully highlighted the need for the lib to report failure towards the app. Lestcape also highlighted that with the windowless timer example.. if nothing works, we need to tell the app so it can decide whether or not to show that information some other way.
Alright.. ok that makes sense. Could it own org.foo.Applications.StatusIcon? The DBUS layer is burried inside the library so in theory we can change this without any impact on apps, applets and APIs. |
|
@clefebvre You are not the only one that is working in a solution: https://github.com/AyatanaIndicators/ How many solution we will have? That is good to you? To me not, is not good. |
If name ownership is required yes that will work. There was other issues with your name ownership like including the PID in the name which is entirely broken in PID namespaces. Again though I don't believe a well known name is needed at all. The host side service will always have a unique name created at connection time since the service is designed where clients register themselves.
Indeed, this is a very solvable problem. Most of my other sandboxing concerns relate to if we want to expose this service in flatpak as a default portal if we consider it safe and sane. I think this is mostly a logistical question that I'd implement myself though as long as the API is designed in such a way that we can proxy the information along (we would do things like have a permission system that allows it being disallowed and we would have to ensure that no unsafe images get passed to the host service to be exploited). |
|
I think you're a very genuine and honest person. Sometimes you get idealistic and passionate and because English is neither my nor your native tongue we get a little bit mixed up. I understand your frustration but I have no solution for it. You're pointing at something human here, not technical. People form little groups and take initiative. If they're open minded they learn from each others and they're open to merges, adoptions or cooperation. I think we are. I don't think you'll ever get everyone at the same table agreeing on absolutely everything before writing the 1 unique and perfect standard the World needs. That's utopic in my opinion. You'll always need to make decisions which will divide slightly, you'll need to make calls which will be questionable. There will always be a better way to do something according to someone else. And that's perfectly OK, that's how we progress. I don't see initiative as a problem, quite the opposite. I see a problem which needs a solution and the more people work on it, whether that's together or not, the better. I'd rather have 10 solutions than none. When I see different projects working on fixing the same thing I don't think it's a waste of time, I think they can learn from one another and even if they don't merge, they'll progress together. I'd rather point the finger at people who aren't doing anything, than at people who are trying their own ways. Take Ayatana for instance. What good would I be if I joined their project? Would they be better off with me inside trying to veer it in a direction they don't want to take? I don't think so. And also, I'm not convinced they'll succeed, but maybe I'm wrong. It's not my place to demoralize them, quite the opposite. As a competitor project to solve the problem I care about, we're not at the stage where we should worry about adoption yet, I do want them to succeed. The better they do the more I can learn from them and vice versa. If they end up doing something excellent, then even better, we're done, problem solved. When you use the word "divergent" you use a word with negative connotations. When somebody forks something just to control it or take credit for it, with no particular goal and no new ideas, that's divergence to me. When somebody promotes a solution which isn't good for people and restricts their freedom just to get a strategical advantage that's divergence to me. When somebody promotes new alternatives for commercial reasons and drops them overnight the minute they're no longer financially interesting, that's careless, and that's divergence to me. I don't think we're like that. I do get your frustration and you're not the only one thinking there should only be one of this for this and one of that for that. I don't think the best way to solve a problem is working with people you disagree with though. I think the best way is to gather people who want the same thing and do it, and as new people arrive and challenge that vision, it's to take their feedback into account. And in that feedback you'll inevitably accept some parts and reject others... and if you're the only project in town, then what good is that? People are different and they want different things, that's why there's different DEs, different distros, different everything. Can we make a tray most people like? maybe. Can we make one everybody likes? hmm I'm not sure really... Can we come up with the perfect tray and satisfy everybody out there doing better just isn't possible? No, absolutely not. What we disagree on isn't technical, it's the idea of doing something new. And even if I agreed to work on improving the most promising solution rather than work on something new, we wouldn't agree anyway, because to me that's Gtk, and to you it isn't. I appreciate you being here and I do learn from it. I think every time we talk like this it challenges our assumptions and we can both improve and take a little bit back. But if just the two of us can't even agree on which already existing solution is the least broken, how can we expect to get everybody out there working on the same solution? |
|
@TingPing ok we'll work on letting the app know about failure to fallback, and using a suffix in the dbus name rather than a prefix (there's no registration against a central service here.. the app puts the info on dbus whether there's a monitor or not). I'll check to see if we need the PID.. I don't believe we do. I think we used that initially to guarantee the name was unique, but we moved on from this more or less and if we use your idea then we don't even need to do that. We'll make PRs or issues for this and ask you for feedback as we get closer. |
Hmm, I hand't looked at the host implementation yet; So the host service iterates all dbus names for trays? This does complicate the portal bit I was just mentioning. We have to have a permission system and ensure secure services (decoding images is always unsafe) and letting a sandboxed application own a name directly used by the host like that isn't good. |
|
Yes, typically the monitor would launch and look at what's on dbus, and if it has the right suffix (prefix in the current implementation), then it would be interested in it. |
I feel like thats very problematic in general, how can the application possibly know if a tray exists or not? |
|
xapp_status_icon_any_monitors() returns TRUE if there's at least one monitor. But it's not enough. You and letscape identified the need, in this discussion, to report failure to render towards the application. So we don't only care about monitors being there... we also care about the fallback being successful. If the fallback towards Xembed fails, we need to report it to the app, and that's something we need to add to the API and implementation. |
|
in other words, right now if this returns TRUE, you're OK. But if it returns FALSE you've no way of knowing if your info is successfully shown via Xembed or not. |
|
Inside of a sandbox you do not have permission to list all dbus names. So this design will not work out, it also means its not really possible to proxy through a portal. |
|
OK, so within flatpak, libxapp's xapp_status_icon_any_monitors() couldn't work then? |
|
wait, so MPRIS doesn't work with Flatpak? I'm all confused now. |
|
So you can explicitly add permissions like |
|
Yeah, the data is pretty flat and you don't really know who you're talking to. An applet can't predict which apps it will show status for, and apps can't predict which applets/monitors will render the status they provide. There can be many apps and many applets, it's a many to many design. |
|
To be fair though you're not really talking to anybody, you're getting strings (label, tooltip text, icon name) and sending click info. |
|
Divergence (as a mathematics terminology that it's) is the opposite of convergence. When two solutions have a divergence, that means to me that they don't come to the same point, not get the same result, they are not equivalents. The first solution is not the same as the second one. This is divergence to me. |
|
We started looking into flatpak and fallback report. Assuming
We'd also add a Regarding compatibility with Flatpak, our assumption right now is that it should already work, but always fallback to Xembed (since the Flatpak app is unable to scan the bus, it would assume no monitors are present). We can easily move from prefixes to suffixes to address the unique name ownership but there's something we don't understand. When running the Spotify Flaptak, we see this in DBUS:
That's using a prefix just like us and it seems to be working. To make apps able to see monitors in Flatpak (and thus to not fall into fallback) we'd need to talk to a unique name, so that the scan is done on the host. We can add that at a later stage and it won't affect the API (it would be used internally by |
Great 😄
Because its an explicit permission. Anyway the real problem is how you designed monitors. I can't imagine any solution where that will work. |
OK, so moving to suffixes will simplify the flatpak meta basically, the dev won't need to declare his statusicon dbus name. |
The app never calls anything on the monitor, the only thing it needs to know is if there are any monitors, so it can decide whether or not to fallback. It currently achieves that by scanning the bus names, but that's not possible in Flatpak, so instead, it'll ask a central service (which we need to add). Once that's done I don't see any other issue. |
Yeah, that will do.
Yes we want desktop integration to "just work". |
|
Say the app name is org.domain.AppName, am I right in saying it can own the following names without declaring them in its metadata?
|
|
@clefebvre I think that the names are right, but wait for TingPing. This should help anyway: |
|
All of those are valid, correct. |
|
State report is in linuxmint/xapp@b875ca3. |
|
Well, that is interesting now, you managed to get it working for more applications: linuxmint/xapp@0a27c6a and this is pretty nice. This was part of my point, just the way it was added it's not something i like, but for the performance point of view of Cinnamon this will work ok (i think). My original idea was the same thing but at the inverse. In my idea the StatusNotifierItem protocol of KDE was the main implementation instead of the XApp. The StatusNotifierItem it's more general than the XApp in his KDE version, just much more complicate to implemented fully. Opening a point apart of my preference: @mtwebster Probably you want to add the |
|
Here is a close implementation to the KDE one: https://jjacky.com/statusnotifier/ It seem that was the preferred implementation of @TingPing some time ago. Is my preferred one right now of what currently exist. Opened issues are also interesting: |
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.soRead 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.
The text was updated successfully, but these errors were encountered: