[Qt-creator] [Development] [OS X] Dock icon progress widget

[Shawn Rutledge]

> On 24 Jun 2016, at 11:19, René J. V. Bertin <rjvbertin at gmail.com> wrote:
> 
> Mike Krus wrote:
> 
>> 
>>> On 22 Jun 2016, at 11:17, Kevin Funk <kfunk at kde.org> wrote:
>>> A platform agnostic wrapper for all this would be indeed great to have!
>> If QtWinExtra has it, QtMacExtra can have it, and it’s doable on Linux, why
>> not add static methods on QProgressBar?
> 
> Why would you add Linux-only methods to QProgressBar? It would make more sense 
> to add something to QtX11Extras if there's a sensible way to do this under X11. 
> Otherwise you'd be adding to QtKDEExtras, oops, that's called KF5 :)

I thought he meant to add it as a cross-platform feature, not leave it in the extras modules.

Static in QProgressBar only makes sense if one application can only have one icon.  But why not have this feature available on each minimized window, in case multiple windows are busy?  (Well, some docks collapse multiple windows into one icon anyway.)  But then the API needs more thought; maybe we can do better than clutter up the API of QWindow or QProgressBar or QGuiApplication.  And BTW QtQuick Controls 2 is adding support for native menus, tray icons and such, so it would make sense to have QML API for this feature too, I suppose.

On Unity the D-Bus protocol is apparently this

https://wiki.ubuntu.com/Unity/LauncherAPI

and apparently work in progress on KDE:

https://git.reviewboard.kde.org/r/127050/

but we haven’t implemented any part of that protocol in Qt, yet.  It could be done.

There is an annoying warning which got mentioned on that KDE page:

"While the libunity API is stable, the DBus protocol underneath is not. We strongly discourage anyone from relying on it"

Philosophically I think that’s wrong.  (But it’s not the first time I’ve seen that attitude.)  A D-Bus protocol is a specification (just like say, a WiFi or Bluetooth specification, or any network RFC): revisions should be few and far between, while implementations naturally tend to be more numerous, and need more frequent fixes.  We really expect the authors of such things to think them through before the D-Bus protocol has “final specification” status.  And we don’t want to depend on yet another library, especially one which will not exist except on an Ubuntu system, and would therefore need to be dynamically loaded.  When we implement D-Bus protocols in our platform plugins, we do that with QtDBus, not by linking other libraries.  In that case, we are obliged to ignore any warnings about the protocol being unstable (or else allow the warning to dissuade us from doing anything at all).  So whether Canonical or Gnome likes it or not, every time they change a protocol which we’ve implemented, our implementation will lag behind.  They had better do any protocol changes in backwards-compatible ways.  Anything else is unrealistic, IMO.  Isn’t it the same issue for KDE implementing those?  Maybe we should treat KDE interest in implementing a Unity protocol as a sign that the specification can be considered frozen, and the warning is moot.

The tendency for third parties to make adjunct Qt plugins (such as style plugins) to add such features, like KDE and Unity have been doing, also has side effects: the feature is not portable.  When they bundle behavior changes and styling changes together, those plugins are left behind when users build or install new versions of Qt on their own: the plugin is only for the minor version of Qt that it was built for.  And then users wonder why the nifty features that those plugins added don’t work anymore.  This is why we independently added support for the D-Bus tray icons, their menus, and the unified menubar: those features began to be widely available on multiple desktops, and thus expected, regardless of Qt version.  It’s not a great use of time though, that different people implemented the same features in different ways.  It would be better if people would contribute patches for such things to Qt in the first place.  But for new features, hammering out proper API is important work, and takes time and patience.

It seems like the progress bar could be a cross-platform feature.  So we just need to think up a sufficiently general API that doesn’t look like it will be too limiting later, if the feature is expanded in some way.

The same story will probably repeat in the context of system notifications, BTW, and we’ll see what else.  There is work in progress on a pluggable notification system.  In general, these interfaces to the rest of the desktop (which use D-Bus on Linux) are slowly proliferating.  In another thread we are discussing how to handle communications and data sharing between apps on mobile platforms.  My hunch is that the good ideas from there will tend to end up being D-Bus specifications on desktop Linux, too, to bring them cross-platform instead of only on mobile devices.