Re: [Development] Use QMetaEnum::keyCount() to initialise array
On 07.01.19 19:50, Tom Isaacson wrote: > I wonder if moc-ng could handle this? > https://woboq.com/blog/moc-with-clang.html Not really, even if it can generate things in a header for templates, it still generates te actual data in a .cpp file. As it was said before, we can't really have the contents of the QMetaObject. Even verdigris does the same (putting the QMetaObject data in the .cpp) One would have to do more research to find out if it is possible. Maybe putting more more data in the QMetaEnum dirrectly. Not sure if this is possible in a binary compatible way. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > -Original Message- > From: Development On Behalf Of Thiago Macieira > Sent: Thursday, January 3, 2019 1:43 AM > To: development@qt-project.org > Subject: Re: [Development] Use QMetaEnum::keyCount() to initialise array > > On Wednesday, 2 January 2019 09:45:29 -02 Thiago Macieira wrote: >> Because the information is not known to the compiler at compile time. > > To be stricter: it *is* know to the compiler, but without a constexpr reflection API, we can't get the information out of the compiler and into code. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New linguist maintainer nomination
On 1/7/19 1:51 PM, Alex Blasche wrote: > After Ossi stepping down as maintainer for Linguist and related tools > (lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a > long history working on Qt and even more specifically with Qt's translation > tools. +1 [insert cunning linguist joke here] Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Jannis Völker for Approver
+1 I trust Jannis with his code and his reviews very much. Disclaimer: we both work for basyskom, sitting door by door. Kind Regards, Frank Am 07.01.19 um 13:35 schrieb Maurice Kalinowski: Hi, I would like to nominate Jannis Völker for approvership. He has been an active contributor to Qt OpcUA mostly since end of 2017. He also has been actively taking care on JIRA, bug fixing and bringing the whole module forward. If you're curious, here is a list of his changes: https://codereview.qt-project.org/#/q/owner:%22Jannis+V%25C3%25B6lker%22,n,z Reviews: https://codereview.qt-project.org/#/q/reviewer:%22Jannis+V%25C3%25B6lker%22,n,z BR, Maurice ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Frank Meerkötter Development Lead basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel : +49 6151 870 589 161 | Fax: +49 6151 - 870 589 162 frank.meerkoet...@basyskom.com | www.basyskom.com Handelsregister: Darmstadt HRB 9352 Geschäftsführung: Heike Ziegler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Use QMetaEnum::keyCount() to initialise array
On Monday, 7 January 2019 10:50:43 PST Tom Isaacson wrote: > I wonder if moc-ng could handle this? > https://woboq.com/blog/moc-with-clang.html As a plugin to Clang, it can do anything. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QAbstractVideoFilter, the pipeline and QImage
I'm trying to implement a QAbstractVideo buffer that uses cv::Mat (or my own custom type, CvMatVideoBuffer or ByteArrayVideoBuffer respectively), but I'm running into a mental block with how this should work. Only map() gives pixel data, I really want a QAbstractVideoBuffer *QVideoFrame::buffer() which I can then cast to my custom type. Generally when I'm fighting Qt in this way, I'm doing something wrong.
I can convert between QImage/cv::Mat with:
cv::Mat qimage_to_mat_cpy(QImage const , bool swap)
{
return qimage_to_mat_ref(const_cast(img), swap).clone();
}
QImage mat_to_qimage_ref(cv::Mat , QImage::Format format)
{
return QImage(mat.data, mat.cols, mat.rows, static_cast(mat.step), format);
}
cv::Mat qimage_to_mat_ref(QImage , int format)
{
return cv::Mat(img.height(), img.width(), format, img.bits(), img.bytesPerLine());
}
Is there an example of how to "properly" use Qt's video pipleline filters, frames, and buffers with OpenCV? I think there should be class(es) that converts a QVideoFrame to a cv::Mat, and one that converts from cv::Mat to QVideoFrame:
filters: [toMat, blur, sobel, houghLines, toVideoFrame]
Many thanks in advance.
Sent: Monday, January 07, 2019 at 10:57 AM
From: "Jason H"
To: "Jason H"
Cc: "Pierre-Yves Siret" , "Qt development mailing list"
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage
I have been thinking about this more, and I think we also need to convert when the pipeline switches between internal formats. This would allow standard filter tooklits to be "a thing" for Qt.
For example, if my pipeline filters are written to use QImage (because scanline() and pixel()) , and someone else's use cv::Mat (OpenCV), alternating between formats is not possible in the same pipeline. I think the panacia is to be able to convert not just at the end, but for any step:
[gauss, sobel, houghLines, final] -> formats: [QVideoFrame->cv::Mat, cv::Mat, cv::Mat->QImage, QImage->QVideoFrame] where each format step is the (inputFormat -> outputFormat)
Just my 0.02BTC.
Sent: Wednesday, January 02, 2019 at 12:33 PM
From: "Jason H"
To: "Pierre-Yves Siret"
Cc: "Qt development mailing list"
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage
Thanks for pointing that out. I guess that could work. It's not as elegant as what I want, where everyhing presents the same way. Now each and every filter has to have
if (flags & QVideoFilterRunnable::LastInChain) {
... generate the frame for the backend per the surfaceFormat
}
As there are many surfaceFormats, that if(){} block is huge, and duplicated in each filter. True, I can create a "final filter" that does this to avoid all that boilerpate code that takes the frame and converts it back to what it needs to be. But what I suggested was Qt should provide this automatically both in the filter chain. The difference is this:
VideoOutput {
filters: [sobel, houghLines]
}
VideoOutput {
filters: [sobel, houghLines, final]
}
Ideally that final filter checks the frame matches what it expects and only if it does not, performs a conversion. Maybe there's a way to register a conversion from a custom type to a QVideoFrame?
Also, if the VideoOutput is not needed* the final filter need not be invoked.
By not needed, I mean the video output element is not visable, or it's area is 0. Sometimes, we want to provide intel about the frames, without affecting them. Currently, this is inherently syncronous, which negatively impacts frame rate.
I should be able to use two (or more) VideoOutputs, one for real-time video display and another for info-only filter pipeline, and these can be distributed across cpu cores. Unfortuantely, the VideoOutput takes over the video source forcing source-output mappings to be 1:1. It would be really nice if it could be 1:N. I experimented with this, and the first VideoOutput is the only one to receive a frame from a source, and the only one with an active filter pipeline. How could I have 3 VideoOutputs, each with it's own filter pipeline and visualize them simulatneously?
Camera { id: camera }
VideoOutput { // only this one works. If I move this after the next one, then that one works.
filters: [sobel, houghLines]
source: camera
}
VideoOutput {
filters: [sobel, houghLines, final]
source: camera
}
So to sum this up:
- Qt should provide automatic frame reconstruction for the final frame (that big if(){} block) (it should be boilerplate)
- A way to register custom format to QVideoFrame reconstruction function
- Allow for multiple VideoOutputs (and filter pipelines) from the same source
-- Maybe an element for no video output pipeline?
Am wrong in thinking any of that doesn't already exist or is a good idea?
Sent: Saturday, December 22, 2018 at 5:10 AM
From: "Pierre-Yves Siret"
To: "Jason H"
Cc: "Qt development mailing list"
Subject: Re:
Re: [Development] Use QMetaEnum::keyCount() to initialise array
I wonder if moc-ng could handle this? https://woboq.com/blog/moc-with-clang.html Tom Isaacson -Original Message- From: Development On Behalf Of Thiago Macieira Sent: Thursday, January 3, 2019 1:43 AM To: development@qt-project.org Subject: Re: [Development] Use QMetaEnum::keyCount() to initialise array On Wednesday, 2 January 2019 09:45:29 -02 Thiago Macieira wrote: > Because the information is not known to the compiler at compile time. To be stricter: it *is* know to the compiler, but without a constexpr reflection API, we can't get the information out of the compiler and into code. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QAbstractVideoFilter, the pipeline and QImage
I have been thinking about this more, and I think we also need to convert when the pipeline switches between internal formats. This would allow standard filter tooklits to be "a thing" for Qt.
For example, if my pipeline filters are written to use QImage (because scanline() and pixel()) , and someone else's use cv::Mat (OpenCV), alternating between formats is not possible in the same pipeline. I think the panacia is to be able to convert not just at the end, but for any step:
[gauss, sobel, houghLines, final] -> formats: [QVideoFrame->cv::Mat, cv::Mat, cv::Mat->QImage, QImage->QVideoFrame] where each format step is the (inputFormat -> outputFormat)
Just my 0.02BTC.
Sent: Wednesday, January 02, 2019 at 12:33 PM
From: "Jason H"
To: "Pierre-Yves Siret"
Cc: "Qt development mailing list"
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage
Thanks for pointing that out. I guess that could work. It's not as elegant as what I want, where everyhing presents the same way. Now each and every filter has to have
if (flags & QVideoFilterRunnable::LastInChain) {
... generate the frame for the backend per the surfaceFormat
}
As there are many surfaceFormats, that if(){} block is huge, and duplicated in each filter. True, I can create a "final filter" that does this to avoid all that boilerpate code that takes the frame and converts it back to what it needs to be. But what I suggested was Qt should provide this automatically both in the filter chain. The difference is this:
VideoOutput {
filters: [sobel, houghLines]
}
VideoOutput {
filters: [sobel, houghLines, final]
}
Ideally that final filter checks the frame matches what it expects and only if it does not, performs a conversion. Maybe there's a way to register a conversion from a custom type to a QVideoFrame?
Also, if the VideoOutput is not needed* the final filter need not be invoked.
By not needed, I mean the video output element is not visable, or it's area is 0. Sometimes, we want to provide intel about the frames, without affecting them. Currently, this is inherently syncronous, which negatively impacts frame rate.
I should be able to use two (or more) VideoOutputs, one for real-time video display and another for info-only filter pipeline, and these can be distributed across cpu cores. Unfortuantely, the VideoOutput takes over the video source forcing source-output mappings to be 1:1. It would be really nice if it could be 1:N. I experimented with this, and the first VideoOutput is the only one to receive a frame from a source, and the only one with an active filter pipeline. How could I have 3 VideoOutputs, each with it's own filter pipeline and visualize them simulatneously?
Camera { id: camera }
VideoOutput { // only this one works. If I move this after the next one, then that one works.
filters: [sobel, houghLines]
source: camera
}
VideoOutput {
filters: [sobel, houghLines, final]
source: camera
}
So to sum this up:
- Qt should provide automatic frame reconstruction for the final frame (that big if(){} block) (it should be boilerplate)
- A way to register custom format to QVideoFrame reconstruction function
- Allow for multiple VideoOutputs (and filter pipelines) from the same source
-- Maybe an element for no video output pipeline?
Am wrong in thinking any of that doesn't already exist or is a good idea?
Sent: Saturday, December 22, 2018 at 5:10 AM
From: "Pierre-Yves Siret"
To: "Jason H"
Cc: "Qt development mailing list"
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage
The filter pipeline starts with a file or camera device, and various filters are applied sequentially to frames. However I spend a lot of time converting frames to QImages for analysis and painting. I'm hoping there's a faster way to do this. Some of the filters alter the frame, some just provide information about the frame.
But each time, I have to unpack a QVideoFrame's pixels and make sure the filter can process that pixel format, or convert it to one format that it expects. I'm getting processing times of 55msec on my mackbook pro, which give me 18FPS from a 25FPS video, so I'm dropping frames. I am starting to think the ideal would be to have some "Box of Pixels" data structure that both QImage and QVideoFrame can use. But for now, I convert each frame to a QImage at each stage of the pipeline.
I'm not that versed in image manipulation but isn't that the point of the QVideoFilterRunnable::LastInChain flag ?
Quoting the doc:
"flags contains additional information about the filter's invocation. For example the LastInChain flag indicates that the filter is the last in a VideoOutput's associated filter list. This can be very useful in cases where multiple filters are chained together and the work is performed on image data in some custom format (for example a format specific to some computer vision
[Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.
Hi, I am requesting a repository for shared components between Qt Creator and Qt3DStudio. The Qt Company is developing shared components for Qt Quick Designer/Qt Design Studio and Qt3D Studio. The first component we develope is a curve editor for animations, but there are more shared components planned. The name of the repository should be 'qtdesigntools' and license of these components will be GPLV3. I will be responsible. Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.
Hi, I am requesting a repository for shared components between Qt Creator and Qt3DStudio. The Qt Company is developing shared components for Qt Quick Designer/Qt Design Studio and Qt3D Studio. The first component we develope is a curve editor for animations, but there are more shared components planned. The name of the repository should be 'qtdesigntools' and license of these components will be GPLV3. I will be responsible. Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Jannis Völker for Approver
+1 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.
Hi, I am requesting a repository for shared components between Qt Creator and Qt3DStudio. The Qt Company is developing shared components for Qt Quick Designer/Qt Design Studio and Qt3D Studio. The first component we develope is a curve editor for animations, but there are more shared components planned. The name of the repository should be 'qtdesigntools' and license of these components will be GPLV3. I will be responsible. Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier wrote: >> But in this day and age where docker works everywhere I don't really >> see the point in fighting to make windows behave like a proper unix >> system, just write a dockerscript that does your cross-compile job. Christian Gagneraud (17 December 2018 13:50) > What do you mean by 'everywhere'? Native Windows dockers are still > experimental, and i haven't heard of native MacOS docker yet (might > have missed smth). I can't speak for "everywhere"; but we've found that docker works cross-platform enough for the needs of our on-going work to replace the monolithic net-test-server currently used to test network-related code: https://codereview.qt-project.org/240564 - macOS https://codereview.qt-project.org/246535 - MS-Win So there is at least some grounds to hope docker can solve the cross-compilation problems Jean-Michaël had in mind. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New linguist maintainer nomination
On Mon, 7 Jan 2019 12:51:25 + Alex Blasche wrote: > After Ossi stepping down as maintainer for Linguist and related tools > (lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a > long history working on Qt and even more specifically with Qt's translation > tools. +1 (Full disclosure: He's in charge of approving my vacation days.) Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Jannis Völker for Approver
> >From: Development on behalf of Maurice >Kalinowski >I would like to nominate Jannis Völker for approvership. He has been an active >contributor to Qt OpcUA mostly since end of 2017. >He also has been actively taking care on JIRA, bug fixing and bringing the >whole module forward. >If you're curious, here is a list of his changes: > >https://codereview.qt-project.org/#/q/owner:%22Jannis+V%25C3%25B6lker%22,n,z >Reviews: >https://codereview.qt-project.org/#/q/reviewer:%22Jannis+V%25C3%25B6lker%22,n,z +1 -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New linguist maintainer nomination
+1. AFAIRC, Kai's hands were already on this stuff a long time ago, dating Trolltech times :) From: Development on behalf of Alex Blasche Sent: Monday, January 7, 2019 1:51:25 PM To: development Subject: [Development] New linguist maintainer nomination Hi, After Ossi stepping down as maintainer for Linguist and related tools (lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a long history working on Qt and even more specifically with Qt's translation tools. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New linguist maintainer nomination
> On 7 Jan 2019, at 13:51, Alex Blasche wrote: > > Hi, > > After Ossi stepping down as maintainer for Linguist and related tools > (lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a > long history working on Qt and even more specifically with Qt's translation > tools. > > -- > Alex > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development Hi, +1 Best regards Samuel -- Samuel Gaist Research And Development Engineer Idiap Research Institute, Centre du Parc, CP 592, CH-1920 Martigny http://www.idiap.ch/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] New linguist maintainer nomination
Hi, After Ossi stepping down as maintainer for Linguist and related tools (lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a long history working on Qt and even more specifically with Qt's translation tools. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Jannis Völker for Approver
Hi, I would like to nominate Jannis Völker for approvership. He has been an active contributor to Qt OpcUA mostly since end of 2017. He also has been actively taking care on JIRA, bug fixing and bringing the whole module forward. If you're curious, here is a list of his changes: https://codereview.qt-project.org/#/q/owner:%22Jannis+V%25C3%25B6lker%22,n,z Reviews: https://codereview.qt-project.org/#/q/reviewer:%22Jannis+V%25C3%25B6lker%22,n,z BR, Maurice ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
Just answered. As I said my email does not functioning (disabled), so did not see the question. Actually initial bug description contains full url. -- Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 07.01.2019, 10:44, "Denis Kormalev" : > I would at least suggest to answer Ekkehard and BogDan in QTBUG-72687. They > are waiting for 4 days for answer from you. > > -- > Regards, > Denis Kormalev > >> On Jan 7, 2019, at 12:08 AM, Aleksey Kontsevich wrote: >> >> Very strange. May I move them to P0-Blocker then? :) >> >> -- >> Best regards, >> Aleksey >> Linked in https://www.linkedin.com/in/alekseykontsevich >> >> 07.01.2019, 07:37, "Jani Heikkinen" : -Original Message- From: Development On Behalf Of Aleksey Kontsevich Sent: lauantai 5. tammikuuta 2019 12.23 To: ekke ; developm...@lists.qt-project.org Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started Hi, What about QTBUG-72687 and QTBUG-72227? >>> >>> QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry. >>> >>> br, >>> Jani >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
I would at least suggest to answer Ekkehard and BogDan in QTBUG-72687. They are waiting for 4 days for answer from you. -- Regards, Denis Kormalev > On Jan 7, 2019, at 12:08 AM, Aleksey Kontsevich wrote: > > Very strange. May I move them to P0-Blocker then? :) > > -- > Best regards, > Aleksey > Linked in https://www.linkedin.com/in/alekseykontsevich > > > 07.01.2019, 07:37, "Jani Heikkinen" : >>> -Original Message- >>> From: Development On Behalf Of >>> Aleksey Kontsevich >>> Sent: lauantai 5. tammikuuta 2019 12.23 >>> To: ekke ; developm...@lists.qt-project.org >>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' >>> started >>> >>> Hi, >>> >>> What about QTBUG-72687 and QTBUG-72227? >> >> QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry. >> >> br, >> Jani > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
I see, will do now. My email is blocked so did not see issue needs more info. -- Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 07.01.2019, 10:29, "Andy Shaw" : > Unfortunately no ( > > Though if you want them to be addressed sooner, then at least providing the > missing info for QTBUG-72687 would help in that case at least. > > Andy > > -Opprinnelig melding- > Fra: Development på vegne av Aleksey > Kontsevich > Dato: mandag 7. januar 2019 09:23 > Til: Jani Heikkinen , ekke , > "developm...@lists.qt-project.org" > Emne: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started > > Very strange. May I move them to P0-Blocker then? :) > > -- > Best regards, > Aleksey > Linked in https://www.linkedin.com/in/alekseykontsevich > > 07.01.2019, 07:37, "Jani Heikkinen" : > >> -Original Message- > >> From: Development On Behalf Of > >> Aleksey Kontsevich > >> Sent: lauantai 5. tammikuuta 2019 12.23 > >> To: ekke ; developm...@lists.qt-project.org > >> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' > >> started > >> > >> Hi, > >> > >> What about QTBUG-72687 and QTBUG-72227? > > > > QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry. > > > > br, > > Jani > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
Unfortunately no ( Though if you want them to be addressed sooner, then at least providing the missing info for QTBUG-72687 would help in that case at least. Andy -Opprinnelig melding- Fra: Development på vegne av Aleksey Kontsevich Dato: mandag 7. januar 2019 09:23 Til: Jani Heikkinen , ekke , "developm...@lists.qt-project.org" Emne: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started Very strange. May I move them to P0-Blocker then? :) -- Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 07.01.2019, 07:37, "Jani Heikkinen" : >> -Original Message- >> From: Development On Behalf Of >> Aleksey Kontsevich >> Sent: lauantai 5. tammikuuta 2019 12.23 >> To: ekke ; developm...@lists.qt-project.org >> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' >> started >> >> Hi, >> >> What about QTBUG-72687 and QTBUG-72227? > > QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry. > > br, > Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
Am 07.01.19 um 09:08 schrieb Aleksey Kontsevich: > Very strange. Aleksey, it would help if you would answer the open questions at QTBUG-72687 ekke > > -- > Best regards, > Aleksey > Linked in https://www.linkedin.com/in/alekseykontsevich > > > 07.01.2019, 07:37, "Jani Heikkinen" : >>> -Original Message- >>> From: Development On Behalf Of >>> Aleksey Kontsevich >>> Sent: lauantai 5. tammikuuta 2019 12.23 >>> To: ekke ; developm...@lists.qt-project.org >>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' >>> started >>> >>> Hi, >>> >>> What about QTBUG-72687 and QTBUG-72227? >> QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry. >> >> br, >> Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
Very strange. May I move them to P0-Blocker then? :) -- Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 07.01.2019, 07:37, "Jani Heikkinen" : >> -Original Message- >> From: Development On Behalf Of >> Aleksey Kontsevich >> Sent: lauantai 5. tammikuuta 2019 12.23 >> To: ekke ; developm...@lists.qt-project.org >> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' >> started >> >> Hi, >> >> What about QTBUG-72687 and QTBUG-72227? > > QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry. > > br, > Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
