[Development] Orphan modules

[Edward Welbourne]

I notice, as part of seeking folk to look at API reviews, that we have
several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
that brought this to my attention) qtxmlpatterns, according to [0].

* [0] https://wiki.qt.io/Maintainers

(There's also qtdoc, with no person as maintainer, but with "Norway" in
the Country column, which I interpret as the doc-team here in Oslo; and
there's qtfeedback, which is unsupported; two other unsupported modules
do in fact have Maintainers.)

If anyone out there feels an urge to volunteer to adopt one of these
orphans, it'd be worth speaking up,

Eddy.

[Chris Adams]

Hi Eddy,

I'm willing to be listed as the maintainer of QtFeedback for now. If
it ever gets more development attention and released as a supported
module then someone with more time to give should probably take over,
but until then I'm more than happy to review any changes people might
contribute for that module.

Cheers,
Chris.


On Thu, Aug 30, 2018 at 11:27 PM, Edward Welbourne
<***@qt.io> wrote:
> I notice, as part of seeking folk to look at API reviews, that we have
> several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
> qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
> that brought this to my attention) qtxmlpatterns, according to [0].
>
> * [0] https://wiki.qt.io/Maintainers
>
> (There's also qtdoc, with no person as maintainer, but with "Norway" in
> the Country column, which I interpret as the doc-team here in Oslo; and
> there's qtfeedback, which is unsupported; two other unsupported modules
> do in fact have Maintainers.)
>
> If anyone out there feels an urge to volunteer to adopt one of these
> orphans, it'd be worth speaking up,
>
> Eddy.
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Lars Knoll]

On 31 Aug 2018, at 02:06, Chris Adams <***@qinetic.com.au<mailto:***@qinetic.com.au>> wrote:

Hi Eddy,

I'm willing to be listed as the maintainer of QtFeedback for now. If
it ever gets more development attention and released as a supported
module then someone with more time to give should probably take over,
but until then I'm more than happy to review any changes people might
contribute for that module.

Thanks Chris! Let’s add you for Qt Feedback then :)

Cheers,
Chris.


On Thu, Aug 30, 2018 at 11:27 PM, Edward Welbourne
<***@qt.io<mailto:***@qt.io>> wrote:
I notice, as part of seeking folk to look at API reviews, that we have
several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
that brought this to my attention) qtxmlpatterns, according to [0].

* [0] https://wiki.qt.io/Maintainers

The supported modules where we have no maintainer listed go to me for the API reviews.

Cheers,
Lars


(There's also qtdoc, with no person as maintainer, but with "Norway" in
the Country column, which I interpret as the doc-team here in Oslo; and
there's qtfeedback, which is unsupported; two other unsupported modules
do in fact have Maintainers.)

If anyone out there feels an urge to volunteer to adopt one of these
orphans, it'd be worth speaking up,

Eddy.
_______________________________________________
Development mailing list
***@qt-project.org<mailto:***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
***@qt-project.org<mailto:***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

[Samuel Gaist]

Hi Eddy,

If you guys think my competences fill the bill, I can take on the qtmacextras
module maintenance.

Best regards

Samuel

> On 30 Aug 2018, at 15:27, Edward Welbourne <***@qt.io> wrote:
>
> I notice, as part of seeking folk to look at API reviews, that we have
> several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
> qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
> that brought this to my attention) qtxmlpatterns, according to [0].
>
> * [0] https://wiki.qt.io/Maintainers
>
> (There's also qtdoc, with no person as maintainer, but with "Norway" in
> the Country column, which I interpret as the doc-team here in Oslo; and
> there's qtfeedback, which is unsupported; two other unsupported modules
> do in fact have Maintainers.)
>
> If anyone out there feels an urge to volunteer to adopt one of these
> orphans, it'd be worth speaking up,
>
> Eddy.
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Tor Arne Vestbø]

Hey,

Nothing against your competence Samuel, but I think the qtmacextras module should be maintained by the same maintained as macOS, Morten.

I also think that the extras modules have a risk of ending up as dumping grounds for platform specific APIs we never really got around to integrating with Qt in a cross platform way, or that didn’t really need a Qt api in the first place, such as wrapping simple objective-c functions.

With the proposed solution of making platform plugins libraries with their own private headers, we can have these apis closer to the platform code, and without lots of plumbing and indirection.

I think the qtmacextras module in particular should be deprecated ASAP, and will strongly oppose any new APIs added to it.

- Tor Arne

> On 12 Sep 2018, at 00:00, Samuel Gaist <***@idiap.ch> wrote:
>
> Hi Eddy,
>
> If you guys think my competences fill the bill, I can take on the qtmacextras
> module maintenance.
>
> Best regards
>
> Samuel
>
>> On 30 Aug 2018, at 15:27, Edward Welbourne <***@qt.io> wrote:
>>
>> I notice, as part of seeking folk to look at API reviews, that we have
>> several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
>> qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
>> that brought this to my attention) qtxmlpatterns, according to [0].
>>
>> * [0] https://wiki.qt.io/Maintainers
>>
>> (There's also qtdoc, with no person as maintainer, but with "Norway" in
>> the Country column, which I interpret as the doc-team here in Oslo; and
>> there's qtfeedback, which is unsupported; two other unsupported modules
>> do in fact have Maintainers.)
>>
>> If anyone out there feels an urge to volunteer to adopt one of these
>> orphans, it'd be worth speaking up,
>>
>> Eddy.
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Gatis Paeglis]

> With the proposed solution of making platform plugins libraries with their own private headers, we can have these apis closer to the platform code, and without lots of plumbing and indirection.
> I think the qtmacextras module in particular should be deprecated ASAP, and will strongly oppose any new APIs added to it.


+1 for deprecating qtx11extras as well and moving the code closer to actual plugin. It is frustrating to have all that boilerplate code for 1 header file - qx11info_x11.h


Gatis Paeglis.

________________________________
From: Development <development-bounces+gatis.paeglis=***@qt-project.org> on behalf of Tor Arne Vestbø <***@qt.io>
Sent: Wednesday, September 12, 2018 10:25:37 AM
To: Samuel Gaist
Cc: ***@qt-project.org
Subject: Re: [Development] Orphan modules

Hey,

Nothing against your competence Samuel, but I think the qtmacextras module should be maintained by the same maintained as macOS, Morten.

I also think that the extras modules have a risk of ending up as dumping grounds for platform specific APIs we never really got around to integrating with Qt in a cross platform way, or that didn’t really need a Qt api in the first place, such as wrapping simple objective-c functions.

With the proposed solution of making platform plugins libraries with their own private headers, we can have these apis closer to the platform code, and without lots of plumbing and indirection.

I think the qtmacextras module in particular should be deprecated ASAP, and will strongly oppose any new APIs added to it.

- Tor Arne

> On 12 Sep 2018, at 00:00, Samuel Gaist <***@idiap.ch> wrote:
>
> Hi Eddy,
>
> If you guys think my competences fill the bill, I can take on the qtmacextras
> module maintenance.
>
> Best regards
>
> Samuel
>
>> On 30 Aug 2018, at 15:27, Edward Welbourne <***@qt.io> wrote:
>>
>> I notice, as part of seeking folk to look at API reviews, that we have
>> several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
>> qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
>> that brought this to my attention) qtxmlpatterns, according to [0].
>>
>> * [0] https://wiki.qt.io/Maintainers
>>
>> (There's also qtdoc, with no person as maintainer, but with "Norway" in
>> the Country column, which I interpret as the doc-team here in Oslo; and
>> there's qtfeedback, which is unsupported; two other unsupported modules
>> do in fact have Maintainers.)
>>
>> If anyone out there feels an urge to volunteer to adopt one of these
>> orphans, it'd be worth speaking up,
>>
>> Eddy.
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Thiago Macieira]

On Wednesday, 12 September 2018 01:44:36 PDT Gatis Paeglis wrote:
> > With the proposed solution of making platform plugins libraries with their
> > own private headers, we can have these apis closer to the platform code,
> > and without lots of plumbing and indirection. I think the qtmacextras
> > module in particular should be deprecated ASAP, and will strongly oppose
> > any new APIs added to it.
> +1 for deprecating qtx11extras as well and moving the code closer to actual
> plugin. It is frustrating to have all that boilerplate code for 1 header
> file - qx11info_x11.h

I was going to say we needed replacement API for it, but I realise the
QX11EmbedContainer is not there. Since people have lived for the last 6 years
without it in Qt 5, it doesn't seem we really need a replacement.

What do applications do if they need to XEmbed another application's window
(for example, VirtualBox for the guest window)? And how do they find out the
real pixel size of it, in case scaling is active?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Lisandro Damián Nicanor Pérez Meyer]

El miércoles, 12 de septiembre de 2018 12:38:03 -03 Thiago Macieira escribió:
> On Wednesday, 12 September 2018 01:44:36 PDT Gatis Paeglis wrote:
> > > With the proposed solution of making platform plugins libraries with
> > > their
> > > own private headers, we can have these apis closer to the platform code,
> > > and without lots of plumbing and indirection. I think the qtmacextras
> > > module in particular should be deprecated ASAP, and will strongly oppose
> > > any new APIs added to it.
> >
> > +1 for deprecating qtx11extras as well and moving the code closer to
> > actual
> > plugin. It is frustrating to have all that boilerplate code for 1 header
> > file - qx11info_x11.h
>
> I was going to say we needed replacement API for it, but I realise the
> QX11EmbedContainer is not there. Since people have lived for the last 6
> years without it in Qt 5, it doesn't seem we really need a replacement.
>
> What do applications do if they need to XEmbed another application's window
> (for example, VirtualBox for the guest window)? And how do they find out the
> real pixel size of it, in case scaling is active?

After reading this I thought of checking which packages would need to be
modified in Debian if for some reason qtx11extras ceased to exist. The list is
not precisely small:

# Broken Build-Depends:
actiona: libqt5x11extras5-dev
breeze: libqt5x11extras5-dev (>= 5.4)
calligra: libqt5x11extras5-dev (>= 5.3.0)
calligraplan: libqt5x11extras5-dev (>= 5.4.0)
cb2bib: libqt5x11extras5-dev
clementine: libqt5x11extras5-dev
compton-conf: libqt5x11extras5-dev
danmaq: libqt5x11extras5-dev
dde-qt5integration: libqt5x11extras5-dev
deepin-image-viewer: libqt5x11extras5-dev
deepin-movie-reborn: libqt5x11extras5-dev
deepin-qt5dxcb-plugin: libqt5x11extras5-dev
deepin-screen-recorder: libqt5x11extras5-dev
deepin-screenshot: libqt5x11extras5-dev
digikam: libqt5x11extras5-dev
dpuser: libqt5x11extras5-dev
drkonqi: libqt5x11extras5-dev (>= 5.9.0~)
dtkwidget: libqt5x11extras5-dev
dtkwm: libqt5x11extras5-dev
falkon: libqt5x11extras5-dev
featherpad: libqt5x11extras5-dev
frameworkintegration: libqt5x11extras5-dev (>= 5.8.0~)
fw4spl: libqt5x11extras5-dev
gambas3: libqt5x11extras5-dev
goldendict: libqt5x11extras5-dev
gst-plugins-good1.0: libqt5x11extras5-dev
gwenview: libqt5x11extras5-dev (>= 5.6.0~)
jag: libqt5x11extras5-dev
kadu: libqt5x11extras5-dev
kadu-mime-tex: libqt5x11extras5-dev
kaffeine: libqt5x11extras5-dev (>= 5.4.0)
kalarm: libqt5x11extras5-dev (>= 5.7.0~)
kcm-fcitx: libqt5x11extras5-dev
kcrash: libqt5x11extras5-dev (>= 5.8.0~)
kdbusaddons: libqt5x11extras5-dev (>= 5.8.0~)
kde-cli-tools: libqt5x11extras5-dev (>= 5.9.0~)
kde-spectacle: libqt5x11extras5-dev (>= 5.4.0~)
kdeconnect: libqt5x11extras5-dev (>= 5.7.0~)
kdelibs4support: libqt5x11extras5-dev (>= 5.8.0~)
kdeplasma-addons: libqt5x11extras5-dev (>= 5.9.0~)
kdocker: libqt5x11extras5-dev
keepassxc: libqt5x11extras5-dev
kgamma5: libqt5x11extras5-dev (>= 5.4.0~)
kglobalaccel: libqt5x11extras5-dev (>= 5.8.0~)
kguiaddons: libqt5x11extras5-dev (>= 5.8.0~)
khotkeys: libqt5x11extras5-dev (>= 5.4.0~)
khtml: libqt5x11extras5-dev (>= 5.8.0~)
kidletime: libqt5x11extras5-dev (>= 5.8.0~)
kio: libqt5x11extras5-dev (>= 5.8.0~)
kjobwidgets: libqt5x11extras5-dev (>= 5.8.0~)
klatexformula: libqt5x11extras5-dev
kmplayer: libqt5x11extras5-dev
knotes: libqt5x11extras5-dev (>= 5.7.0~)
knotifications: libqt5x11extras5-dev (>= 5.8.0~)
konqueror: libqt5x11extras5-dev
krfb: libqt5x11extras5-dev
krita: libqt5x11extras5-dev (>= 5.6.0)
kruler: libqt5x11extras5-dev (>= 5.4)
kscreen: libqt5x11extras5-dev (>= 5.4)
kscreenlocker: libqt5x11extras5-dev (>= 5.9.0~)
ktouch: libqt5x11extras5-dev (>= 5.5~)
kvirc: libqt5x11extras5-dev
kwin: libqt5x11extras5-dev (>= 5.9.0~)
kwindowsystem: libqt5x11extras5-dev (>= 5.8.0~)
kxmlgui: libqt5x11extras5-dev (>= 5.4)
kxstitch: libqt5x11extras5-dev
libfm-qt: libqt5x11extras5-dev
libkscreen: libqt5x11extras5-dev (>= 5.9.0~)
libksysguard: libqt5x11extras5-dev (>= 5.4)
liblxqt: libqt5x11extras5-dev
libqtpas: libqt5x11extras5-dev
libreoffice: libqt5x11extras5-dev (>= 5.6)
lximage-qt: libqt5x11extras5-dev
lxqt-about: libqt5x11extras5-dev
lxqt-admin: libqt5x11extras5-dev
lxqt-config: libqt5x11extras5-dev
lxqt-globalkeys: libqt5x11extras5-dev
lxqt-notificationd: libqt5x11extras5-dev
lxqt-openssh-askpass: libqt5x11extras5-dev
lxqt-panel: libqt5x11extras5-dev
lxqt-policykit: libqt5x11extras5-dev
lxqt-powermanagement: libqt5x11extras5-dev
lxqt-qtplugin: libqt5x11extras5-dev
lxqt-runner: libqt5x11extras5-dev
lxqt-session: libqt5x11extras5-dev
lxqt-sudo: libqt5x11extras5-dev
obconf-qt: libqt5x11extras5-dev
obs-studio: libqt5x11extras5-dev
oxygen: libqt5x11extras5-dev (>= 5.4)
paraview: libqt5x11extras5-dev
pavucontrol-qt: libqt5x11extras5-dev
pcmanfm-qt: libqt5x11extras5-dev
phonon-backend-gstreamer: libqt5x11extras5-dev (>= 5.2.0~)
plasma-desktop: libqt5x11extras5-dev (>= 5.10.0~)
plasma-framework: libqt5x11extras5-dev (>= 5.4)
plasma-integration: libqt5x11extras5-dev (>= 5.9.0~)
plasma-workspace: libqt5x11extras5-dev (>= 5.9.0~)
powerdevil: libqt5x11extras5-dev (>= 5.9.0~)
psi: libqt5x11extras5-dev
psi-plus: libqt5x11extras5-dev
pyqt5: libqt5x11extras5-dev (>= 5.9.1)
pyside2: libqt5x11extras5-dev
qcomicbook: libqt5x11extras5-dev (>= 5.4.0)
qjackctl: libqt5x11extras5-dev
qmmp: libqt5x11extras5-dev (>= 5.4)
qps: libqt5x11extras5-dev
qqc2-desktop-style: libqt5x11extras5-dev (>= 5.8.0~)
qsampler: libqt5x11extras5-dev
qsynth: libqt5x11extras5-dev
qtav: libqt5x11extras5-dev
qtcreator: libqt5x11extras5-dev (>= 5.6.2~)
qtcurve: libqt5x11extras5-dev
qtdoc-opensource-src: qtx11extras5-doc-html (>= 5.11.1~)
qterminal: libqt5x11extras5-dev
qtop: libqt5x11extras5-dev
qtractor: libqt5x11extras5-dev
qxgedit: libqt5x11extras5-dev
renderdoc: libqt5x11extras5-dev
screengrab: libqt5x11extras5-dev
sddm-kcm: libqt5x11extras5-dev (>= 5.4.0~)
simplescreenrecorder: libqt5x11extras5-dev (>= 5.7)
swift-im: libqt5x11extras5-dev (>= 5.0.0)
uim: libqt5x11extras5-dev
virtualbox/contrib: libqt5x11extras5-dev
vlc: libqt5x11extras5-dev
vokoscreen: libqt5x11extras5-dev
vtk7: libqt5x11extras5-dev
x2goclient: libqt5x11extras5-dev
yakuake: libqt5x11extras5-dev
zeal: libqt5x11extras5-dev

--
Combata las características. Si una característica no es absolutamente
esencial, descártela, especialmente si tiene el mismo efecto que se
puede alcanzar mediante la combinación de otras características.
Andrew S. Tanenbaum, de su libro "Computer Networks"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[Tor Arne Vestbø]

> On 12 Sep 2018, at 18:52, Lisandro Damián Nicanor Pérez Meyer <***@gmail.com> wrote:
>
> El miércoles, 12 de septiembre de 2018 12:38:03 -03 Thiago Macieira escribió:
>> On Wednesday, 12 September 2018 01:44:36 PDT Gatis Paeglis wrote:
>>>> With the proposed solution of making platform plugins libraries with
>>>> their
>>>> own private headers, we can have these apis closer to the platform code,
>>>> and without lots of plumbing and indirection. I think the qtmacextras
>>>> module in particular should be deprecated ASAP, and will strongly oppose
>>>> any new APIs added to it.
>>>
>>> +1 for deprecating qtx11extras as well and moving the code closer to
>>> actual
>>> plugin. It is frustrating to have all that boilerplate code for 1 header
>>> file - qx11info_x11.h
>>
>> I was going to say we needed replacement API for it, but I realise the
>> QX11EmbedContainer is not there. Since people have lived for the last 6
>> years without it in Qt 5, it doesn't seem we really need a replacement.
>>
>> What do applications do if they need to XEmbed another application's window
>> (for example, VirtualBox for the guest window)? And how do they find out the
>> real pixel size of it, in case scaling is active?
>
> After reading this I thought of checking which packages would need to be
> modified in Debian if for some reason qtx11extras ceased to exist. The list is
> not precisely small:

Does that list guarantee that the package actually uses APIs from the module?

If they do, does the list say anything about whether or not those APIs have modern replacements in Qt or other ways to do the same?

Tor Arne

[Thiago Macieira]

On Wednesday, 12 September 2018 10:09:53 PDT Tor Arne Vestbø wrote:
> If they do, does the list say anything about whether or not those APIs have
> modern replacements in Qt or other ways to do the same?

There's exactly one class in QtX11Extras: QX11Info.
http://doc.qt.io/qt-5/qx11info.html

I could see kwin_x11 needing it, but I really don't see all the other
applications doing so. Do we have a replacement for QX11Info?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Jean-Michaël Celerier]

There are quite a bunch of people using it out there :
https://github.com/search?l=C%2B%2B&q=QX11Info+NOT+tst_QX11Info+NOT+QT_END_LICENSE&type=Code


-------
Jean-Michaël Celerier
http://www.jcelerier.name


On Thu, Sep 13, 2018 at 1:41 AM Thiago Macieira <***@intel.com>
wrote:

> On Wednesday, 12 September 2018 10:09:53 PDT Tor Arne VestbÞ wrote:
> > If they do, does the list say anything about whether or not those APIs
> have
> > modern replacements in Qt or other ways to do the same?
>
> There's exactly one class in QtX11Extras: QX11Info.
> http://doc.qt.io/qt-5/qx11info.html
>
> I could see kwin_x11 needing it, but I really don't see all the other
> applications doing so. Do we have a replacement for QX11Info?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Gatis Paeglis]

> APIs have modern replacements in Qt.


Not everything can be or should be in cross platform code.


> other ways to do the same?


For some maybe, but it is all about convenience. Some things (e.g. peeking at our internal event queue) can be done only if we expose that info, there isn't really other ways.


> I could see kwin_x11 needing it, but I really don't see all the other applications doing so.


There actually are other application that need this. Xlib used to provide various higher level APIs on top of X11 protocol. XCB, which stands for X11 C Binding, is low level API, which does not provide equivalents for all of Xlib APIs that some Qt 4 applications, that use native calls, depend on. This is where QX11Extras is used to provide some alternatives.


My only concern was that it should not be a separate module. The topic here was about orphan modules, everything else (e.g. if any of APIs have become redundant) should be discussed elsewhere.


> I was going to say we needed replacement API for it, but I realise the
QX11EmbedContainer is not there. Since people have lived for the last 6 years
without it in Qt 5, it doesn't seem we really need a replacement.


See https://codereview.qt-project.org/#/c/42990/


Gatis Paeglis.


________________________________
From: Development <development-bounces+gatis.paeglis=***@qt-project.org> on behalf of Jean-Michaël Celerier <***@gmail.com>
Sent: Thursday, September 13, 2018 8:37:57 AM
To: Thiago Macieira
Cc: development
Subject: Re: [Development] Orphan modules

There are quite a bunch of people using it out there : https://github.com/search?l=C%2B%2B&q=QX11Info+NOT+tst_QX11Info+NOT+QT_END_LICENSE&type=Code


-------
Jean-Michaël Celerier
http://www.jcelerier.name


On Thu, Sep 13, 2018 at 1:41 AM Thiago Macieira <***@intel.com<mailto:***@intel.com>> wrote:
On Wednesday, 12 September 2018 10:09:53 PDT Tor Arne Vestbø wrote:
> If they do, does the list say anything about whether or not those APIs have
> modern replacements in Qt or other ways to do the same?

There's exactly one class in QtX11Extras: QX11Info.
http://doc.qt.io/qt-5/qx11info.html

I could see kwin_x11 needing it, but I really don't see all the other
applications doing so. Do we have a replacement for QX11Info?

--
Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com>
Software Architect - Intel Open Source Technology Center

[Sune Vuorela]

On 2018-09-12, Gatis Paeglis <***@qt.io> wrote:
> +1 for deprecating qtx11extras as well and moving the code closer to actual plugin. It is frustrating to have all that boilerplate code for 1 header file - qx11info_x11.h

I think it makes sense to have qtx11extras. A stable api and abi that
X11 users can rely on.

I see the only alternative is to provide stable apis in QPA and friends
instead. But that has so far been refused.

/Sune

[Edward Welbourne]

Tor Arne Vestbø (12 September 2018 10:25)
> I think the qtmacextras module should be maintained by the same
> [maintainer] as macOS, Morten.

That would depend on - Morten: are you willing to take it on ?

As long as Tor Arne and Morten are watching the module, Samuel could
gain some experience as a Maintainer, after all.

> I also think that the extras modules have a risk of ending up as
> dumping grounds for platform specific APIs we never really got around
> to integrating with Qt in a cross platform way, or that didn’t really
> need a Qt api in the first place, such as wrapping simple objective-c
> functions.

Indeed, I'm always wary of extras, util, misc and similar names, that
have no boundary on their scope to keep clutter from being dumped in.
I've found too much misplaced junk in such-named things over the years.

> With the proposed solution of making platform plugins libraries with
> their own private headers, we can have these apis closer to the
> platform code, and without lots of plumbing and indirection.

Sounds promising.

> I think the qtmacextras module in particular should be deprecated
> ASAP, and will strongly oppose any new APIs added to it.

Use of passive voice - "should be" - perhaps a better plan would be to
actively submit the patches to make it happen, or file a task in Jira
for it. Even if there's no release branch ready for them, having
patches on dev gives relevant folk notice of your intent; and it might
give a focus for like-minded folk to co-ordinate the pre-requisites of
that change,

Eddy.

[Morten Sørvig]

> On 12 Sep 2018, at 11:02, Edward Welbourne <***@qt.io> wrote:
>
> Tor Arne Vestbø (12 September 2018 10:25)
>> I think the qtmacextras module should be maintained by the same
>> [maintainer] as macOS, Morten.
>
> That would depend on - Morten: are you willing to take it on ?

To be honest I assumed that I already was, so that’s a yes :)

Not that there as been much activity on the module. I agree that the best way forward is to move it to a deprecated ands/or done state, for the reasons outlined earlier in this thread.

Morten

[Edward Welbourne]

Tor Arne Vestbø (12 September 2018 10:25)
>> I think the qtmacextras module should be maintained by the same
>> [maintainer] as macOS, Morten.

On 12 Sep 2018, at 11:02, Edward Welbourne <***@qt.io> wrote:
> That would depend on - Morten: are you willing to take it on ?

> Morten Sørvig (12 September 2018 12:16)
To be honest I assumed that I already was, so that’s a yes :)

Wiki duly updated, then :-)

Eddy.

[Tor Arne Vestbø]

On 12 Sep 2018, at 11:02, Edward Welbourne <***@qt.io> wrote:
>> With the proposed solution of making platform plugins libraries with
>> their own private headers, we can have these apis closer to the
>> platform code, and without lots of plumbing and indirection.
>
> Sounds promising.

I don’t think I’ve written anything down yet on that, so here’s a first stab:

https://bugreports.qt.io/browse/QTBUG-70518

>
>> I think the qtmacextras module in particular should be deprecated
>> ASAP, and will strongly oppose any new APIs added to it.
>
> Use of passive voice - "should be" - perhaps a better plan would be to
> actively submit the patches to make it happen, or file a task in Jira
> for it. Even if there's no release branch ready for them, having
> patches on dev gives relevant folk notice of your intent; and it might
> give a focus for like-minded folk to co-ordinate the pre-requisites of
> that change,

Absolutely, I will try to find some time to deprecate parts of QtMacExtras. I assume I’m still allowed to have opinions on how to proceed on areas that I’m not personally able to take direction action on? 😊

Tor Arne

[Tor Arne Vestbø]

> On 12 Sep 2018, at 12:37, Tor Arne Vestbø <***@qt.io> wrote:
>>
>> Use of passive voice - "should be" - perhaps a better plan would be to
>> actively submit the patches to make it happen, or file a task in Jira
>> for it. Even if there's no release branch ready for them, having
>> patches on dev gives relevant folk notice of your intent; and it might
>> give a focus for like-minded folk to co-ordinate the pre-requisites of
>> that change,
>
> Absolutely, I will try to find some time to deprecate parts of QtMacExtras.

https://codereview.qt-project.org/#/c/239688/

Tor Arne