Em qua 14 maio 2014, às 20:17:34, Thiago Macieira escreveu:
> Em sex 09 maio 2014, às 16:53:20, Yuchen Deng escreveu:
> > If I have to do `make install` first, then I can't use `make install
> > INSTALL_ROOT=$PWD/qt` anymore.
> > It's means INSTALL_ROOT does not support for this case?
> >
> > make
Em sex 09 maio 2014, às 16:53:20, Yuchen Deng escreveu:
> If I have to do `make install` first, then I can't use `make install
> INSTALL_ROOT=$PWD/qt` anymore.
> It's means INSTALL_ROOT does not support for this case?
>
> make install_docs INSTALL_ROOT=$PWD/qt >>install.log 2>&1
>
> 2014-05-09 10
Em qui 15 maio 2014, às 09:18:31, Yang Fan escreveu:
> BTW, when will QtWebkit be replaced?
>From yesterday:
http://blog.qt.digia.com/blog/2014/05/13/news-from-the-qt-webengine-team/
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_
On 15 May 2014 09:18, Yang Fan wrote:
> BTW, when will QtWebkit be replaced?
The plan is to make Qt WebEngine available to Qt Enterprise Embedded
users from Qt 5.3, and other users from Qt 5.4:
http://blog.qt.digia.com/blog/2014/05/13/news-from-the-qt-webengine-team/
Regards,
Sze-Howe
> On Th
BTW, when will QtWebkit be replaced?
On Thu, May 15, 2014 at 8:48 AM, Thiago Macieira
wrote:
> Em qua 14 maio 2014, às 16:39:15, P Bai escreveu:
> > As to the first two issues, from what I read online, it is because of
> > QtWebkit, which I have to use in my app. Is there any hope we could get
>
Em qua 14 maio 2014, às 16:39:15, P Bai escreveu:
> As to the first two issues, from what I read online, it is because of
> QtWebkit, which I have to use in my app. Is there any hope we could get
> these fixed?
Correct, all of them come from QtWebKit.
Anyway, there's no plan on further updating
On 2014-05-14, at 07:39 PM, P Bai wrote:
> Hi All,
>
> My mac app just got rejected by the Mac App Store for the following reasons:
>
>
> The use of non-public APIs can lead to a poor user experience should these
> APIs change in the future, and is therefore not permitted.
Hi All,
My mac app just got rejected by the Mac App Store for the following reasons:
The use of non-public APIs can lead to a poor user experience should these APIs
change in the future, and is therefore not permitted. The following non-public
APIs are included in your appl
Em qua 14 maio 2014, às 13:36:30, Thiago Macieira escreveu:
> QSysInfo::osVersion() will return "Windows 8" but
> QSysInfo::osKernelRelease() will return "6.2.9200".
BTW, on Linux:
$ qtdiag | head -2
Qt 5.3.1 (x86_64-little_endian-lp64 shared (dynamic) debug build; by GCC 4.8.1
20130909 [gcc-4_
On Thursday 15 May 2014 04:44:34 Ben Lau wrote:
> well , I also think that the document about Drag and Drop is not clear
> enough.. Reading from example code is more easy to understand.
>
> Anyway , the solution to your problem: You should call drag.accept() within
> the onEntered slot. Then it wi
On Wed, May 14, 2014 at 11:37:45AM +0200, Milian Wolff wrote:
> On Tuesday 13 May 2014 21:58:29 André Pönitz wrote:
> > 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
> 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.
well , I also think that the document about Drag and Drop is not clear
enough.. Reading from example code is more easy to understand.
Anyway , the solution to your problem: You should call drag.accept() within
the onEntered slot. Then it will enable the onDropped slot to be executed.
http://qt-pr
Em qua 14 maio 2014, às 14:12:40, Stephen Kelly escreveu:
> Note also that version number schemes for particular software are not
> constant over time.
>
> https://blog.qt.digia.com/blog/2009/09/03/qt-4th-edition-feature-pack-7/
That was a joke! Tongue in cheek with how Symbian/S60 named its ver
On 2014-05-14, at 04:26 PM, Thiago Macieira wrote:
> Em qua 14 maio 2014, às 08:45:28, Keith Gardner escreveu:
>>> Well, if you use a virtual, you'd simply subclass to handle the specific
>>> format for your project.
>>
>> I haven't thought about using inheritance to simplify the compare but I
>
Em qua 14 maio 2014, às 08:45:28, Keith Gardner escreveu:
> > Well, if you use a virtual, you'd simply subclass to handle the specific
> > format for your project.
>
> I haven't thought about using inheritance to simplify the compare but I
> think that would provide the best compromise.
I don't w
Hey,
I'm trying to get my head around the QML Drag and Drop API and keep finding
oddities. (I've already posted some bugs and CRs in order to improve the
situation). But here's a new one:
DropArea has a 'onDropped' signal, that is supposed to be emitted "when a drop
event occurs within the bou
Thank you a lot, that is a very comprenhensive response.
> If you have GUI thread state, application logic and other stuff you can
> call QQuickItem::polish() and reimplemnt QQuickItem::updatePolish() which
> is called just before the QML tree is synced into the render thread.
Indeed, this is GUI
It depends on what your update state is...
If you want to tick rendering state (OpenGL and Scene Graph stuff) then you can
call QQuickWindow::update() and make a direct connection to
QQuickWindow::beforeRendering() to advance the state on the render thread just
before the scene is drawn.
If y
Hi guys!
So... I am working on a project where the data model is written in a
functional style and uses a "epochal" approach to move it's state
forward... the details would probably bore you but the important thing is
that it requires a tick() function to be called to make an updated world
state v
Keith Gardner schreef op 14-5-2014 15:45:
Well, if you use a virtual, you'd simply subclass to handle the
specific format for your project.
I haven't thought about using inheritance to simplify the compare but
I think that would provide the best compromise. What are your
thoughts abo
>
> Well, if you use a virtual, you'd simply subclass to handle the specific
> format for your project.
>
I haven't thought about using inheritance to simplify the compare but I
think that would provide the best compromise. What are your thoughts about
comparing a QVersion to a QSpecializedVersion
Keith Gardner schreef op 14-5-2014 14:28:
I think that makes sense, but it would be nice if it would be easy
for the user of the class to extend the version checking himself
for non-numerical sections of the version string. That could be
done in several ways I think, for instanc
On Wednesday, May 14, 2014 07:41:20 you wrote:
> At this moment, the 'v' is optional and if present, will be ignored.
Try to ignore the specificness of that. The only point I was making is this:
Version number schemes change over time in a way you can't predict.
Thanks,
--
Join us at Qt Deve
>
> >1. Numerical groupings should be compared integers instead of
> characters
> >in order to properly allow for "alpha2" < "alpha11".
> >2. Delimiters should only be used to denote groups of content but be
> >skipped during the compare. "alpha" == "-alpha" == "~alpha" ==
> ".alph
>
>
> I think that makes sense, but it would be nice if it would be easy for the
> user of the class to extend the version checking himself for non-numerical
> sections of the version string. That could be done in several ways I think,
> for instance with an API like this:
>
> QVersion
> {
> ...
>
On Sunday, May 11, 2014 13:42:25 Keith Gardner wrote:
> Other comparison rules:
>
>1. Numerical groupings should be compared integers instead of characters
>in order to properly allow for "alpha2" < "alpha11".
>2. Delimiters should only be used to denote groups of content but be
>s
On Tuesday 13 May 2014 21:58:29 André Pönitz wrote:
> 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.
>
> A
On Tue, May 13, 2014 at 03:31:52PM -0500, Keith Gardner wrote:
> On Tue, May 13, 2014 at 3:06 PM, Oswald Buddenhagen
> wrote:
> > my point is that this class is becoming unreasonably complex for a
> > rather trivial thing, which only a fraction of the applications will
> > use.
> >
> Your argumen
Hello,
I have some good news which I won't repeat here, please read up on the state
of Qt accessibility in Qt 5.3 and onward:
http://blog.qt.digia.com/blog/2014/05/14/accessibility-in-qt-5-3/
I'd like to invite everyone interested to join our new Qt accessibility
mailing list:
http://lists.qt-p
On Wednesday 14 of May 2014 08:01:33 Oliver Wolff wrote:
> 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
> -Original Message-
> From: Verbruggen Erik
> 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.
I changed
Keith Gardner schreef op 13-5-2014 22:31:
imo, the cases which are fully under the user's control (internal
version checking) should be handled solely numerically (even without
considering any pre-releases), which basically means a minimalistic
semver(-like) implementation which
33 matches
Mail list logo
