Re: [Development] Orphan modules

[Sune Vuorela]

On 2018-09-12, Gatis Paeglis  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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[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  on 
behalf of Jean-Michaël Celerier 
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=QX11Info+NOT+tst_QX11Info+NOT+QT_END_LICENSE=Code


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


On Thu, Sep 13, 2018 at 1:41 AM Thiago Macieira 
mailto:thiago.macie...@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



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

Re: [Development] Orphan modules

[Jean-Michaël Celerier]

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


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


On Thu, Sep 13, 2018 at 1:41 AM Thiago Macieira 
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
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[Tor Arne Vestbø]

> On 12 Sep 2018, at 18:52, Lisandro Damián Nicanor Pérez Meyer 
>  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 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[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  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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[Tor Arne Vestbø]

> On 12 Sep 2018, at 12:37, Tor Arne Vestbø  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 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[Tor Arne Vestbø]

On 12 Sep 2018, at 11:02, Edward Welbourne  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 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[Morten Sørvig]

> On 12 Sep 2018, at 11:02, Edward Welbourne  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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[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  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  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
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[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  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
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development





signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[Lars Knoll]

On 31 Aug 2018, at 02:06, Chris Adams 
mailto:chris.ad...@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
mailto:edward.welbou...@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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Orphan modules

[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
 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
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development