On 2/01/13 11:01 PM, Peter Kümmel wrote:
> On 02.01.2013 13:50, Yves Bailly wrote:
>> Le 02/01/2013 13:42, Thiago Macieira a écrit :
>>> On quarta-feira, 2 de janeiro de 2013 10.53.03, Yves Bailly wrote:
Does anyone knows where I could find the source code of the "official"
installer, or
On 21/12/12 11:20 PM, Koehne Kai wrote:
> Any thoughts on this?
Wolfgang will be happy if this finally goes in :)
I guess you were going to do this anyway but you might want to check
that the code in the playground project is in a good state (esp
regarding any changes to Qt 5 in the last 6 mont
On 13/12/12 07:12, Alan Alpert wrote:
> Hmm... so you're suggesting that we tie the imports for a single
> application into a single file (manageable by the build system)? That
> might work...
>
> So all the application source files would look like this:
>
> import QtQml from MyImports
> import QtQ
On 12/12/12 07:28, André Pönitz wrote:
> What about something like
>
> import QtQml from Qt 5.0
> import QtQuick from Qt 5.0
+1
All the benefits of "a group of QML modules attached to a single Qt
release" without the performance problem of pulling them all in.
Then "Qt 5.0" is just some met
On 11/12/12 13:23, Alan Alpert wrote:
> Any comments on adding an API like this?
>
> Are there any other usecases which this might need to support?
If we're talking device security and restrictions policy... then please
make this something that can fail "softly" at runtime.
I know most mobile pl
On 04/12/12 18:28, Martin Smith wrote:
> What about changes to qdoc? It doesn't have autotests.
There's a first time for everything ;)
--
Link
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/develop
On 04/12/12 02:29, Knoll Lars wrote:
> since there has been some confusion about the branches we created, let me try
> to clarify
... and document on a wiki or something? For the people that won't see
this email but might search for this info?
And for the people that don't look but need the rem
On 29/11/12 22:46, Denis Shienkov wrote:
> docs_target.commands = "set QTDOC=$$QTDOC$$escape_expand(\\n\\t)$$QDOC3
> $$QDOCCONF"
This won't work.
make treats separate "lines" as completely separate commands. You cannot
set a variable in one line and use it in another. You must pass all
stateme
On 28/11/12 22:45, Denis Shienkov wrote:
> Why not available Qt env variables from *.qdocconf file?
>
> For example,
>
> I need specify path to Qt Doc installation directory from my.qdocconf file:
>
> ...
> indexes = $QT_INSTALL_DOCS/doc/html/qt.index
$ in a .qdocconf file uses environment variabl
On 27/11/12 8:03 PM, Sascha Cunz wrote:
>> Qt already allows to serialize any datatype known to the meta type
>> system, provides means for IPC (D-Bus is just one example) and has a
>> code generator which implements our objects (moc) and allows for
>> handling asynchronous signals and slots.
>>
>>
On 01/11/12 09:41, Thiago Macieira wrote:
> On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote:
>> On 01/11/12 01:02, Thiago Macieira wrote:
>>> Also, do I understand correctly that you're suggesting that multiarch
>>>
>>> distributions
On 01/11/12 01:02, Thiago Macieira wrote:
> Also, do I understand correctly that you're suggesting that multiarch
> distributions should have *both*:
> /usr/lib/qt5//bin/assistant AND
> /usr/lib64/qt5/bin/assistant
> /usr/lib/qt5//bin/linguist AND
On 25/10/12 13:00, Rohan McGovern wrote:
> True, there used to be Nokia employees reading every failure report and
> chasing up apparently unstable tests, either trying to fix the tests, or
> acknowledge them via bug reports and marking them insignificant.
> Those people are gone and the test resul
On 24/10/12 4:04 PM, Konstantin Ritt wrote:
> You definitely don't want support multiarch configurations out-of-the-box :)
> Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5
> /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86`
> (or even with `qmake -set-qt 5
On 24/10/12 04:33, Thiago Macieira wrote:
> I think we are keeping it simple. The current proposal is the simplest
> that still works. If you can come up with something even simpler, I'll
> gladly accept it.
>>> If the option is required in one platform and does not cause anything but
>>> a minor
On 24/10/12 07:01, d3fault wrote:
> If you discover a vulnerability, please report it to
> secur...@qt-project.org and we'll take care of the rest. You can of
> course join in on the discussion and suggest fixes etc, as Qt is a
> COLLABORATIVE PROJECT.
>
> If you think the vulnerability would cause
On 23/10/12 15:10, d3fault wrote:
> Also please tell me why I can't join the Qt Security Team without
> contradicting yourselves.
You haven't earned the trust of the people in charge.
The current security team members have earned the trust of the people in
charge.
No contradictions there.
--
Serves me right for not reading _all_ the mail in this folder before
replying to an old thread...
On 20/10/12 09:16, Thiago Macieira wrote:
> a) under most circumstances, it will simply find another qmake and pass
> through all arguments. That is:
> qmake -project
> basically
On 20/10/12 07:35, Thiago Macieira wrote:
> Really, I don't care what qmake5 is and where it points to, so long as:
> a) it exists
> b) it works
> c) it's the official and documented way of creating Qt applications in Qt 5
>
> Any other names are under the customer's taste.
Surely then the v
On 19/10/12 01:30, Thiago Macieira wrote:
> After all of my patches are integrated, here are the changes that will happen:
>
> - bin:
> The following tools have been renamed:
So... You just don't care about the calls from myself and others to
leave the names alone instead install newly-named (ali
On 16/10/12 03:35, Thiago Macieira wrote:
> Will do. I need help from Ossi to figure out how I broke qmake, because it's
> not evident.
Most likely it's qconfig.cpp, which contains the paths returned by
QLibrary. There's a special version of this file just for qmake
(generated by configure).
--
On 15/10/12 20:12, Olivier Goffart wrote:
>> Renato Araujo wrote:
>>> I'm working to port a library based on qt4.8 and qtquick 1.1 to qt5
>>> and qtquick 2.0.
>>> This library uses dynamic metaobject to export dynamic properties
>>> signals and slot.
>>> What this library does is override the metaO
On 12/10/12 09:18, Thiago Macieira wrote:
> The only tools that need renaming are the tools that are run by users but are
> tied to a specific library version. That's basically qmake.
>
> If we had a generic build tool that worked with multiple Qt versions (like
> cmake), we wouldn't need to do it.
On 11/10/12 05:01, Stephen Chu wrote:
> I think I can bring qtbase to head for that. But last time I did it, I
> had to wipe my whole Qt5 repo to get back to qt5 current. Maybe I will
> have better luck this time. :)
In 99.999% of cases, if you remove your git repo to fix a problem,
you're doing
On 9/10/12 5:17 PM, Simon Hausmann wrote:
> On Tuesday, October 09, 2012 09:07:10 AM Lincoln Ramsay wrote:
>> On 08/10/12 22:58, Simon Hausmann wrote:
>>> Now this has some ugly implications, everyone will have to change the way
>>> they develop with Qt 5. In t
On 08/10/12 22:58, Simon Hausmann wrote:
> Now this has some ugly implications, everyone will have to change the way they
> develop with Qt 5. In this context we have another interesting artifact:
> People who have been developing Qt for a long time as part of company efforts
> such as Trolltech, N
On 08/10/12 15:09, song.7@nokia.com wrote:
collect2 (4.4.1) is used to link.
If you're linking something that includes C++ you should really use g++
as the linker.
If you're going to invoke ld directly, you need to ensure the
appropriate flags are set so it includes the C++ runtime.
On 08/10/12 14:57, song.7@nokia.com wrote:
We are building the mesa for Qt, and the gcc is used to build out ARM
version.
But the bellow symbols is reported as undefined:
_ZTVN10__cxxabiv120__si_class_type_infoE
_ZTVN10__cxxabiv121__vmi_class_type_infoE
_ZTVN10__cxxabiv117__class_type_in
On 28/09/12 14:37, Loaden wrote:
I prefer:
dev -> next
stable -> master
release -> release
Clearly they should be named after a traffic light:
green - commit away
orange - be careful (keep it stable)
red - don't commit
Luckily we use git so you can give the branches any name you want on
yo
On 27/09/12 11:58, Thiago A. Corrêa wrote:
> I've submitted this changeset:
> https://codereview.qt-project.org/#change,35790 and qdoc complains
> about an override in documentation. Basically, the two
> QSqlQuery::value signatures are identical except that one is a
> template method and the o
So I have this little client/server thing that started life as a single
program. All the networking bits are kind of yuck and a pain to maintain
and I was thinking that from a high level, this all feels kind of like
Service Framework, just over a network.
So I tried putting network support into
which is most
certainly not needed for the monolithic doc build - dunno about modular
builds).
I don't know enough about where doc building is going to say what the
"right" fix is here. Maybe Casper or Alan can comment.
--
Lincoln Ramsay - Senior
ake to be run if you've
built modules after qtdoc builds, otherwise those modules will be
missing from the documentation.
make -C doc qmake
Or if your make doesn't have -C
cd doc
make qmake
cd ..
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, N
QML types are implemented in C++ that makes it
difficult to support them across display engines...
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.or
build tree for these files.
I'm not sure if there's a change for that yet.
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
ht
le so just allowing QT += declarative to enable
QtQuick2 won't gain you anything.
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-p
platform plugin
to use.
If there's a way to detect the environment you're running under that
would be even better than a compiled-in default.
https://bugreports.qt-project.org/browse/QTBUG-21881
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http:/
On 04/25/2012 12:44 AM, ext Mike Zraly wrote:
> On Mon, Apr 23, 2012 at 7:57 PM, Lincoln Ramsay
> mailto:lincoln.ram...@nokia.com>> wrote:
> I'm a little concerned about performance during shutdown if there are a
> large number (say 100 or more) of QLoggingCat
data member.
See the patch.
> 2. Get rid of the QT_LOG_CATEGORY macro and expose QLogging category
> directly.
Yeah... what I said before.
I think there is merit in this idea. We may have to be a little careful
since people have already started using this code (ie. I'd like to keep
that you have to run "qdoc [module.pro] [module.qdocconf]", or do you
> see that differently?
Doesn't qmake run over doc.pri to generate a Makefile rule "make docs"
that you run? Or are we moving away from "make docs" and towards running
qdoc explic
en. Allowing explicit dependencies on docs (where there
is no dependency between modules) may make sense but dependencies
derived from the build should be extracted from the build.
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
__
elieve a
source-compatible, cross-platform API is what is being created.
eg.
http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/
"The API is mostly aligned with our ongoing mobile SDK effort, but I
also had to create some uniquely desktop-related widgets such as
ScrollBar, ScrollAr
maintain otherwise
virtually-identical .qml files for each target platform just because the
components have a different import, or a different name for an element.
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
__
I guess having the type (avoiding redundant warning/error), function
(avoiding Q_FUNC_INFO) and message should be ok as long as it doesn't
bloat message length too much...
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
_
s an add-on to the language :(
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On 03/29/2012 09:41 AM, ext Lincoln Ramsay wrote:
> Why can't Creator just set the QT_MESSAGE_PATTERN environment variable
> then and leave the default alone? Creator would not need to show the
> filename and line number, just use them for when you click on the warnings.
And r
builds) ...
Why can't Creator just set the QT_MESSAGE_PATTERN environment variable
then and leave the default alone? Creator would not need to show the
filename and line number, just use them for when you click on the warnings.
--
Lincoln Ramsay - Senior Software Engineer
Qt Developme
ot even supported to build without QPA on Qt 5.
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Probably easier to just have qmake generate the dependency
itself :)
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
rivate
>
> This will always add to the command line:
>
> -lfoo -lQtPlatformSupport
>
> which is the wrong order. It needs to be the other way around.
You can do this...
QT += platformsupport-private
load(qt)
LIBS += -lfoo
--
Lincoln Ramsay - Senior Software Eng
to
document NOTIFY signals and I guess at that point the thread was
hijacked onto a separate topic.
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-proje
on if the signal docs are found). Since I don't
actually know the qdoc code, I went for a simple fix.
If the above design pattern (co-opting a signal for NOTIFY) is common
and suppressing the documentation for those signals will be a problem
then I guess the more complicated fix will need to
setters is
> only _documented_ as a property, but it is not defined as a
> Q_PROPERTY so anyone trying to use them using the properties API is
> at a loss at why that does not work...
You can't document members as a property without using Q_PROPERTY.
--
Lincoln Ramsay - Senior Softwa
ther bits of code dealing
with getters and setters but not notifiers. I've updated them too but I
don't actually know what they do.
http://codereview.qt-project.org/#change,19374
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Fram
entional. You document the property. The getter and setter methods
> do not need to be documented.
I like this, but I don't like that you must explicitly document the
NOTIFY signal for a property.
Is there a particular reason that NOTIFY signals aren't handled the same
as getters an
On 03/01/2012 02:01 PM, ext wolfgang.b...@nokia.com wrote:
> I need to have a vote on a implementation detail regarding filtering
> of wildcards categories.
I vote for ordered handling because it's natural and consistent with
just about everything else out there.
--
Lincoln Rams
On 02/25/2012 04:44 AM, ext David Faure wrote:
>> I took the easy way of declaring a category for qDebug so I wouldn't
>> have to figure out how to do conditional formatting :)
>
> Fair enough. But then call it "default", not "legacy".
Sounds fine t
ne you want" case...
> Just wanted to point out that the current environment variable for configuring
> the output is called QT_MESSAGE_PATTERN. So it should be either
> QT_MESSAGE_CONFIG,
> or we should quickly rename QT_LOGGING_PATTERN ...
I guess QT_MESSAGE_CONFIG would be b
ose Windows users would expect relative paths to be "in the CWD, which
> is usually the executable's directory"? Not sure.
That doesn't work when an unprivileged user runs an installed app
because they don't have permission to write to Program Files.
If a relative path is
utput.file = c:\log.txt
# this is the default (output goes to message handler or file, not both)
logging.output.both = false
# write to both the file and the message handler
logging.output.both = true
# for messages being written into the file, overwrite the formatting string
logging.output.format
t; most likely be pretty bad.
I vote for removing it. I think that's better than making it just float
or double.
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Developme
Do you imagine something in the qLog config file? An environment
variable? A C++ API?
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
one caveat.
We feel the use case of "I have no add-on but I want logs captured to a
file" merits the inclusion of file-writing code into QtCore. This is
turned on via the qlog config file and the formatting for this can be
set in the config file.
But you can most certainly i
only reason is "well, I didn't dare to touch qDebug itself"?
> I think it's the right time to touch it :-)
As has already been covered, the C++ language does not let us overload
the qDebug macro with category support and overloading at the function
level results in a potential
e,13226
> Furthermore, if you do make the macro evaluate the category, then you
> have to call something at run-time to do the filtering, in which case
> what I propose is equally as good.
No, for the reasons stated before and above. Moving the "filtering" down
into t
<< "message for category1";
qLog(category2) << "message for category2";
This code cannot:
qDebug() << category1 << "message for category1"
<< category2 << "message for category2";
Is the second syntax really that much
onal and will remain so.
Removing that from your example gives almost the same syntax as qLog but
with a different name and I think I've covered that already :)
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
en the categories are disabled.
This works fine though.
qLog(category1) << "message for category1";
qLog(category2) << "message for category2";
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
s can clarify that we can use variadic macros in Qt,
then we can see if we can actually use variadic macros to differentiate
between:
qDebug("message");
qDebug() << "message";
qDebug(CAT) << "message";
Where the last one expands to if (do_nothing); else
d qDebug.
qLog is just a name. It's the name this code had when it was in Qtopia
but it's hardly important if it keeps this name. It would be nice to
focus on the implementation of the feature to make sure it is sound
before we worry overly much about what to call it :)
--
Lincoln Rams
ant in
the if) and so omit that code from the binary. Certainly, that code will
never be run when the macro expands this way.
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development maili
. Maybe
> there's place for both, but I thought the idea for the Qt libraries
> was to avoid the need for recompiles ...
qLog is most certainly a run-time system.
The actual macro looks more like this:
if (!global_enabled() || !category_enabled(cat)) /*NOP*/; else qDebug()
--
Lin
uot; to something else (perhaps living
in an Add-on).
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
, here it is:
http://codereview.qt-project.org/#change,13226
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
gives you string-based categories without the cost of
string comparisons and I suspect the size cost of the logging messages
is larger than the cost of the category classes.
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Framew
27;t know this code but in my code's case, the error
looked bogus to me (ie. it was a perfectly valid use of static_cast as
far as I'm aware).
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
_
one is finished (or deleted) then the app quits.
* I'm sure we can bikeshed a better name than QTask :)
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Developmen
77 matches
Mail list logo
