Hi,
On 03/02/2012, at 7:50 AM, ext Andreas Holzammer wrote:
> Hi,
>
> Does this mean QtQuick 1 does not depend on V8 anymore? Are there plans
> to remove this from the qt5 qtdeclarative module?
As Matt described, the QtQuick 1 elements, and JSC based engine they use, now
exist in a separate mo
Hi,
Does this mean QtQuick 1 does not depend on V8 anymore? Are there plans
to remove this from the qt5 qtdeclarative module?
Thank you
Andy
Am 03.02.2012 04:32, schrieb matthew.v...@nokia.com:
> As the first part of the changes described by QTBUG-23737, we have now
> separated version 1 of Qt
As the first part of the changes described by QTBUG-23737, we have now
separated version 1 of Qt Quick from the qt5 qtdeclarative module.
The implementation of Qt Quick 1 is now hosted in the 'qtquick1' repository (
http://qt.gitorious.org/qt/qtquick1 ). For maximum compatibility with the
exis
- Original Message -
> From: "wolfgang.b...@nokia.com"
> To: robin...@viroteck.net; david.fa...@kdab.com
> Cc: development@qt-project.org
> Sent: Thursday, February 2, 2012 6:00 PM
> Subject: Re: [Development] QLog ( Work on qDebug and friends)
>
> I think we can change the current QLog.
On Thursday, February 02, 2012 22:30:52 Stephen Kelly wrote:
> The port is stuck at kdeui (which blocks a lot of other stuff), because of
> the change to QPA. The kdeui library uses the Qt4 X11 integration.
This is already out of date. I ifdef'ed out the X11 stuff and ported more of
kdelibs.
Th
I think we can change the current QLog.
Category using qDebug(category) and writing stuff out in an output file.
For me a logging file is much more important than system logs or socket because
you can ask the customer that uses your Qt application to send you back the
output log file.
Other cool
On Thursday, February 02, 2012 22:30:52 Stephen Kelly wrote:
> I found some source incompatibilities, some of which have not been fixed,
Should have read '... have been fixed', but even that is not completely true.
See some of my commits here (pedantic and CMake macro):
http://codereview.qt-pro
Hi there,
I ported some of kdelibs to Qt5 (just the easy stuff).
You can see the commits here:
http://quickgit.kde.org/?p=kdelibs.git&a=log&h=894cde6ead6d9146d97e8adc7959efc907fdfe0e
To try it out, you need CMake 2.8.7 and extra-cmake-modules master.
I found some source incompatibilities, som
On Thu, Feb 2, 2012 at 3:24 PM, Quim Gil wrote:
> On 02/02/2012 06:48 AM, ext Lauro Moura wrote:
>>
>> http://trac.webkit.org/wiki/BuildingQt5OnHarmattan#Qt5packagesforHarmattan
>> https://lists.webkit.org/pipermail/webkit-qt/2012-February/002402.html
>
>
> This is great!
>
> I understand why that
Hi Caio,
Fine for me. Please create a bug report for it and assign to yourself.
Cheers,
Lars
On 2/2/12 2:48 PM, "ext Kent Hansen" wrote:
>Den 02. feb. 2012 14:39, skrev ext Caio Marcelo de Oliveira Filho:
>> Hello,
>>
>> I didn't have time to provide a patch this week, but I would like to
>> g
On Thursday 02 February 2012 15:01:02 shane.kea...@accenture.com wrote:
> An important requirement is that it must be easy to enable debugging in Qt
> libraries without touching the application code. This is so that we can
> debug regressions affecting closed source applications.
>
> With the exis
In data giovedì 2 febbraio 2012 14:03:03, David Faure ha scritto:
> On Thursday 02 February 2012 14:56:49 Robin Burchell wrote:
> > On Thu, Feb 2, 2012 at 2:22 PM, David Faure wrote:
> > > 1) showing more information (file, line, method, process name and PID)
> > > in the default message handler,
On 02/02/2012 06:48 AM, ext Lauro Moura wrote:
> http://trac.webkit.org/wiki/BuildingQt5OnHarmattan#Qt5packagesforHarmattan
> https://lists.webkit.org/pipermail/webkit-qt/2012-February/002402.html
This is great!
I understand why that wiki page is at *.webkit.org but since this is
about running Q
> From: André Somers
> Op 2-2-2012 13:22, David Faure schreef:
>> On Thursday 02 February 2012 12:52:38 =?ISO-8859-1?Q?Andr=E9?= Somers
> wrote:
>>> I think there are plenty of implementations doing this already. Take a
>>> look at QxtLogger for instance. It can be used with the output handler
An important requirement is that it must be easy to enable debugging in Qt
libraries without touching the application code.
This is so that we can debug regressions affecting closed source applications.
With the existing qDebug, we need to disable the qInstallMsgHandler call*, and
recompile the
On Mon, Jan 30, 2012 at 8:00 AM, Laszlo Papp wrote:
> On Tue, Jan 10, 2012 at 9:51 PM, Quim Gil wrote:
>> Hi, just speaking by myself since at least I have got a N950 in my hands
>> running Qt 5...
>
> It would be an invaluable contribution to ship a snapshot debian
> package into the community r
Op 2-2-2012 13:22, David Faure schreef:
> On Thursday 02 February 2012 12:52:38 =?ISO-8859-1?Q?Andr=E9?= Somers wrote:
>> I think there are plenty of implementations doing this already. Take a
>> look at QxtLogger for instance. It can be used with the output handler
>> just fine, but it also allows
Den 02. feb. 2012 14:39, skrev ext Caio Marcelo de Oliveira Filho:
> Hello,
>
> I didn't have time to provide a patch this week, but I would like to
> get this in Qt 5.0 if possible -- I'm willing to write the necessary
> changes and tests for it.
>
> QTBUG-9380: It would be useful if QStateMachine
Hello,
I didn't have time to provide a patch this week, but I would like to
get this in Qt 5.0 if possible -- I'm willing to write the necessary
changes and tests for it.
QTBUG-9380: It would be useful if QStateMachine had a signal to notify
about configuration changes
https://bugreports.qt-proje
On Thursday 02 February 2012 14:56:49 Robin Burchell wrote:
> On Thu, Feb 2, 2012 at 2:22 PM, David Faure wrote:
> > 1) showing more information (file, line, method, process name and PID) in
> > the default message handler, probably based on env vars (easy to add now
> > that QMessageLogContext ha
On Thu, Feb 2, 2012 at 2:22 PM, David Faure wrote:
> 1) showing more information (file, line, method, process name and PID) in the
> default message handler, probably based on env vars (easy to add now that
> QMessageLogContext has the necessary information).
Please don't show *all* of that by de
On Thursday 02 February 2012 12:52:38 =?ISO-8859-1?Q?Andr=E9?= Somers wrote:
> I think there are plenty of implementations doing this already. Take a
> look at QxtLogger for instance. It can be used with the output handler
> just fine, but it also allows more finegrained access with more than
>
Op 2-2-2012 0:03, BRM schreef:
>> From: David Faure
>> On Wednesday 01 February 2012 10:02:00 BRM wrote:
>>> I would also suggest that the plugins use a standard public interface
>>> class
>>> such as QAbstractLogFacility, like QTcpSocket uses QAbstractSocket - so
>>> that people can add the
On Wednesday 01 February 2012 15:03:57 BRM wrote:
> It does the job for a very basic logging system, but when you need to start
> categorizing your log messagse it does not do well at all.
Hence the idea of adding the category to the new QMessageLogContext class
(see global/qlogging.h).
> However
On Thursday, February 02, 2012 09:49:47 AM ext lars.kn...@nokia.com wrote:
> On 2/2/12 10:30 AM, "ext joona.t.petr...@nokia.com"
>
> wrote:
> >Hi,
> >
> >I'd like to nominate Pekka Vuorela (pvuorela on IRC) for approver in Qt.
> >He has been working on the text input domain for over half-decade a
On 2/2/12 10:30 AM, "ext joona.t.petr...@nokia.com"
wrote:
>Hi,
>
>I'd like to nominate Pekka Vuorela (pvuorela on IRC) for approver in Qt.
>He has been working on the text input domain for over half-decade and
>been keeping Qt 5 text input in quality shape since last summer.
Full support from m
Hi,
I'd like to nominate Pekka Vuorela (pvuorela on IRC) for approver in Qt. He has
been working on the text input domain for over half-decade and been keeping Qt
5 text input in quality shape since last summer.
Br,
Joona Petrel
___
Development mail
Well, ActiveQt is currently not actively maintained by anybody. If no one
steps up, it'll at some point be left behind. So whoever has an interest
in the module, please step up.
Cheers,
Lars
On 2/2/12 8:37 AM, "ext Friedemann Kleint"
wrote:
>Hi,
>
>the status of the module is that we are trying
On Wednesday, February 01, 2012 07:37:27 AM ext Kent Hansen wrote:
> Hi,
> The .ico plugin was originally a Qt Solution, but in Qt 4.4 it was made
> part of Qt because QtWebKit needed it.
>
> Does QtWebKit still need it? Does anyone else need it?
> In any case, would it be OK to move it to the new
On 01 February 2012 22:17 Thiago Macieira wrote:
> Aapo, that settles it then.
>
> Please submit the reversal for the 4.8 branch and feel free to cherry-pick it
> to 4.8.0-symbian.
Ok, I updated my earlier proposal with some documentation on how relative urls
are handled.
http://codereview.qt-
30 matches
Mail list logo
