On 13/05/2014 16:47, Thiago Macieira wrote:
> Em ter 13 maio 2014, às 09:57:59, Knoll Lars escreveu:
>>> That won't help unless we also disable the revdep for QtQuick, as QtQuick
>>> depends on QtNetwork.
>> That doesn’t mean we need to run the network tests as a revdep as well.
> Then the problem
On Tue, May 13, 2014 at 3:06 PM, Oswald Buddenhagen <
oswald.buddenha...@digia.com> wrote:
> On Tue, May 13, 2014 at 12:59:10PM -0500, Keith Gardner wrote:
> > > but then there is also the semantical perspective. keith's last
> proposal
> > > i saw considered only numerical segments specially.
> >
Em ter 13 maio 2014, às 12:36:02, achart...@fastmail.fm escreveu:
> Also, with the QMAKE_DEFAULT_INCDIRS approach, is the path
> addition logic recursive (i.e., -isystem will apply to all subfolders)
> or do child folders need to be listed explicitly (I'm hoping it's
> recursive)?
Yes, it's recurs
Em ter 13 maio 2014, às 12:28:11, achart...@fastmail.fm escreveu:
> Hi all,
>
> I would like to enable the -Weverything and -Werror Clang compiler flags
> for my application code to treat all warnings as errors.
Please note that Qt compiles mostly cleanly with -Wall -Wextra -Werror. We do
not su
On Tue, May 13, 2014 at 12:59:10PM -0500, Keith Gardner wrote:
> > but then there is also the semantical perspective. keith's last proposal
> > i saw considered only numerical segments specially.
>
> Did you intend to say suffix? What I wrote on May 11th spoke specifically
> to the suffix compare
On Tue, May 13, 2014 at 05:30:43PM +0200, Ulf Hermann wrote:
> > Please create a new module. This doesn't need to be in qtbase.
>
> Is anyone opposed to keeping this in a separate qtdebugsupport.git
> repository, then?
I am.
At the very least, this is still missing an explanation what actual
pr
Hi all,
It looks like Thiago Macieira committed a fix for this back in January
(just add paths to QMAKE_DEFAULT_INCDIRS). I am currently using Qt
5.2.1. Does this mean that this fix is present in the upcoming Qt 5.3
release? Also, with the QMAKE_DEFAULT_INCDIRS approach, is the path
addition logic
Hi all,
I would like to enable the -Weverything and -Werror Clang compiler flags
for my application code to treat all warnings as errors. Unfortunately,
Qt itself generates a large number of warnings. I would like to suppress
the warnings generated for Qt code but have Clang report all the
warning
Em ter 13 maio 2014, às 19:13:56, Oswald Buddenhagen escreveu:
> > If you think the QVersion constructor should be strict, I won't disagree.
> > Then we should have a QVersion::fromUserInput, like the QUrl version,
> > which is lax and has heuristics.
>
> that would work from an api perspective.
>
>
> but then there is also the semantical perspective. keith's last proposal
> i saw considered only numerical segments specially.
Did you intend to say suffix? What I wrote on May 11th spoke specifically
to the suffix compare:
>From what I have found, there are some key words that can be used
On Tue, May 13, 2014 at 09:38:03AM -0700, Thiago Macieira wrote:
> Em ter 13 maio 2014, às 18:26:32, Oswald Buddenhagen escreveu:
> > the user has complete control over the input of qversion, and can apply
> > any transformations which his use case may require. also, the effort
> > would be quite t
>> Is anyone opposed to keeping this in a separate qtdebugsupport.git
>> repository, then?
>
> With what compatibility promises regarding code and protocol?
I would promise source and binary compatibility and backwards as well as
forward compatibility of the protocol. At the same time I would pub
Tirsdag 13. mai 2014 06.23.46 skrev Kalinowski Maurice:
> > >The rest of the libraries in qtbase are really base stuff.
> >
> >
> > Actually I was thinking about splitting a few more things out. In addition
> > to
the ones mentioned above, I believe we would benefit from splitting
> > QtNetwork
Em ter 13 maio 2014, às 18:26:32, Oswald Buddenhagen escreveu:
> On Tue, May 13, 2014 at 08:51:09AM -0700, Thiago Macieira wrote:
> > Em ter 13 maio 2014, às 17:47:59, Oswald Buddenhagen escreveu:
> > > the analogy is entirely bogus. the thresholds for usefulness and the
> > > user's ability to man
On Tue, May 13, 2014 at 08:51:09AM -0700, Thiago Macieira wrote:
> Em ter 13 maio 2014, às 17:47:59, Oswald Buddenhagen escreveu:
> > the analogy is entirely bogus. the thresholds for usefulness and the
> > user's ability to manipulate the input into something the qt code can
> > work with are enti
Em ter 13 maio 2014, às 17:47:59, Oswald Buddenhagen escreveu:
> On Tue, May 13, 2014 at 07:43:18AM -0700, Thiago Macieira wrote:
> > Em ter 13 maio 2014, às 11:58:15, Oswald Buddenhagen escreveu:
> > > what is the added value of hard-coding arbitrary policies (and
> > > thereby restricting possibl
On Tue, May 13, 2014 at 07:43:18AM -0700, Thiago Macieira wrote:
> Em ter 13 maio 2014, às 11:58:15, Oswald Buddenhagen escreveu:
> > what is the added value of hard-coding arbitrary policies (and
> > thereby restricting possible use cases) instead of providing a
> > minimalistic solution (or two,
Ulf Hermann:
> Is anyone opposed to keeping this in a separate qtdebugsupport.git
> repository, then?
With what compatibility promises regarding code and protocol?
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.o
> Please create a new module. This doesn't need to be in qtbase.
Is anyone opposed to keeping this in a separate qtdebugsupport.git
repository, then?
regards,
Ulf
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailm
Em ter 13 maio 2014, às 10:29:36, Gunnar Sletta escreveu:
> > "GUI: X11 (xcb) integration" -> owner: Gunnar Sletta
>
> I would not be terribly upset if somebody that actually did work on the xcb
> plugin stepped up and took this one
We had the thread asking for that for a couple of weeks and nobo
Em ter 13 maio 2014, às 09:57:59, Knoll Lars escreveu:
> >That won't help unless we also disable the revdep for QtQuick, as QtQuick
> >depends on QtNetwork.
>
> That doesn’t mean we need to run the network tests as a revdep as well.
Then the problem is simply of running the network tests. The CI
Em ter 13 maio 2014, às 11:58:15, Oswald Buddenhagen escreveu:
> On Mon, May 12, 2014 at 06:25:34PM -0700, Thiago Macieira wrote:
> > Em seg 12 maio 2014, às 12:27:46, Oswald Buddenhagen escreveu:
> > > any a-priori transformations needed to make it actually work with random
> > > versioning scheme
Hi,
I can create a QtService (from qt-solutions) or I can create an ActiveQt
server. However, I am unable to combine them together as an ActiveQt server,
running as a Windows service.
(Un)install the service, (un)register the ActiveX components and run as console
application all works but starti
From: Knoll Lars
>On 13/05/14 11:49, "Bubke Marco" wrote:
>>Actually the different the difference between qtdeclarative and qtbase is
>>already producing enough overhead. For example bisect is hard to
>>impossible which I need to do often to find out smart changes.
>
>I very much disagree. The cha
On 05/13/2014 12:19 PM, Oswald Buddenhagen wrote:
> what's become of the new network test server, anyway?
IIRC there is one test failure showing on the new image, but not on the
old one (see my mail some months ago:
https://www.mail-archive.com/development@qt-project.org/msg14730.html).
Once th
On 13 May 2014, at 11:18, Blasche Alexander wrote:
> Hi,
>
> Following some discussions on this list and in Jira I have made changes to
> Jira components. If you have a filter that explicitly mentions one of the
> affected components, please adjust them now. Otherwise you filter may not
> re
On Tue, May 13, 2014 at 06:01:00AM +, Knoll Lars wrote:
> Actually I was thinking about splitting a few more things out. In addition
> to the ones mentioned above, I believe we would benefit from splitting
> QtNetwork out into it’s own module. The reason is that QtNetwork is
> responsible for m
On 13/05/14 11:49, "Bubke Marco" wrote:
>Actually the different the difference between qtdeclarative and qtbase is
>already producing enough overhead. For example bisect is hard to
>impossible which I need to do often to find out smart changes.
I very much disagree. The changes and refactorings
On Mon, May 12, 2014 at 06:25:34PM -0700, Thiago Macieira wrote:
> Em seg 12 maio 2014, às 12:27:46, Oswald Buddenhagen escreveu:
> > any a-priori transformations needed to make it actually work with random
> > versioning schemes are highly specific, and should therefore be left to
> > the user. ar
On 13/05/14 08:57, "Thiago Macieira" wrote:
>Em ter 13 maio 2014, às 06:01:00, Knoll Lars escreveu:
>> Actually I was thinking about splitting a few more things out. In
>>addition
>> to the ones mentioned above, I believe we would benefit from splitting
>> QtNetwork out into it’s own module. The
Actually the different the difference between qtdeclarative and qtbase is
already producing enough overhead. For example bisect is hard to impossible
which I need to do often to find out smart changes.
What about to break the 1:1 relationship between CI modules and repositories.
Why not have m
> One thing Andre raised though was whether we should continue running
> our own (albeit improved) proprietary protocol, or try to integrate
> into / implement TCF: http://wiki.eclipse.org/TCF
TCF has different messaging semantics. In particular it has message
types (Request, Response, Event) and
Hi,
Following some discussions on this list and in Jira I have made changes to Jira
components. If you have a filter that explicitly mentions one of the affected
components, please adjust them now. Otherwise you filter may not return the
correct results going forward.
1.)
- "Core: Gesture Supp
Looks nice! Would it be possible to update the logo and the image saying
"Qt Open Governance / Code Review" with a HiDPI version? They look
really fuzzy on my screen, especially next to the text that's showing
crisp and clear.
-- Erik.
On 12-5-2014 16:08, Haataja Ismo wrote:
>> And to see/try
34 matches
Mail list logo
