Re: [Development] Qt 4.8: disabling the CI and closing for anything except security fixes
On 14/08/15 08:25, "Sarajärvi Tony" wrote: >> -Original Message- >> From: development-bounces+tony.sarajarvi=theqtcompany.com@qt- >> project.org [mailto:development- >> bounces+tony.sarajarvi=theqtcompany@qt-project.org] On Behalf Of >> Thiago Macieira >> Sent: 14. elokuuta 2015 3:40 >> To: development@qt-project.org >> Subject: [Development] Qt 4.8: disabling the CI and closing for anything >> except security fixes >> >> I recently tried to fix a very simple bug in Qt 4.8 but I can't get the >>change >> to integrate because the CI seems to have fallen into disrepair. >> >> Instead of using valuable QA time in fixing the CI for 4.8, I'd like to >>propose >> instead that we simply disable the CI for that version and close Qt 4.8 >>for >> any submission except security fixes. Gerrit would be configured for >>pure >> merging instead of staging, but that would only be enabled to Gerrit >>admins >> and they'd only do it after confirmation from the security team >>(security@qt- >> project.org). >> >> Any objections? > >Not from me ;) Agreed. This sounds like the best way to continue. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8: disabling the CI and closing for anything except security fixes
> -Original Message- > From: development-bounces+tony.sarajarvi=theqtcompany.com@qt- > project.org [mailto:development- > bounces+tony.sarajarvi=theqtcompany@qt-project.org] On Behalf Of > Thiago Macieira > Sent: 14. elokuuta 2015 3:40 > To: development@qt-project.org > Subject: [Development] Qt 4.8: disabling the CI and closing for anything > except security fixes > > I recently tried to fix a very simple bug in Qt 4.8 but I can't get the change > to integrate because the CI seems to have fallen into disrepair. > > Instead of using valuable QA time in fixing the CI for 4.8, I'd like to > propose > instead that we simply disable the CI for that version and close Qt 4.8 for > any submission except security fixes. Gerrit would be configured for pure > merging instead of staging, but that would only be enabled to Gerrit admins > and they'd only do it after confirmation from the security team (security@qt- > project.org). > > Any objections? Not from me ;) -Tony > -- > 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] Qt 4.8: disabling the CI and closing for anything except security fixes
I recently tried to fix a very simple bug in Qt 4.8 but I can't get the change to integrate because the CI seems to have fallen into disrepair. Instead of using valuable QA time in fixing the CI for 4.8, I'd like to propose instead that we simply disable the CI for that version and close Qt 4.8 for any submission except security fixes. Gerrit would be configured for pure merging instead of staging, but that would only be enabled to Gerrit admins and they'd only do it after confirmation from the security team (security@qt- project.org). Any objections? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module Request: QtGeniviExtras
On Thursday 13 August 2015 10:29:31 Turunen Tuukka wrote: > Like Thiago and other have pointed out we of course would like to have the > content of the new module well suited for Qt before it can become part of a > Qt release. I think the best way to achieve this is to do the work within > the Qt Project and Qt repositories, after which we can then at some point > have a module that is well fit for Qt and its purpose. To be clear: I'm not against the creation of a repository for GENIVI extra functionality. I am for it. I am, however, questioning the design of the API that Dominik presented. -- 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] New Module Request: QtGeniviExtras
On Thursday 13 August 2015 10:32:42 Dominik Holland wrote: > > Another option is to split the category name by the dots and select the > > first letter of each section. So "qt.qpa.windows" is "qqw", while > > "qt.widgets.gestures" is "qwg". > > Using that approach i'm already getting 4 clashes of the 10 categories > we use in one of our projects, so i don't think this is the best > approach to this. And for me that also sounds like magic which no Qt > User would understand, how do you think to document that ? That's what you get when the namespace is so small. Blame the DLT designers for the limitations they introduced, not me. > > You can also add a configuration item to the environment variable or > > qtlogging.ini, which provides a separate, shorter name. QtGeniviExtras > > could provide an API to set it programmatically. > > Ok but once you forget to provide the env variable or the logging ini > all your logging is lost as DLT don't accept logs without a category. It uses the heuristic short name as above. This would allow logging for categories that have no specific DLT short name, such as just about all the existing Qt code out there right now. > Also this looks like something which is suitable for a developer, but > not for a production system. Hence the QtGenivExtras way of programmatically setting a short name for a category. We can also introduce another Q_LOGGING_CATEGORY2 macro which can take extra parameters and settings. We may also in the process get rid of some ugly const_cast I've seen show up in the code. > > But this starts with writing a DLT backend inside QtCore first. > > Looking at how the logging backends are currently integrated in qtcore > this sounds like the worst solution of all, as it needs a configure time > check to enable the DLT logging and it would enable it for all Qt > libraries and examples. Correct. I don't understand why this would be bad. Any Qt that you run on a Genivi system is likely to be compiled by that GENIVI-compliant distribution, not the one you download from qt.io or from your regular Linux distro. That distribution can enable the DLT backend. Getting the output for all libraries and examples seems like a benefit to me. If you don't want the debugging output in production, you can disable it at compile time (QT_NO_DEBUG_OUTPUT) or at runtime. Regular logging could remain at info and warning levels. > For development this seems to be very unhandy. Please explain. If you're developing a simulated system, you get the output in Creator like any other regular logging output. If you run that application on the target device, it becomes DLT. Sounds like win-win to me. > I think the back-channel is really one of the things you can't or better > you don't want to do in a qtcore backend. What is the back channel? > Thiago i totally understand what you are up to and i agree that it would > be good if it could be easily integrated as a logging backend. But in my > opinion this is really unpractical, it introduces some magic and a > special configure time check. I agree it introduces some magic, but only because of the limitations of the logging device in question. As for the configure-time check, it's no different than slog, journald, syslog or the Apple log, the latter of which was proposed but never integrated. > IMHO the users of QtGeniviExtras and the DLT logging are totally aware > of how the system works and want to have full control over it. > DLT is only known in the automotive space and there it's only used for > GENIVI linux based systems. So i think we talk about a logging solution > which 90% of the qt community don't know or won't ever use. I really > don't think this is something which should be integrated into qtcore, > and should be totally fine to live in it's own repository and in the end > it's very similar of what the other extra repositories currently do, > components which doesn't fit and are platform specific are in extras While I understand that, my opinion is that Qt is supposed to make your life easier. If we can integrate with the current system, we should. There's a reason why the type converters to CoreFoundation types are in QtCore, not in QtMacExtras. We don't have to achieve 100% support either. Qt's goals is 90% easy, 9% doable. The way I see it, those 90% match integrating it into QtCore, with the 9% extra in the QtGeniviExtras module. The 1% remaining is out of scope for Qt. If you really need that, you can always just use DLT directly since, after all, it's all native code. -- 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] [RFC] decommissioning the qtonpi mailing list
On 13.08.2015 11:47, Oswald Buddenhagen wrote: > moin, > > the qtonpi mailing list didn't have a single message in close to a year; > interest@ and development@ serve the remaining needs much better at this > point. > to cut down maintenance effort, i'd like to shut the list down, leaving > only the archives intact. objections? > > if you want to "nominate" other lists which have outlived their purpose, > go ahead. I nominate j...@qt-project.org and g...@qt-project.org -- Sergio Ahumada sahum...@texla.cl ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [QML][Multimedia] Multiple video outputs from one Camera
Hi all.
Is it possible to show a video from the one Camera to multiple VideoOutputs?
E.g. this code:
import QtQuick 2.4
import QtMultimedia 5.4
Rectangle {
id: root
Camera { id: cam }
Column {
VideoOutput { source: cam; width: 50; height: 50 }
VideoOutput { source: cam; width: 50; height: 50 }
}
}
shows only one video on the last output, and reports the error:
{quote}
bool QDeclarativeVideoOutput::createBackend(QMediaService*) Media
service has neither renderer nor window control available.
{quote}
BR,
Denis
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module Request: QtGeniviExtras
> -Original Message- > From: development-bounces+tuukka.turunen=theqtcompany.com@qt- > project.org [mailto:development- > bounces+tuukka.turunen=theqtcompany@qt-project.org] On Behalf Of > Dominik Holland > Sent: 13. elokuuta 2015 12:37 > To: André Somers > Cc: development@qt-project.org > Subject: Re: [Development] New Module Request: QtGeniviExtras > > > > On 08/13/2015 11:08 AM, André Somers wrote: > > > > > >> IMHO the users of QtGeniviExtras and the DLT logging are totally > >> aware of how the system works and want to have full control over it. > >> DLT is only known in the automotive space and there it's only used > >> for GENIVI linux based systems. So i think we talk about a logging > >> solution which 90% of the qt community don't know or won't ever use. > >> I really don't think this is something which should be integrated > >> into qtcore, and should be totally fine to live in it's own > >> repository and in the end it's very similar of what the other extra > >> repositories currently do, components which doesn't fit and are > >> platform specific are in extras > >> > > > > Just wondering... If so you expect so few users to use this, what is the > benefit of having this as a Qt module? Would it not be better to keep things > that only users from specialized niche markets use in specialized libs aimed > at those users? > > > > André > > > > But's what i'm targeting, the module is meant for these users and it will > contain multiple specialized libs. > > The benefit of having it as a module is that it can use the same build > infrastructure, it's shipped with Qt, integrated in qmake/cmake, using the > same Documentation. It should be part of Qt, but it's only needed on specific > platforms, like all the other extra repositories. I think nobody cares about > the > qtwinextras beside the people developing for it. > > The module shouldn't be contained in any Desktop Installer or on mobile > platforms, it's just available on automotive platforms and their SDKs > I think it is fine to create the requested repo for new module. Depending on the need it can then either be included or not be included in the release packages. It is better to keep these enablers within the Qt systems than in a separate location somewhere. Like Thiago and other have pointed out we of course would like to have the content of the new module well suited for Qt before it can become part of a Qt release. I think the best way to achieve this is to do the work within the Qt Project and Qt repositories, after which we can then at some point have a module that is well fit for Qt and its purpose. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use QT_DEPRECATED_SINCE macro for specific enum values
But it has actually been used to deprecate single enum values. Here is an
example from QTextFormat:
class Q_GUI_EXPORT QTextFormat
{
Q_GADGET
public:
enum FormatType {
InvalidFormat = -1,
BlockFormat = 1,
CharFormat = 2,
ListFormat = 3,
#if QT_DEPRECATED_SINCE(5, 3)
TableFormat = 4,
#endif
FrameFormat = 5,
UserFormat = 100
};
.cpp
/*!
\enum QTextFormat::FormatType
This enum describes the text item a QTextFormat object is formatting.
\value InvalidFormat An invalid format as created by the default
constructor
\value BlockFormat The object formats a text block
\value CharFormat The object formats a single character
\value ListFormat The object formats a list
\omitvalue TableFormat Unused Value, a table's FormatType is FrameFormat.
\value FrameFormat The object formats a frame
\value UserFormat
\sa QTextCharFormat, QTextBlockFormat, QTextListFormat,
QTextTableFormat, type()
*/
martin
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Thiago Macieira
Sent: Wednesday, August 12, 2015 11:06 PM
To: development@qt-project.org
Subject: Re: [Development] Use QT_DEPRECATED_SINCE macro for specific enum
values
On Wednesday 12 August 2015 22:12:43 Denis Shienkov wrote:
> So, my question is: how to deprecate the specific enum value with a
> right way for all compilers/platforms?
Don't do it. There's no portable way yet. Maybe in a year or two we can
introduce a macro for it.
--
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
[Development] [RFC] decommissioning the qtonpi mailing list
moin, the qtonpi mailing list didn't have a single message in close to a year; interest@ and development@ serve the remaining needs much better at this point. to cut down maintenance effort, i'd like to shut the list down, leaving only the archives intact. objections? if you want to "nominate" other lists which have outlived their purpose, go ahead. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module Request: QtGeniviExtras
On 08/13/2015 11:08 AM, André Somers wrote: > > >> IMHO the users of QtGeniviExtras and the DLT logging are totally aware >> of how the system works and want to have full control over it. >> DLT is only known in the automotive space and there it's only used for >> GENIVI linux based systems. So i think we talk about a logging solution >> which 90% of the qt community don't know or won't ever use. I really >> don't think this is something which should be integrated into qtcore, >> and should be totally fine to live in it's own repository and in the end >> it's very similar of what the other extra repositories currently do, >> components which doesn't fit and are platform specific are in extras >> > > Just wondering... If so you expect so few users to use this, what is the > benefit of having this as a Qt module? Would it not be better to keep things > that only users from specialized niche markets use in specialized libs aimed > at those users? > > André > But's what i'm targeting, the module is meant for these users and it will contain multiple specialized libs. The benefit of having it as a module is that it can use the same build infrastructure, it's shipped with Qt, integrated in qmake/cmake, using the same Documentation. It should be part of Qt, but it's only needed on specific platforms, like all the other extra repositories. I think nobody cares about the qtwinextras beside the people developing for it. The module shouldn't be contained in any Desktop Installer or on mobile platforms, it's just available on automotive platforms and their SDKs -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holl...@pelagicore.com www.pelagicore.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module Request: QtGeniviExtras
> IMHO the users of QtGeniviExtras and the DLT logging are totally aware > of how the system works and want to have full control over it. > DLT is only known in the automotive space and there it's only used for > GENIVI linux based systems. So i think we talk about a logging solution > which 90% of the qt community don't know or won't ever use. I really > don't think this is something which should be integrated into qtcore, > and should be totally fine to live in it's own repository and in the end > it's very similar of what the other extra repositories currently do, > components which doesn't fit and are platform specific are in extras > Just wondering... If so you expect so few users to use this, what is the benefit of having this as a Qt module? Would it not be better to keep things that only users from specialized niche markets use in specialized libs aimed at those users? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module Request: QtGeniviExtras
On 08/12/2015 04:36 PM, Thiago Macieira wrote: > On Wednesday 12 August 2015 14:26:26 Robert Griebl wrote: Every LoggingCategory (In DLT it's called Context) needs to have a 3 characters long unique identifier and a Description. >>> >>> Stupid API limitation. Can you convince GENIVI to get rid of the >>> 3-character identifier requirement? It should be an arbitrarily-long >>> string, in which case we can use the logging category itself. >> >> Again - calling other APIs stupid does not help. And no - this is an >> industry standard which cannot easily change, because Qt has a different >> logging API. Besides: have you tried yet to get changes into Genivi >> components? Good luck with that -- we tried to fix a few much bigger >> problems upstream and it ended in uphill battles you don't want to fight. > > This and... > >> >>> qt_hash(the category name) then base64url-encode the result and cut to 3 >>> characters. >> >> And this will be (a) unique and (b) human readable in the DLT viewer? >> (yes even 3 characters can be human readable) > > ... human readable do not go hand-in-hand. If you have 3 letters for a whole > bunch of categories, then by definition it's neither unique nor human > readable. > So my suggestion seems right on the money and it's reasonably unique -- it > provides for 18 bits of data, while most 3-letter human text is around 15 or > 16 bits. > > Another option is to split the category name by the dots and select the first > letter of each section. So "qt.qpa.windows" is "qqw", while > "qt.widgets.gestures" is "qwg". Using that approach i'm already getting 4 clashes of the 10 categories we use in one of our projects, so i don't think this is the best approach to this. And for me that also sounds like magic which no Qt User would understand, how do you think to document that ? > > You can also add a configuration item to the environment variable or > qtlogging.ini, which provides a separate, shorter name. QtGeniviExtras could > provide an API to set it programmatically. Ok but once you forget to provide the env variable or the logging ini all your logging is lost as DLT don't accept logs without a category. Also this looks like something which is suitable for a developer, but not for a production system. The DLT logging is not something which is disabled in the production. > > But this starts with writing a DLT backend inside QtCore first. Looking at how the logging backends are currently integrated in qtcore this sounds like the worst solution of all, as it needs a configure time check to enable the DLT logging and it would enable it for all Qt libraries and examples. For development this seems to be very unhandy. > >> > By the way, doesn't GENIVI require systemd and thus journald anyway? >> > Why do they have their own logging mechanism? >> >> Did you read the part about the back-channel from the DLT-Viewer to the >> application. But that is besides the point: DLT is used in much more >> than just systemd based IVI systems: > > That's where my ignorance of DLT is. I was assuming it was created by GENIVI, > recently. You're telling me it's an old protocol. > I think it was one of the first GENIVI components and GENIVI is around for quite some years. I doubt that it's likely that they will the protocol. I think the back-channel is really one of the things you can't or better you don't want to do in a qtcore backend. Thiago i totally understand what you are up to and i agree that it would be good if it could be easily integrated as a logging backend. But in my opinion this is really unpractical, it introduces some magic and a special configure time check. IMHO the users of QtGeniviExtras and the DLT logging are totally aware of how the system works and want to have full control over it. DLT is only known in the automotive space and there it's only used for GENIVI linux based systems. So i think we talk about a logging solution which 90% of the qt community don't know or won't ever use. I really don't think this is something which should be integrated into qtcore, and should be totally fine to live in it's own repository and in the end it's very similar of what the other extra repositories currently do, components which doesn't fit and are platform specific are in extras -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holl...@pelagicore.com www.pelagicore.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
