[Development] New library in qtbase

Samuel Gaist samuel.gaist at edeltech.ch
Wed Feb 1 00:32:43 CET 2017


> On 15 Jan 2017, at 15:04, Robin Burchell <robin.burchell at crimson.no> wrote:
> 
> On Fri, Jan 13, 2017, at 11:58 PM, Samuel Gaist wrote:
>> Short summary, we have three possibilities:
>> 1) Own module (and current implementation)
>> 2) One “core" module and one GUI module to separate concerns for system
>> not requiring a GUI connection (Jake’s suggestion)
>> 3) Put everything in QtGui and implement the stuff in the QPA parts with
>> the implication that a QGuiApplication will be required.
>> 
>> Can we come to an agreement about which one to implement ?
> 
> My own vote would be tending towards 3 once the concept is nailed down.
> The existing change looks a little confused from a quick skim, e.g. you
> have a QCocoaNotifier which seems to be public API, but this is not the
> way I would expect to see this (at least, not in QtGui); I'd expect to
> see a "notification" class without any platform specifics, as far as
> possible, which then hooked into platform-specific code to "do its
> magic".
> 
> As the "magic" would tend to be platform-specific, QPA seems to be the
> logical place to me; this then also allows a platform implementer to
> provide their own custom notification handling, should it be required –
> thinking more on the embedded or new platform front here, which is
> typically where QPA comes in anyway, where you may not necessarily have
> existing services or standards to follow.
> 
> I can agree that it's "sad" to have to switch a QCoreApplication to a
> QGuiApplication once you need something in it, even if you don't have a
> GUI to present (though really, is this a common problem?), but aside
> from puritanical concerns, does that actually cause many concrete
> issues?
> 
> So, considering that, and as it's a problem that already exists for
> non-graphical applications to have to interact with images/clipboard,
> for syntax highlighting and other text manipulation, etc, I don't think
> that adding another case to that problem is a death sentence. I think
> it's an extension of a minor inconvenience, but I don't think that
> arbitrary splitting of a feature or class is a good way to address that.
> It leads to a harder to use & understand API for little gain as I
> imagine it, though it is hard to say without a concrete suggestion on
> API to review.
> 
> In the much longer term, on a separate tangent from your work, it might
> be interesting to think about rearranging things to properly address
> this problem if the gain is worth it, but even then, that starts to get
> tricky & requires a lot of care and research, especially when you
> realize that not everything you may want can be done without a windowing
> system: clipboard access, for instance, I'd say is almost certainly
> impossible to do without a windowing system on all platforms
> 
> The same may apply to presenting notifications. Do you know the specific
> requirements of the APIs for, say, Windows/macOS/iOS/Android? If any of
> those (or future platforms) required the WS, then you'd essentially be
> left with a useless API on anything that did not have a QGuiApplication.
> 
> I'd say that ultimately, requiring a QGuiApplication instance is a
> lesser evil than providing an API that won't work universally.
> 
> --
>  Robin Burchell
>  robin at crimson.no
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

Hi Robin,

Thanks for your thorough analysis.

The implemented plugin classes are not meant to be public API at all. They follow the naming scheme from QPA since the original implementation was done through it but in a less re-usable manner. This is definitely an area that will be cleaned up.

Thinking about your comments and the suggestion from Jake, I was wondering if cutting things a bit in the middle would be an interesting solution: what about having the integration in QPA and the implementation in a separated module ? This would allow to avoid making the GUI module bigger with code that is not directly GUI related (as in actively drawing) while keeping the platform specific stuff together.

Cheers
Samuel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170201/eb0f907e/attachment.sig>


More information about the Development mailing list