> On 28 Nov 2016, at 01:05, Aleix Pol <aleix...@kde.org> wrote: > > On Sat, Nov 26, 2016 at 12:51 AM, Samuel Gaist <samuel.ga...@edeltech.ch> > wrote: >> Hi, >> >> As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d >> like to open a discussion about adding a new library in qtbase. >> >> Why this discussion ? >> >> Currently in work a pluggable notification system developed in its own >> library in qtbase. >> >> Why add a new library ? >> >> Originally the submission was integrated in QPA however after some thoughts >> and discussion, it was reworked to avoid that so that developers of non-GUI >> application could also take advantage of notifications without the need of a >> QGuiApplication. >> >> One of my motivation to move the code in its own library was that the second >> implementation provided a run-time plugin selection mechanism much like the >> QtSql module. After further discussion, the plugin selection has been moved >> to build-time. >> >> The library as it is currently could even be in its own repository however >> the goal in the long run is to replace the code used in QSystemTrayIcon by >> calls to this module which at this time duplicates the showMessage logic for >> macOS. Therefore having it as a separated repo would mean that qtbase would >> depend on it to be build which IMHO is not an option. >> >> So basically we are at this point: >> >> 1) Keep the new notifications module >> 2) Move the code in the gui module since QImage might be used >> >> In any case, the outcome of this discussion should likely be written in a >> QUIP so we have a clear set of rules about adding new libraries in existing >> Qt modules. >> >> Thank you for your attention > > This is very interesting! We've missed this in several occasions and > at the moment it's a bit of a stopper for some KDE applications to > flourish on some platforms (thinking of KDE Connect at the moment but > I'm sure that others too). > > IMHO the inflection point it's whether it's going to require > QCoreApplication or QGuiApplication. Without having sat down into > details, not only QImage but QIcon should also be part of the API. I'd > say that QtGui will end up being required. > > Aleix
That’s one of the “trick" I used, I didn’t put the QIcon interface on purpose. Without it you don’t need a QGuiApplication. One possibility might be to do like Jake suggested and have one non-gui and one gui library provide by the module. If we go with Allan's suggestion, putting it in QPA (which corresponds a bit like my first implementation), then there would be no way around a QGuiApplication. Samuel _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
