OK, i have looked into this and found some connections. Specifically, all major OSs seem to have APIs providing the following:
1. download progress 2. native notifications. As older versions don't have those, and linux systems are pretty modular in any case, i propose that we use no fallback for download progress (the download button has a progress bar in any case), and we use XUL notifications as fallback for native notifications. the available implementations can be seen here (APIs are linked, so click on a node to get to the docs): https://cdn.mediacru.sh/ITsCgwM5JrUS.svg it seems that if we opt not to support growl on older macs or growl4windows or snarl on windows, the requirements to get everything are: OSX 10.9 or windows 8.0 or linux with KDE/unity (as there's no download progress API in GNOME 3). ---------- since the opinions seems to be against linking all kinds of libraries on linux, we'd need to create the following: 1. a service for DBUS. let's call it nsIDBUSService 2. a wrapper of the DBUS notification API using nsIDBUSService 3. a wrapper of the DBUS unity launcher API using nsIDBUSService 4. a wrapper of the KJob API using nsIDBUSService (if possible) 5. for each one of download progress and notifications: a switching mechanism that decides at compile time which native API to use (DBUS, Windows, or OSX), and at runtime if the API is available (respective DBUS service running? right version of Windows/OSX?) until then, we can just reactivate libnotify support like ubuntu does: https://bugzilla.mozilla.org/show_bug.cgi?id=853104#c18 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
