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 ca
m 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] Orp
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
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 cou
> 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 wi
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 pl
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 12:
> 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 re
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 wr
> 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
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
alf of Tor Arne Vestbø
Sent: Wednesday, September 12, 2018 10:25:37 AM
To: Samuel Gaist
Cc: development@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,
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
wi
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: q
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 ove
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] https://
18 matches
Mail list logo
