Open cassidyjames opened 4 years ago
Hey, thanks for the information. Now, I have two more questions, What is the reason behind this restriction? I mean, the indicator is build following all eOS guidelines and rules, why not allow people have access more easily to this kind of stuff? The main reason I wrote this application is because I've seen how popular was my other not so well written indicator and decided to build another one, and make it more accessible to them.
What if I decide to add more functionality to the application in parallel with the indicator? Like a process monitor that has also an indicator?
@PlugaruT the primary reason is that the system indicator area by design provides first-party, OS-wide indicators. Opening the flood gates to allow third-party apps to add their own indicators means we're inviting a ton of clutter and making that space less purposeful. I cover this a bit in this developer tips blog post: https://blog.elementary.io/developer-tips-backgrounding-system-integration/
What if I decide to add more functionality to the application in parallel with the indicator?
Currently I don't believe that would be accepted, because the problem comes down to adding an app indicator to the system area.
Yeah, I get that and I partially agree, because it all comes down to what the users wants, if the user wants to add something, you bet he will find a way to do this. But, the reason I asked this is because there are already application in the ApoCenter that do this, they add an indicator in the wingpanel.
@cassidyjames What is the difference between my Monitor Indicator and @PlugaruT's indicator? Is this because I ship an indicator with an app?
@stsdc your app probably probably predated our exact clarification of the rules so you may have been grandfathered in. Otherwise, my answer would be: we're human and we missed it.
the system indicator area by design provides first-party, OS-wide indicators. Opening the flood gates to allow third-party apps to add their own indicators means we're inviting a ton of clutter and making that space less purposeful. I cover this a bit in this developer tips blog post: blog.elementary.io/developer-tips-backgrounding-system-integration
Quoting a comment I made recently in StackExchange about this topic:
The HIG entry linked from that very blog post does not seem to disavow app indicators in the system tray, though. It explains when such an integration makes sense or not, and according to those recommendations, system-related information like those related to the filesystem (Dropbox, Google Drive), network (VPN, IPFS) and performance indicators should be acceptable.
Isn't displaying system load precisely that sort of OS-wide indicators? I don't see why it would be necessary to automatically block all apps from using indicators; since there is already a review step for AppCenter apps, it seems to be sufficient to apply the criteria defined in the HIG during the review...
@cassidyjames, I honestly never ran a linux distro without adding a system monitor indicator.
I currently run Elementary OS on an Asus T101HA which is an Intel Atom with 4GB of RAM. So I definitely need such an extension to constantly see if I'm on the edge of my PC's resources.
I'd actually like to see such an indicator as an OS feature which could just be enabled from System Settings.
Of course if @PlugaruT agrees, @cassidyjames, I know that are probably very busy working on Odin but I wanted to ask if would you guys consider adopting this system monitor indicator into eOS as a first-party, OS-wide indicator? I literally mean, incorporating it to the project as you have other indicators like keyboard lang, notifications, etc. and provide it as part of the OS. The code is already here, it may need some styling to make sure it fits exactly with the rest of eOS design, but is a matter of building on top and not starting from scratch. Also it doesn't need to be displayed by default but only if the user wants to enable it.
I think an indicator like this is really needed and provide it as part of the OS will be great so we users don't have to go hunting for the same in other places, which likely end up breaking eOS panel look and feel anyway.
Just my two cents.
PS: I would consider splitting the weather feature into a different, dedicated, weather indicator and leave this one dedicated to monitor different system resources only.
@casasfernando I'm not sure; there hasn't been a huge demand for a resource monitor, and even if we included one, I don't think we'd include it as an indicator—it would probably just be an app. Regarding Weather, there is an open issue and PR against the Date & Time indicator:
https://github.com/elementary/wingpanel-indicator-datetime/issues/255 https://github.com/elementary/wingpanel-indicator-datetime/pull/248
I would just like to add an unsolicited opinion and say that this restriction on the App Center is arbitrary and users are smart enough to know clutter from utility. Especially when they purposefully download and install an application like this one, whose sole function is to be an indicator of system resources. OS-level, you might say.
This removal of Ayatana and other Wingpanel indicators is why I had to begrudgingly switch away from eOS a couple of years ago. I get that you guys have a vision for no icons up there, but like, don't install them on your machine if you dislike them so much. They're clearly wildly popular on macOS and other Linux Distros.
@casasfernando I'm not sure; there hasn't been a huge demand for a resource monitor, and even if we included one, I don't think we'd include it as an indicator—it would probably just be an app. Regarding Weather, there is an open issue and PR against the Date & Time indicator:
elementary/wingpanel-indicator-datetime#255 elementary/wingpanel-indicator-datetime#248
@cassidyjames thanks a lot for taking the time to get back to my comment. I forked @PlugaruT 's project to https://github.com/casasfernando/wingpanel-indicator-weather as a dedicated weather indicator, did some modifications and add a few features (including manual location setting). I'm not planning to submit it to AppCenter since it will be rejected for the reasons already discussed above but if you find the time to take a look at it and give me any feedback on the design and any changes I should make so it will seamlessly integrate with Elementary I would really appreciate it. I plan to maintain it moving forward when Odin is finally released.
Many thanks for @PlugaruT since his code was a great base to work on.
Why not create a PPA on launchpad as a workaround? See https://github.com/PlugaruT/wingpanel-monitor/issues/27#issuecomment-903782275
OK Odin is out, what's the follow on this?
Hey @PlugaruT, thank you for another app submission to AppCenter! However, after a review of your app, we have determined that it is an “extension” or “plugin” of the Panel. As listed in the Publishing Requirements:
At some point in the future, we may expand the types of apps accepted into AppCenter, and we will announce any such major changes on our blog. We hope this does not deter you from submitting future apps that are supported!
Let me know if you have any questions and I would be happy to answer them.