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
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.
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
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
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
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
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/
>
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
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
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
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(
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
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
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,
> -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
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
> -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
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
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
> -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
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
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
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
23 matches
Mail list logo