[Development] New library in qtbase

[Samuel Gaist]

> On 28 Nov 2016, at 01:05, Aleix Pol <aleixpol at kde.org> wrote:
> 
> On Sat, Nov 26, 2016 at 12:51 AM, Samuel Gaist <samuel.gaist at 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