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
> 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 op
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
12 matches
Mail list logo
