Re: [Development] Source break policy for function overloads

2016-07-13 Thread Thiago Macieira
Em quarta-feira, 13 de julho de 2016, às 23:29:42 PDT, Richard Moore escreveu: > On 13 July 2016 at 19:10, Marc Mutz wrote: > > Renaming a public inline function of a non-exported class is BC, but SiC > > Type > > (b), so not acceptable. > > ​Good analysis, however isn't the compiler allowed to n

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Richard Moore
On 13 July 2016 at 19:10, Marc Mutz wrote: > Renaming a public inline function of a non-exported class is BC, but SiC > Type > (b), so not acceptable. > ​Good analysis, however isn't the compiler allowed to not inline stuff too which would mean this example is not b/c either. ​ ​Cheers Rich.​

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Marc Mutz
On Wednesday 13 July 2016 18:47:28 Thiago Macieira wrote: > We do have this policy since 5.0 that we have to be careful about > overloads due to the connect syntax. The breakage was accidental and not > intended. > > I did intend to add overloads, as they're nice to use, I just hadn't > consider

Re: [Development] QWebEngine - H.264 playback, proprietary codecs.

2016-07-13 Thread Allan Sandfeld Jensen
On Wednesday 13 July 2016, Steve Schilz wrote: > We are using QWebEngine to drive a hybrid app (Html5 + Javascript + C++) on > windows. According to QWebEngineFeatures Doc, > http://doc.qt.io/qt-5/qtwebengine-features.html#pepper-plugin-api You must > pass a flag to qmake, WEBENGINE_CONFIG+=use_pr

Re: [Development] QWebEngine - H.264 playback, proprietary codecs.

2016-07-13 Thread Thiago Macieira
Em quarta-feira, 13 de julho de 2016, às 16:08:11 PDT, Steve Schilz escreveu: > Would it make sense for QWebEngine to support this codec, in order to be > able to provide ‘out of the box’ (via download at end user’s computer), > support for h.264 playback in tags? If we're able to ship a build wi

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Thiago Macieira
Em quarta-feira, 13 de julho de 2016, às 16:45:05 PDT, Ola Røer Thorsen escreveu: > In my opinion, please try to avoid these overloads as much as possible. That's the current policy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Thiago Macieira
Em quarta-feira, 13 de julho de 2016, às 10:44:13 PDT, Alexander Blasche escreveu: > Hi, > > Yesterday, I stumbled over a break in QtSerialBus due to the addition of new > QTimer::setInterval(..) overloads in qtbase/dev. This was introduced by > > https://codereview.qt-project.org/#/c/160889/ >

[Development] QWebEngine - H.264 playback, proprietary codecs.

2016-07-13 Thread Steve Schilz
We are using QWebEngine to drive a hybrid app (Html5 + Javascript + C++) on windows. According to QWebEngineFeatures Doc, http://doc.qt.io/qt-5/qtwebengine-features.html#pepper-plugin-api You must pass a flag to qmake, WEBENGINE_CONFIG+=use_proprietary_codecs, and build Qt from source yourself

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Ola Røer Thorsen
2016-07-13 16:30 GMT+02:00 Simon Hausmann : > > It all comes down to the question: What impression do we want to give > people when they upgrade to > > a newer version of Qt? > > > In my experience, I first had problems with this when I converted to the new "connect" syntax some years ago and hit

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Simon Hausmann
Hi, I suppose that if this is the first time an overload is added, then the risk of ambiguity exists. It seems that this is the case here. If released API has overloads and a new overload is added, then the caller code using QObject::connect would already use qOverload or similar, right? In

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Giuseppe D'Angelo
Il 13/07/2016 15:55, Simon Hausmann ha scritto: I think if we allow source compatibility breakages like the one here (overloaded slot added), then I think it should require a prominent notice in the changelog / release notes. Note that setInterval is not even a slot (but an overload of start(

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Simon Hausmann
Hi, I think in the interest of our users and the popularity of Qt, the maintenance of source compatibility should be a supremely important goal. That said, breakages of source compatibility for the sake of cleanups appear to have been accepted by approvers in the past. I think if we allow

Re: [Development] [Qt-creator] [FYI] commit/review policy refactored

2016-07-13 Thread Oswald Buddenhagen
On Wed, Jul 13, 2016 at 01:10:20PM +0200, Kai Köhne wrote: > Oswald Buddenhagen wrote: > > On Wed, Jul 13, 2016 at 12:15:44PM +0200, Kai Köhne wrote: > > > "Make sure that your commit matches the Qt Commit Policy. > > > > > > > 1. Invite relevant reviewers. > > > > * Always invite the respective do

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Giuseppe D'Angelo
Il 13/07/2016 12:44, Alexander Blasche ha scritto: While talking to several devs in the office I could not find a congruent opinion on this issue. Do we or even can we care? Do we have a policy? While it would be nice not to add overloads to signals and slots, and we can keep an eye on that,

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Kai Koehne
> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > [...] > We do not have SC promise only BC. We tend to not break SC without > reason, for example we avoid juggling with header files just to "cleanup" > stuff, but definitely we reserve right to a

Re: [Development] Source break policy for function overloads

2016-07-13 Thread Jędrzej Nowacki
On Wednesday 13 of July 2016 10:44:13 Alexander Blasche wrote: > Hi, > > Yesterday, I stumbled over a break in QtSerialBus due to the addition of new > QTimer::setInterval(..) overloads in qtbase/dev. This was introduced by > > https://codereview.qt-project.org/#/c/160889/ > > Unfortunately this

Re: [Development] [Qt-creator] [FYI] commit/review policy refactored

2016-07-13 Thread Kai Koehne
> -Original Message- > From: Qt-creator [mailto:qt-creator-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Wednesday, July 13, 2016 12:49 PM > To: development@qt-project.org; qt-crea...@qt-project.org > Subject: Re: [Qt-creator] [Development] [FYI] comm

Re: [Development] [FYI] commit/review policy refactored

2016-07-13 Thread Oswald Buddenhagen
On Wed, Jul 13, 2016 at 12:15:44PM +0200, Kai Köhne wrote: > The page is obviously written from the viewpoint of a maintainer. I'd > prefer to write It in a less intimidating way to the contributor, and > make it helpful for first time, inexperienced contributors. > first-timers can ask in case of

[Development] Source break policy for function overloads

2016-07-13 Thread Alexander Blasche
Hi, Yesterday, I stumbled over a break in QtSerialBus due to the addition of new QTimer::setInterval(..) overloads in qtbase/dev. This was introduced by https://codereview.qt-project.org/#/c/160889/ Unfortunately this has the undesirable side effect that lines like: q->connect(q, &QModbusClie

Re: [Development] [FYI] commit/review policy refactored

2016-07-13 Thread Kai Koehne
> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Wednesday, July 13, 2016 11:08 AM > To: development@qt-project.org; qt-crea...@qt-project.org > Subject: [Development] [FYI] commit/review polic

Re: [Development] [FYI] commit/review policy refactored

2016-07-13 Thread Oswald Buddenhagen
On Wed, Jul 13, 2016 at 11:57:28AM +0200, Martin Smith wrote: > Sometimes I am listed as a reviewer for a code change in Qt that also involves > documentation changes. The code change is sometimes outside my expertise, but > I > assume I have been included to approve the documentation changes. I a

Re: [Development] [FYI] commit/review policy refactored

2016-07-13 Thread Martin Smith
Sometimes I am listed as a reviewer for a code change in Qt that also involves documentation changes. The code change is sometimes outside my expertise, but I assume I have been included to approve the documentation changes. I always give +1 in such cases. Is that correct? martin

[Development] [FYI] commit/review policy refactored

2016-07-13 Thread Oswald Buddenhagen
just a heads-up that i (finally) split off the review policy from the commit policy. see https://wiki.qt.io/Review_Policy . if you have suggestions for improvement, please discuss them upfront on irc. you're expected to read the document even if you're not interested in actively improving it any t