Porting Software To Qt5, KDE Frameworks 5

[Ericg]

Status Notifiers are the basis for Ubuntu's AppIndicatora, as a way to drop the legacy way to do system tray icons which was via xembed. Dropping of xembed icons has been known for months and is kind of crucial given that its an X-specification (hence the name. http://standards.freedesktop.org/xem...ec-latest.html) and now Qt and KDE both support Wayland which wouldn't have access to it. So you either support Wayland and X and tell people "Well your application will work under X, but not Wayland, which is fine since we support both.. but most of our users are really on Wayland so using xembed is kind of counter productive.." or you just say "Screw it. Everyone use Status Notifiers. They work everywhere."

Martin's post on it: http://blog.martin-graesslin.com/blo...n-plasma-next/

Marco Martin's post on it: http://notmart.org/blog/2014/06/syst...-next-and-gtk/


(Martin, feel free to correct me on anything here, its just what ive picked up on reading the mailing lists and dev posts)

[Damian_Ivanov]

Ubuntu's indicators are not remotely compatible with the Statusnotifiers (they were in the past but are not anymore and won't be any time soon again).
You don't need KDE for the status notifiers to work. DBus is all you need. In QML an implementation could look like (and that's a fast draft):
DBusInterface {
id: dbusInterface
destination: "org.kde.StatusNotifierWatcher"
path: "/StatusNotifierWatcher"
iface: "org.kde.StatusNotifierWatcher"
signalsEnabled: true
function rcStatusNotifierItemRegistered() {registeredElements=dbusInterface.getProperty("Reg isteredStatusNotifierItems");}
function rcStatusNotifierItemUnregistered() {registeredElements=dbusInterface.getProperty("Reg isteredStatusNotifierItems");}
}

Grid {
columns:5;
spacing:5
Repeater {
model:registeredElements.length;
Rectangle {
width:settings.smallIconSize;
height:settings.smallIconSize;
color:"transparent";
DBusInterface {id:dBus;
destination:registeredElements[index].slice(0,-19);
path:"/StatusNotifierItem";
iface:"org.kde.StatusNotifierItem";
signalsEnabled:true;
Component.onCompleted: (icon.status == Image.Ready) ? icon.iconName=dBus.getProperty("IconName") : icon.iconName="error"
function rcNewIcon() {
icon.iconName=dBus.getProperty("IconName");
(icon.iconName == "") ? iconItem.icon=dBus.getPixmapProperty("IconPixmap") : "";}
}


Icon {id:icon;
width:settings.smallIconSize; height:settings.smallIconSize;
iconName:"user-busy"}

IconItem {id:iconItem;
width:settings.smallIconSize; height:settings.smallIconSize;
iconicon.iconName == "") ? dBus.getPixmapProperty("IconPixmap") : ""}
// Window{id:toolTip;flags:Qt.ToolTip; color:activePalette.highlight; Text{anchors.centerInarent; text:"fsdfds"}}

MouseArea {
anchors.fillarent;
acceptedButtons:Qt.AllButtons;
hoverEnabled:true;
onWheel: if (wheel.angleDelta.y > 0) {dBus.call("Scroll", [5, "vertical"])}
else if (wheel.angleDelta.y < 0) {dBus.call("Scroll", [5, "horizontal"])}
onPressed: {
var globalCoordinares = icon.mapToItem(panelBackground, 0, 0)
if (mouse.button == Qt.LeftButton) {dBus.call("Activate", [globalCoordinares.x, panelBackground.y])}
// if (mouse.button == Qt.LeftButton) {dBus.call("Activate", [globalCoordinares.x, window.y-window.height]),console.log(dBus.getProperty("IconPixmap")[0])}
else if (mouse.button == Qt.RightButton) {dBus.call("ContextMenu", [globalCoordinares.x, panelBackground.y-panelBackground.height])}
else if (mouse.button == Qt.MiddleButton) {dBus.call("SecondaryActivate", [globalCoordinares.x, panelBackground.y-panelBackground.height])}}

// onEntered: {console.log("X: " + globalCoordinares.x + " y: " + globalCoordinares.y)}
//onExited:toolTip.close()
}
}
}
}

[eydee]

well bugs in QSystemTrayIcon can hardly be called show-stoppers. Anyway that's a Unity issue: Unity needs to provide a PlatformTheme plugin and replace the x-embedd based icon by a status notifier. That's what we do in Plasma - Unity could even just use our code to do it.

If you're making a tray based program, a tray that doesn't work is exactly that, a show stopper. The other important things have already been said by others. Qt is great because it's cross platform. I use it because I can make a GUI program that compiles on multiple operating systems. Working on KDE and windows only defeats the purpose of being cross platform. I hope these issues will some day be fixed, until then, I stick to Qt 4.

PS: I mostly use LXDE and XFCE, not Unity.

[scionicspectre]

If you're making a tray based program, a tray that doesn't work is exactly that, a show stopper. The other important things have already been said by others. Qt is great because it's cross platform. I use it because I can make a GUI program that compiles on multiple operating systems. Working on KDE and windows only defeats the purpose of being cross platform. I hope these issues will some day be fixed, until then, I stick to Qt 4.

PS: I mostly use LXDE and XFCE, not Unity.

I just realized- wouldn't it be cool to make an application that supports the new specification and have it run AS a traditional tray icon? Then everyone could have a sort of way out until the far-flung day where we've all moved on.

Just a thought- it sounds plausible if this becomes a big enough problem outside of Qt alone. Until then, it would be nice to have some flexibility, since that's one of the traditional values behind Qt, anyway.

[zanny]

I just realized- wouldn't it be cool to make an application that supports the new specification and have it run AS a traditional tray icon? Then everyone could have a sort of way out until the far-flung day where we've all moved on.

Just a thought- it sounds plausible if this becomes a big enough problem outside of Qt alone. Until then, it would be nice to have some flexibility, since that's one of the traditional values behind Qt, anyway.

I believe that is what is already happening. The X based tray mapping is done only under X - if you were running a Qt5 application under Wayland, it would be using the newer tray standard. I think.

What we really want is statusnotifiers everywhere, with the xembed version being dropped entirely. They keep it for compatibility, I guess - qt5 apps are supposed to run on really old systems as long as they provide the qt5 libs. Qt5 is an open project at least, so someone can contribute an implementation where if statusnotifiers aren't available it falls back to xembed.

[mgraesslin]

I believe that is what is already happening. The X based tray mapping is done only under X - if you were running a Qt5 application under Wayland, it would be using the newer tray standard. I think.

no there is no implementation for QSystemTrayIcon on Wayland. QSystemTrayIcon in 5.3 is bound to the X11 protocol if Qt is compiled with X11 support (I fixed that for 5.4). QSystemTrayIcon also doesn't work out-of-the-box on the upcoming Qt 5 based Plasma release - as we dropped the X embed support - as stated in a previous comment. It's working nevertheless as we have implemented a wrapper to KSNI in the PlatformTheme which works if the distros pick the mentioned patch from 5.4 (they are informed about it). Fun fact: as we removed support for X11 QSystemTrayIcon from 4.8 is not working in the upcoming Plasma release (unless the distro picks a patch from Ubuntu to support AppIndicator for QSystemTrayIcon).

QSystemTrayIcon is not guaranteed to be supported on a platform - it even offers a QSystemTrayIcon::isSystemTrayAvailable().

Now any desktop environment on Linux should provide a PlatformTheme plugin and provide an implementation for QSystemTrayIcon - using the legacy x11 embed protocol is just ridiculous. With the help of the plugin it can be wrapped into any form which suits the desktop environment. To my knowledge no desktop environment is currently relying on xembed system tray icon as only or primary way to have a status notifier.

If you have an application which requires a system tray icon to work at all the devs did something badly wrong. There's a reason why we kicked the x11 embed protocol from Plasma. Next to the technical reasons it's also that we don't want any applications in it. It's a "SYSTEM" try and no "APPLICATIONS" tray. For the applications there are the docks.

[eydee]

If you have an application which requires a system tray icon to work at all the devs did something badly wrong. There's a reason why we kicked the x11 embed protocol from Plasma. Next to the technical reasons it's also that we don't want any applications in it. It's a "SYSTEM" try and no "APPLICATIONS" tray. For the applications there are the docks.

You're still not thinking with ALL operating system in mind. The point of Qt is doing all this under the hood and provide the same interface for the programmer no matter wqhat platform he's on, so he doesn't have to think about different platform dependent solutions. The more platforms are "lost", the more people will move to other alternatives. Even now a lot of people suggest using java instead of solutions like Qt.

[zanny]

no there is no implementation for QSystemTrayIcon on Wayland. QSystemTrayIcon in 5.3 is bound to the X11 protocol if Qt is compiled with X11 support (I fixed that for 5.4). QSystemTrayIcon also doesn't work out-of-the-box on the upcoming Qt 5 based Plasma release - as we dropped the X embed support - as stated in a previous comment. It's working nevertheless as we have implemented a wrapper to KSNI in the PlatformTheme which works if the distros pick the mentioned patch from 5.4 (they are informed about it). Fun fact: as we removed support for X11 QSystemTrayIcon from 4.8 is not working in the upcoming Plasma release (unless the distro picks a patch from Ubuntu to support AppIndicator for QSystemTrayIcon).

QSystemTrayIcon is not guaranteed to be supported on a platform - it even offers a QSystemTrayIcon::isSystemTrayAvailable().

Now any desktop environment on Linux should provide a PlatformTheme plugin and provide an implementation for QSystemTrayIcon - using the legacy x11 embed protocol is just ridiculous. With the help of the plugin it can be wrapped into any form which suits the desktop environment. To my knowledge no desktop environment is currently relying on xembed system tray icon as only or primary way to have a status notifier.

If you have an application which requires a system tray icon to work at all the devs did something badly wrong. There's a reason why we kicked the x11 embed protocol from Plasma. Next to the technical reasons it's also that we don't want any applications in it. It's a "SYSTEM" try and no "APPLICATIONS" tray. For the applications there are the docks.

Docks are huge though. Usually. I use icontasks as my primary application launcher and I'd never have enough room for everything if clementine, ktorrent, ktp, bluedevil, steam, kmail, and konversation were not minimizing to tray. The tray is nice because it gives you smaller icons of what is already running, even if it is not a presented window.

I think it sounds really Gnome-esque to try to push developers away from putting apps with persistent running states anywhere but the system tray. That is how it has worked for over a decade. Couldn't there just be a tangential system management plasmoid that includes things like volume control and wifi if you wanted one? I like dockmanager for running application functionality that is presenting a window as well, but that is not the same as a daemon like program you always have running. I think there is a UX benefit too - your tray icons can be smaller because you are always using them on and off, whereas docked icons are bigger because they might not be muscle memory software you are constantly using.

Here is a screengrab of my current tray on 4.13.2: http://i.imgur.com/r5aL3mq.png?1

I intentionally like having my persistent daemon like programs running in the tray while transient applications are in my dock. I understand the argument that an application that outright doesn't work without the tray icon is a design oversight, though. And it is your window manager, for the most part, after all, I'm not trying to say I know better =P (thank you so much for your work on kwin and plasma its all super awesome software etc)

[CTown]

...Next to the technical reasons it's also that we don't want any applications in it. It's a "SYSTEM" try and no "APPLICATIONS" tray. For the applications there are the docks.

In that case, will the default task bar in Plasma ever get quicklists support? It makes applications need the system tray less (since the same actions can be applied to the right click menu of each application in the dock bar) and makes common features very accessible. Also, as zanny puts it, using only icons in the task bar saves a lot of room (and roomy tends to make for nice design).

Docks are huge though. Usually. I use icontasks as my primary application launcher and I'd never have enough room for everything if clementine, ktorrent, ktp, bluedevil, steam, kmail, and konversation were not minimizing to tray. The tray is nice because it gives you smaller icons of what is already running, even if it is not a presented window...

In the icon tasks settings you can change the "Scale Icons to" setting to something smaller or "Automatic" to see if you can fit more icons that way.

[CTown]

Ubuntu's indicators are not remotely compatible with the Statusnotifiers (they were in the past but are not anymore and won't be any time soon again).
You don't need KDE for the status notifiers to work. DBus is all you need. In QML an implementation could look like (and that's a fast draft):

But if a GTK application uses Ubuntu's indicatior library, the application works perfectly in Plasma. So, how can Statusnotifiers and indicators not be the same?

Here is an article by Marco Martin on the subject.