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
d 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
wrote:
> On Wednesday, 12 September 2018
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
> 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
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
>
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
> 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
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
> 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
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
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
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:
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
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
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]
16 matches
Mail list logo
