On Wed, Jan 9, 2013 at 2:11 AM, Sergio Ahumada wrote:
> The latest failure is:
> tst_qperformancetimer(qtquick1.git)
See: https://codereview.qt-project.org/#change,44228 - I've been
meaning to do it for a while, but now that I saw a failure from it, I
guess it's a good time :)
_
On Jan 7, 2013, at 7:01 AM, Oswald Buddenhagen wrote:
> On Fri, Dec 28, 2012 at 08:36:21AM -0600, Glen Mabey wrote:
>> Issue 8) I did not see any output from the sanity bot when I did a
>> git commit even though I had installed the symlink
>> /.git/hooks/post-commit to git_post_commit_hook … any
I reverted back to the pervious version of qt5, but I still get this error.
Qt-Compositor configured with openGL integration: wayland_egl
Project ERROR: Package egl not found
The EGL is install in the correct directory because when I check the config.log
the egl package is found and passed the c
/home/alexander/qtwayland/src/compositor/compositor_api/compositor_api.pri:15:
'qtHaveModule' is not a recognized test function.
Project ERROR: Package egl not found
make[1]: *** [sub-compositor-install_subtargets] Error 3
make[1]: Leaving directory `/home/alexander/qtwayland/src'
make: *** [sub-s
I have tried your solution and wayland_egl tested successfully.
However, I still get this error and I do not know what Qt wants me to fix.
Project MESSAGE: /home/alexander/qtbuild/bin/syncqt -module QtCompositor
-mkspecsdir /home/alexander/qtbuild/mkspecs -outdir /home/alexander/qtwayland
/hom
Hi,
> what is the status and the planning for qt5 accelerated video playback :
> on Windows (It seems that there was some work around dxva/Angle playback)
> Linux : Gstreamer?
> Mac : ?
> And android (I suppose for now that there is no video support)
On Mac 10.7+ using the AVFoundation media pl
what is the status and the planning for qt5 accelerated video playback :
on Windows (It seems that there was some work around dxva/Angle playback)
Linux : Gstreamer?
Mac : ?
And android (I suppose for now that there is no video support)
___
Development m
> The reason qmlmin or a qml-defs-processor could work is that it's
> purely optimization. The QML code works exactly the same with and
> without it, so you can develop with the un-processed QML and then get
> a speed boost for the final deployment.
>
I should also mention that this is also how QR
On Tue, Jan 8, 2013 at 9:32 AM, Mohamed Fawzi wrote:
> I understand the attractiveness of small tools, especially if one wants to
> deploy bundling that tool.
> Still I am with Kay on this, I see the probability of diverging, and thus
> having more bugs, that happen only in one tool and not the
On Tue, Jan 8, 2013 at 3:17 AM, Alberto Mardegan
wrote:
> On 01/08/2013 02:03 AM, Alan Alpert wrote:
>> Feedback?
>>
>> It's really Qt that's cross-platform focused now, not me. I just want
>> this so that SameGame runs beautifully on BB10 :) . So while I'd
>> welcome feedback from any source, I *
That is a good point, currently the license is 1393 characters, so I think
2 should be enough (it doen't look like there is any limit in the range,
other than being implicitly 32 bit in some places...
Fawzi
From: Rutledge Shawn
Sent: Tuesday, January
On Tue, Jan 8, 2013 at 1:45 AM, Attila Csipa wrote:
> On 08-Jan-13 02:03, Alan Alpert wrote:
>> What I suggest is a path based swap-out like Plasma has, but a little
>> more generic than being tied into the Plasma Package format. Here's
>> the basic algorithm for swapping, where platformSelectors
I understand the attractiveness of small tools, especially if one wants to
deploy bundling that tool.
Still I am with Kay on this, I see the probability of diverging, and thus
having more bugs, that happen only in one tool and not the other as bigger.
Even having a single binary does not remove a
On Tue, Jan 8, 2013 at 4:56 AM, Koehne Kai wrote:
>> -Original Message-
>> From: Alan Alpert [mailto:4163654...@gmail.com]
>> Sent: Monday, December 24, 2012 8:23 AM
>> To: Koehne Kai
>> Cc: Sorvig Morten; development@qt-project.org
>> Subject: Re: [Development] QML Runtime
>>
>> For those
On Tuesday 8 January 2013 15:49:32 Laszlo Papp wrote:
> I personally expected that you need this list for something permanent that
> is out of the scope for the existing mailing lists, like development@, qt-
> components@, and so forth. I still did not get any examples what development
> cannot
On 7 Jan 2013, at 11:21 AM, Mohamed Fawzi wrote:
> I would like to close the discussion if possible.
> Is the following hierarchy acceptable?
>
> text/plain; charset=utf-8
> text/vnd.qt.qml => a file adhering to the QML grammar/syntax .qml suffix
>text/vnd.qt.qtquick1+qml => .qml suffix +
>
> 3) Use a mailing list like for QtCore, QtGui, and what not android patches
> for instance what others also see like QtCore sub(module) maintainers
> without subscribing separately for each platform?
>
4) mobile-developm...@qt-project.org (or something similar, but you get the
idea)
This way,
On Tue, Jan 8, 2013 at 3:26 PM, Paul Olav Tvete wrote:
> On Tuesday 8 January 2013 15:13:38 Laszlo Papp wrote:
>
> > We do not have separate lists for Mac, QNX, Windows, Linux, Harmattan,
> > Symbian and so forth so far, so I am wondering: what exactly would not
> fit
> > the existing mailing l
On Tuesday, January 08, 2013 04:26:47 PM Paul Olav Tvete wrote:
[...]
> Edit: and as Maurice says, we can shut down the list when it's no longer
> useful.
For clarification: That doesn't mean that the archives are subject to deletion.
Simon
___
Develop
On Tuesday 8 January 2013 15:13:38 Laszlo Papp wrote:
> We do not have separate lists for Mac, QNX, Windows, Linux, Harmattan,
> Symbian and so forth so far, so I am wondering: what exactly would not fit
> the existing mailing lists?
This is a new project, and we need a convenient way to com
I am sorry for writing this, but this sounds like a bad idea to me because:
1) The important discussions go to the separate bubble. For instance, I am
more interested in mobile platform discussions than Mac and I still have to
read the Mac discussions.
2) Removing the list eliminates the possibil
Historically we always had mailing lists for new platform development.
The reason has been that the topics vary quite a lot, starting with
architectural design for some implementations and others. That can cause lots
of noise on a generic mailing list, especially for those who are not
intereste
On Jan 8, 2013, at 3:53 PM, Keller Alexander-B42067
mailto:b42...@freescale.com>>
wrote:
I have tried to your solution, but it did not work. I have created a pkgconfig
file for wayland-egl. (I attached the pkgconfig file in the email) However,
when configured qtwayland it did not look for the
We do not have separate lists for Mac, QNX, Windows, Linux, Harmattan,
Symbian and so forth so far, so I am wondering: what exactly would not fit
the existing mailing lists?
Laszlo
On Tue, Jan 8, 2013 at 11:48 AM, Eskil Abrahamsen Blomfeldt <
eskil.abrahamsen-blomfe...@digia.com> wrote:
> Hi,
>
Hi,
It's been a lot of time now since qt5.git#stable was updated, so I'd
like to ask for help to check and hopefully fix the failing tests there.
The latest failure is:
tst_qdeclarativelistview (qtquick1.git)
tst_qperformancetimer(qtquick1.git)
tst_qscroller(qtbase.git)
S
On terça-feira, 8 de janeiro de 2013 14.44.45, Eskil Abrahamsen Blomfeldt
wrote:
> On 01/08/2013 01:43 PM, Thiago Macieira wrote:
> > On quinta-feira, 3 de janeiro de 2013 14.48.51, Thiago Macieira wrote:
> >> Please delete the branch and recreate (with another name) without these
> >
> >> files i
On Tue, 2013-01-08 at 22:37 +0900, Takumi ASAKI wrote:
> Hi,
>
> Qt::InputMethodQuery is marked as obsolete in the document.
> http://qt-project.org/doc/qt-5.0/qtcore/qt-obsolete.html#InputMethodQuery-enum
>
> Is this correct?
>
> Qt::InputMethodQuery is very important for Input Method.
And yet
On 01/08/2013 01:43 PM, Thiago Macieira wrote:
> On quinta-feira, 3 de janeiro de 2013 14.48.51, Thiago Macieira wrote:
>> Please delete the branch and recreate (with another name) without these
>> files in src/3rdparty/android/precompiled/android-8/arch-arm/lib/:
> Again, please *delete* the bran
Hi,
Qt::InputMethodQuery is marked as obsolete in the document.
http://qt-project.org/doc/qt-5.0/qtcore/qt-obsolete.html#InputMethodQuery-enum
Is this correct?
Qt::InputMethodQuery is very important for Input Method.
And the new class QInputMethodQueryEvent is depends on it.
It seems there is no
> -Original Message-
> From: Alan Alpert [mailto:4163654...@gmail.com]
> Sent: Monday, December 24, 2012 8:23 AM
> To: Koehne Kai
> Cc: Sorvig Morten; development@qt-project.org
> Subject: Re: [Development] QML Runtime
>
> For those interested in the matter, the discussion has now moved to
On quinta-feira, 3 de janeiro de 2013 14.48.51, Thiago Macieira wrote:
> Please delete the branch and recreate (with another name) without these
> files in src/3rdparty/android/precompiled/android-8/arch-arm/lib/:
Again, please *delete* the branch.
--
Thiago Macieira - thiago.macieira (AT) inte
Hi,
I'd like to propose making a mailing list in Qt Project for the Qt 5 for
Android port. I think it makes sense to have a separate list for this,
since it will probably be fairly high in traffic as this project is
ramping up, and I want to avoid having a lot of ad hoc mailing lists
based on
On 01/08/2013 02:03 AM, Alan Alpert wrote:
> Feedback?
>
> It's really Qt that's cross-platform focused now, not me. I just want
> this so that SameGame runs beautifully on BB10 :) . So while I'd
> welcome feedback from any source, I *need* to hear it from people
> interested in other platforms (or
Hi,
making of Qt 5.0.1 patch release has started and few items to notify:
- We are planning to move into 'release' branch next Wednesday
(9th Jan). There are already around 300 commits available since
v5.0.0 in 'stable'
- Content from 'stable' will be the basis for 5.0.1
- After 9th Jan any
On 08-Jan-13 02:03, Alan Alpert wrote:
> What I suggest is a path based swap-out like Plasma has, but a little
> more generic than being tied into the Plasma Package format. Here's
> the basic algorithm for swapping, where platformSelectors is an
> ordered list of selectors specified for the platfo
On Tuesday 08 January 2013 08:31:10 Sletta Gunnar wrote:
> On Jan 7, 2013, at 11:16 AM, Sean Harmer wrote:
> > Given the current contents of QtGui and the state of Qt3D I would suggest
> > the following:
> >
> > QtGui continues to be the home for low-level OpenGL convenience classes.
> > That is
On Jan 7, 2013, at 11:16 AM, Sean Harmer wrote:
>
> Given the current contents of QtGui and the state of Qt3D I would suggest the
> following:
>
> QtGui continues to be the home for low-level OpenGL convenience classes. That
> is classes that have a pretty much 1:1 mapping to OpenGL objects.
37 matches
Mail list logo