Am 16.02.2016 um 08:29 schrieb Knoll Lars:
Hi everybody,
It would be great if those of you who haven’t done so yet fill in the 5.7 new
features page on the wiki (https://wiki.qt.io/New_Features_in_Qt_5.7), so that
we can get a good overview over the bigger new features in 5.7.
In addition,
On 23.04.2015 20:31, René J.V. Bertin wrote:
On Thursday April 23 2015 16:58:05 Peter Kuemmel wrote:
Because the gerrit code is Qt5 not Qt4.
Doh ... I wondered about that and should have realised it was the case seeing
the dialoghelper file on the list.
So it needs a complete review and
On 23.04.2015 14:30, René J.V. Bertin wrote:
On Thursday April 23 2015 11:13:41 Peter Kuemmel wrote:
René, maybe this helps you a bit:
https://codereview.qt-project.org/#/c/111056/
It's only a incomplete copy and paste of your Qt 4 patch,
but it could show you the direction.
Hi Peter,
On 30.05.2014 23:59, Adam Strzelecki wrote:
Moreover it takes more to build qt-creator with Qbs (20min) than Qmake+make
(18min). Also it doesn't support precompiled headers, at least not for
qt-creator, where Qmake+make+PCH goes down to 9min.
Strange, I thought qbs improves build times.
On 19.05.2014 10:57, Oswald Buddenhagen wrote:
On Sun, May 18, 2014 at 05:29:56PM +0200, Adam Strzelecki wrote:
Hello,
I wonder if there was any work done in regards of making Ninja Qmake
generator. From my experience Ninja vastly improves (re)build time.
I wonder if it would be hard to
On 27.04.2014 22:41, Thiago Macieira wrote:
Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
Then adding 100MB just to run QML really hurts, and you start
looking for alternatives, like using only QWidgets with very
limited OpenGL support or not to use a Qt-GUI at all.
Of those 100 MB
On 28.04.2014 08:10, Kurt Pattyn wrote:
On 28 Apr 2014, at 07:53, Peter Kümmel syntheti...@gmx.net wrote:
On 27.04.2014 22:40, Thiago Macieira wrote:
Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
On 26.04.2014 17:39, André Pönitz wrote:
You could have made the point declarative
On 28.04.2014 09:32, Gunnar Sletta wrote:
ATM the problem is to get started because I don't know much about the
current architecture of the graphic stack.
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
On 28.04.2014 18:01, Tony Van Eerd wrote:
On 25.04.2014 12:18, Joerg Bornemann wrote:
Yep, I hear people keep repeating the mantra QML is declarative. It's
just QML/JS that isn't.
I think the declarative-mantra is a good idea, especially when used for
_specifying_ (not programming) the
On 24.04.2014 21:15, Attila Csipa wrote:
solutions to cross platform mobile development :( After playing a bit
with Xamarin (yes, I know, but put aside the C# hate for a minute), it's
quite striking what different approaches can result in (and it also made
it quite clear what Qt is doing
On 25.04.2014 12:18, Joerg Bornemann wrote:
Yep, I hear people keep repeating the mantra QML is declarative. It's
just QML/JS that isn't.
I think the declarative-mantra is a good idea, especially when used for
_specifying_ (not programming) the GUI.
At Adobe they tried it with pure C++
On 26.04.2014 17:39, André Pönitz wrote:
You could have made the point declarative structures are good for GUI
description for Qt Widget's .ui files, after all, .ui files contents
pretty much _is_ declaring layout nesting and property values.
Just an idea:
Declarative-only QML files could be
On 21.04.2014 13:39, Roland Winklmeier wrote:
- Memory consumption: Even a mini example took about 70 MB of memory,
QtWidgets need a lot less. This is not a complain, I know the JS runtime
needs its initial memory. It was just one factor, because our
application is running as an addon to
On 27.04.2014 22:40, Thiago Macieira wrote:
Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
On 26.04.2014 17:39, André Pönitz wrote:
You could have made the point declarative structures are good for GUI
description for Qt Widget's .ui files, after all, .ui files contents
pretty much
http://qt-project.org/doc/qt-5/supported-platforms.html
Embedded Linux (DirectFB, EGLFS, KMS, and Wayland)
Am I right that this sentence is the complete documentation
for using Qt 5 on an embedded system?
Nothing about how to build, what's needed for QML,
what for QWidgets, how to replace qws,
On 19.10.2013 17:17, Hausmann Simon wrote:
Looks good to me. (although I would prefer the more
descriptive Qt msvc version macros)
Can you submit this to gerrit stable branch and Cc me?
stable for qt4? I had already pushed 2 patches to 4.8.
Simon
*Fra: *Yuchen Deng
*Sendt: *15:37
On 05.09.2013 12:10, Daniel Teske wrote:
QScopedPointer has never been a scoped pointer. It has always had a .reset()
method. That should never have been part of QScopedPointer.
I wonder if this would happen again with the current review process.
daniel#
On 06.09.2013 19:52, David Faure wrote:
connect(job, SIGNAL(result(QJob*)),
this, SLOT(handleResult(QJob*)));
This looks so old-school like in times of futures and monads.
Couldn't such a class be part of the hopefully coming QtConcurrent replacement?
Peter
On 10.09.2013 08:16, Knoll Lars wrote:
Develop it in a playground project, show why it makes sense and once you have
a stable API let's discuss into which module it should go.
An idea I already had when I saw the QUniquePoiner implementation:
Couldn't we add a new branch to
On 04.09.2013 07:36, Olivier Goffart wrote:
On Tuesday 03 September 2013 21:20:20 Peter Kümmel wrote:
It is of great benefit that you never had to think about if
QScopedPointer(5.1) will delete when leaving scope.
That's not true.
QScopedPointer... myPtr(foo());
myPtr.take();
Sure
On 03.09.2013 22:47, Thiago Macieira wrote:
On terça-feira, 3 de setembro de 2013 22:12:58, Oswald Buddenhagen wrote:
A non-null QScopedPointer deletes when it leaves the scope.
which sounds quite reasonable to me.
It still does that.
Moving out of a QScopedPointer simply means taking
On 03.09.2013 22:12, Oswald Buddenhagen wrote:
On Tue, Sep 03, 2013 at 09:20:20PM +0200, Peter Kümmel wrote:
Adding a move contructor to QScopedPointer makes no sense, because moving
means 'escaping the scope', which breaks the fundamental point of
QScopedPointer. QScopedPointer is different
On 04.09.2013 09:16, Thiago Macieira wrote:
On quarta-feira, 4 de setembro de 2013 09:00:14, Peter Kümmel wrote:
But then you could use take() add wrap the pointer with something else,
only this way I would call explicit.
What's that something else? Remember that QScopedPointer was created
On 04.09.2013 17:54, Thiago Macieira wrote:
On quarta-feira, 4 de setembro de 2013 10:20:39, Peter Kümmel wrote:
What's that something else? Remember that QScopedPointer was created to
simplify handling of exceptions (when we tried to care about exceptions).
If we have to take the pointer out
Adding a move contructor to QScopedPointer makes no sense, because moving
means 'escaping the scope', which breaks the fundamental point of
QScopedPointer. QScopedPointer is different to std::unique_ptr and should
remain so.
I have to agree with Steven. After allowing moving, the semantic is
On 10.03.2013 16:54, Sze Howe Koh wrote:
Olivier started implementing this:
https://codereview.qt-project.org/#change,49864
Last year I gave it also a try,
http://lists.qt-project.org/pipermail/development/2012-June/004580.html
On 19.02.2013 20:29, Turunen Tuukka wrote:
We have the packages ready and tested with minor
fixes compared to RC1 (21st Dec). If we re-do these
packages it is a significant effort with very limited benefits.
It seems to me this already happens before:
you first do the packaging and then
On 21.02.2013 14:00, Turunen Tuukka wrote:
Unfortunately we do not have unlimited resources in the release team, so
pointlessly redoing the packages is not something I want to do.
I would release the already packaged versions as they are as a
Digia-only release, and skip 4.8.5/4.7.6 in the
On 01.02.2013 01:37, Alan Alpert wrote:
That said, I'd prefer it for us to reach a consensus that the
abandoned state should mean abandoned (adj 2 of
http://en.wiktionary.org/wiki/abandoned) instead of destroyed (past
participle of verb 1, http://en.wiktionary.org/wiki/destroy). Then
The problem with the original request to simply make all changes
abandoned is that it will destroy the differentiation between
trash and not interested in atm.
Another problem is that some touches your changes you've invested
time and motivation and simply moves it into the trash can.
Please
On 30.01.2013 19:23, Charley Bay wrote:
I've implemented a C++ adapter-layer (mostly template-based) to expose
C++ objects to QML.
We are in the early-stages for its use, and (of course) the final-API
will significantly impact how we expose our (domain-specific) C++ classes
to QML.
My
On 29.01.2013 13:05, Oswald Buddenhagen wrote:
moin *,
5.0 is out and the 5.1 feature freeze isn't that far off any more.
seems like the best time for some serious house cleaning.
therefore i'd like to urge everyone to give their pending changes which
haven't seen activity for a long time a
Seems currently everybody could merge to staging.
I as non-approver have a merge button in gerrit.
Or is this only a new feature to see if the
request passes all tests?
Peter
___
Development mailing list
Development@qt-project.org
On 26.01.2013 07:34, Laszlo Papp wrote:
Good question; we discussed this issue before. This is unfortunately also a
real problem for us to test the module with
all the combinations for each factor. It requires (semi-)manual testing and
hence a bit of effort. I see two ways to
improve the
On 18.01.2013 14:37, Motyka Rafal wrote:
Hello,
Qt 5.0.1 release testing has been started. We would like to kindly ask the Qt
Community for help by testing the new
packages.
1. Installer packages are available here:
http://releases.qt-project.org/digia/5.0.1/backups/2013-01-18-412/
On 10.01.2013 19:56, Ruslan Nigmatullin wrote:
Botan, as I see is C++ wrapper around OpenSSL itself.
Are you sure? It looks different on their site:
http://botan.randombit.net/index.html
Qt already has OpenSSL dependency. What's are benefits of using it if Botan
is just additional
On 09.01.2013 17:11, Salovaara Akseli wrote:
Hi,
Qt 5.0.1 release branching is ongoing and there are already around 300
commits available since Qt 5.0.0 release.
Ahm, what was the difference between release and a tag, and between release
and stable?
There are also quite many bugs
On 10.01.2013 23:31, Sergio Ahumada wrote:
On 01/10/2013 11:29 PM, Peter Kümmel wrote:
On 09.01.2013 17:11, Salovaara Akseli wrote:
Hi,
Qt 5.0.1 release branching is ongoing and there are already around 300
commits available since Qt 5.0.0 release.
Ahm, what was the difference between
On 02.01.2013 14:33, Lincoln Ramsay wrote:
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
On 02.01.2013 14:18, Thiago Macieira wrote:
On quarta-feira, 2 de janeiro de 2013 14.01.02, 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
On 04.01.2013 12:27, Thiago Macieira wrote:
On sexta-feira, 4 de janeiro de 2013 09.35.33, Peter Kümmel wrote:
Isn't on Windows only PATH used to figure out which Dll to load?
Correct.
Then
qt.conf in the same dir as QtCore/qmake should be enough on Windows, or
missed I something?
You
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 at least some information about what it does? Because the
On 04.12.2012 12:28, Oswald Buddenhagen wrote:
On Mon, Dec 03, 2012 at 04:29:24PM +, Knoll Lars wrote:
Dev is the branch where you can land anything that's supposed to go into
5.1. The following policies apply:
Stable:
This branch will be the basis for Qt 5.0 and subsequent patch level
Currently on Windows private headers are needed when
#include QtGui is used.
\include\QtGui\QtGui
\include\QtGui\QPlatformNativeInterface
which needs 5.0.0\qpa\qplatformnativeinterface.h
Is this by design?
Peter
___
Development mailing list
On 08.10.2012 18:07, Thiago Macieira wrote:
On segunda-feira, 8 de outubro de 2012 16.37.46, Peter Kümmel wrote:
Currently on Windows private headers are needed when
#include QtGui is used.
\include\QtGui\QtGui
\include\QtGui\QPlatformNativeInterface
which needs 5.0.0\qpa
This discussion shows another problem.
ATM it is not possible to release a Qt4 version
(has Qt5 the same problem?) with a proper version
number based on an already released version and
containing only some patches.
This is not only a scenario when the Qt copyright
changes. It could happen all
The ABI incompatibilities have been fixed for GCC version 4.7.2
but as a result C++11 code compiled with GCC 4.7.0 or 4.7.1 may
be incompatible with C++11 code compiled with different GCC
versions and with C++98/C++03 code compiled with any version.
Did they know what they were doing with
On 03.09.2012 16:10, kai.koe...@nokia.com wrote:
My suggestion on how to proceed is to choose one that offers the following or
most of the following:
- most recent GCC (4.7 preferably, 4.6 if not)
Latest mingw-builds and latest rubenv packages both provide 4.7.1
- *working* GDB and
On 30.08.2012 18:16, Thiago Macieira wrote:
On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote:
There are more differences than that. There are differences in
features, such as threading support, large-file support, etc.
Mingw-w64 is usually ahead of any other in terms
On 01.09.2012 12:39, Thiago Macieira wrote:
On sábado, 1 de setembro de 2012 12.23.31, Peter Kümmel wrote:
As a general rule, you should choose the default SJLJ packages,
unless you know you need faster exception handling and can guarantee
you'll never need to unwind
On 01.09.2012 12:47, Peter Kümmel wrote:
On 01.09.2012 12:39, Thiago Macieira wrote:
On sábado, 1 de setembro de 2012 12.23.31, Peter Kümmel wrote:
As a general rule, you should choose the default SJLJ packages,
unless you know you need faster exception handling and can
On 01.09.2012 12:52, Thiago Macieira wrote:
On sábado, 1 de setembro de 2012 12.47.15, Peter Kümmel wrote:
So you think it is possible to use DW2 for 32 bit binaries?
Yes.
What happens if a binary compiled with GCC/DW2 calls a
C++ function in a Dll compiled with MSVC and this function
On 31.08.2012 09:02, Pau Garcia i Quiles wrote:
All those MinGW and forks contain mingw32-make.exe util which does have -j
option, but in fact this option doesn't make the real parallel build. Maybe
sh.exe is needed, but this shell util will pass the incompatible path string
so that the build
On 30.08.2012 18:16, Thiago Macieira wrote:
On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote:
There are more differences than that. There are differences in
features, such as threading support, large-file support, etc.
Mingw-w64 is usually ahead of any other in terms
On 31.08.2012 09:00, Yves Bailly wrote:
Hello all,
Le 30/08/2012 14:33, Yves Bailly a écrit :
Le 30/08/2012 13:23, lars.kn...@nokia.com a écrit :
the Qt 5 beta has now been released. Please find all the details at
http://www.qt-project.org/wiki/Qt-5-Beta
Trying to compile on Windows 7
On 31.08.2012 13:31, Thiago Macieira wrote:
On sexta-feira, 31 de agosto de 2012 12.05.00, Laszlo Papp wrote:
On my suggestion, we dropped .tar.bz2. We're keeping .tar.gz to ensure
maximum
compatibility and .tar.xz because it's the smaller of the three.
Was this decision publicly discussed
On 31.08.2012 13:54, Thiago Macieira wrote:
On sexta-feira, 31 de agosto de 2012 13.40.38, Peter Kümmel wrote:
On the #qt-release channel, then reviewed through Gerrit.
https://codereview.qt-project.org/33837
This is a little bit behind closed doors.
Similar to the decision releasing beta
On 30.08.2012 18:16, Thiago Macieira wrote:
My suggestion on how to proceed is to choose one that offers the following or
most of the following:
- most recent GCC (4.7 preferably, 4.6 if not)
- *working* GDB and tested with Creator, with Python support
- large file support, threading
On 29.08.2012 02:02, Rohan McGovern wrote:
Is there a list which configurations are checked by the CI?
Yes, you can check the list from testresults.qt-project.org, e.g.
http://testresults.qt-project.org/ci/QtBase_master_Integration/latest-success/
For the quality gate checks such a short
On 28.08.2012 10:34, Stephen Kelly wrote:
On Monday, August 27, 2012 19:23:19 Peter Kümmel wrote:
On 27.08.2012 19:14, Peter Kümmel wrote:
Cross-compiling with mkspec/win win32-g++ doesn't
This doesn't mean anything to me. What is the host and what is the target?
On Linux with mingw to win32
On 28.08.2012 11:03, Stephen Kelly wrote:
On Tuesday, August 28, 2012 10:44:58 Peter Kümmel wrote:
In the build dir the files are in lib/cmake, but
they are not copied to the install dir.
Does the install step complete without warnings or errors?
No, there are no cmake rule in the Makefiles
On 28.08.2012 12:04, Stephen Kelly wrote:
On Tuesday, August 28, 2012 11:49:28 Peter Kümmel wrote:
I tried it again from scratch, and I was wrong, it also doesn't work
on 12.04, only one file is copied: lib/cmake/Qt5Core/Qt5CTestMacros.cmake
Ok. Please tell me how to try it out.
'aptitude
On 28.08.2012 12:18, Peter Kümmel wrote:
On 28.08.2012 12:04, Stephen Kelly wrote:
On Tuesday, August 28, 2012 11:49:28 Peter Kümmel wrote:
I tried it again from scratch, and I was wrong, it also doesn't work
on 12.04, only one file is copied: lib/cmake/Qt5Core/Qt5CTestMacros.cmake
Ok
to be copied to
win32-mainwindow/platforms. I cannot imagine that the msvc runtime is
missing, because you are using the mingw compiler and the compiler does
not use the msvc runtine...
Am 28.08.2012 13:37, schrieb Peter Kümmel:
On 28.08.2012 12:18, Peter Kümmel wrote:
On 28.08.2012 12:04, Stephen
I've tried to build qtbase
1. on Windows 7
2. rubenvb's mingw-w64:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release/
3. in Windows shell cmd.exe
4. as shadow build with ..\qtbase\configure.bat -fast -nomake demos -nomake
On 28.08.2012 19:27, marius.storm-ol...@nokia.com wrote:
On 28/08/2012 12:16, ext Peter Kümmel wrote:
I've tried to build qtbase
1. on Windows 7
2. rubenvb's mingw-w64:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release
On 28.08.2012 19:59, marius.storm-ol...@nokia.com wrote:
On 28/08/2012 12:48, ext Peter Kümmel wrote:
On 28.08.2012 19:27, marius.storm-ol...@nokia.com wrote:
On 28/08/2012 12:16, ext Peter Kümmel wrote:
Have I missed something or is building with mingw in cmd.exe not supported
On 28.08.2012 21:12, marius.storm-ol...@nokia.com wrote:
On 28/08/2012 13:46, ext Peter Kümmel wrote:
On 28.08.2012 19:59, marius.storm-ol...@nokia.com wrote:
On 28/08/2012 12:48, ext Peter Kümmel wrote:
But also jom fails, I thought jom could also handle mingw
makefiles?
No, Jom only
qtbase/examples/widgets/mainwindows/mainwindow
crashes here immediately on startup. Attached the backtrace.
It's a fresh Qt5 build on a virtual machine.
Ubuntu 12.04 based distro
gcc 4.6.3
All is fine with Qt4.
I have a debug setup here so I could provide more information.
Peter
(gdb) bt
#0
On 27.08.2012 13:12, Peter Kümmel wrote:
qtbase/examples/widgets/mainwindows/mainwindow
crashes here immediately on startup. Attached the backtrace.
It's a fresh Qt5 build on a virtual machine.
Ubuntu 12.04 based distro
gcc 4.6.3
All is fine with Qt4.
I have a debug setup here so I could
On 27.08.2012 13:30, Thiago Macieira wrote:
On segunda-feira, 27 de agosto de 2012 13.23.47, Peter Kümmel wrote:
On 27.08.2012 13:12, Peter Kümmel wrote:
qtbase/examples/widgets/mainwindows/mainwindow
crashes here immediately on startup. Attached the backtrace.
It's a fresh Qt5 build
Cross-compiling with mkspec/win win32-g++ doesn't
install the cmake files into lib/cmake.
The line in mkspecs/features/create_cmake.prf
INSTALLS += cmake_qt5_module_files
is called but ignored, there are no install rules
in the Makefiles for cmake files.
Any ideas how to fix this?
Peter
When building plugins, moc generates files with '#ifdef QT_NO_DEBUG'
but the lib/cmake modules doesn't add QT_NO_DEBUG for release builds.
A bug?
Peter
___
Development mailing list
Development@qt-project.org
http://doc-snapshot.qt-project.org/5.0/qtplugin.html#Q_PLUGIN_METADATA
When Q_PLUGIN_METADATA() is used with a FILE name which doesn't
exist, moc throws an error, but when FILE isn't present at all
moc silently doesn't generate the pluginMetaData[]s.
Isn't this a bug?
Peter
On 26.08.2012 20:14, Peter Kümmel wrote:
http://doc-snapshot.qt-project.org/5.0/qtplugin.html#Q_PLUGIN_METADATA
When Q_PLUGIN_METADATA() is used with a FILE name which doesn't
exist, moc throws an error, but when FILE isn't present at all
moc silently doesn't generate the pluginMetaData[]s
Qt could be compiled native or cross for a system
different to the system on which Qt is build.
But this is not how mkspecs/ is organized:
linux-*native
win32-*native
wince* cross
unsupported/* cross and native
device/* cross
also configure supports different
On Sun, 19 Aug 2012 12:00:25 +0200
Thiago Macieira thiago.macie...@intel.com wrote:
I'd actually prefer that you clean this up *after* we switch buildsystems,
Ahhh! :)
whenever that happens. Cleaning up configure is an unnecessary task if we're
going to throw it away soon after.
Please
On 22.06.2012 09:26, Olivier Goffart wrote:
Nice stuff. Now you just need to make it for Qt5, and handle all the special
cases :-)
There is a room for tests in tets/auto/tools/moc (I'm saying that because you
made your test somewhere else)
OK, ported to Qt5 now:
On 19.06.2012 14:31, Oswald Buddenhagen wrote:
moin,
the buildsystem branch of qtbase is currently being integrated. this is
~120 commits worth of qmake project file fixes and cleanups. there are
some changes to how modularization (in particular configure tests) is
handled, and
On 19.06.2012 11:04, Olivier Goffart wrote:
templatetypename T QMetaObject AT::staticMetaObject = { ... };
Hi Oliver,
looking at this with some hacking on moc,
templateclass T
class Foo : public QObject
{
Q_OBJECT
public:
Foo() {}
signals:
void asignal(T t);
};
it looks like
On 20.06.2012 12:31, Thiago Macieira wrote:
On quarta-feira, 20 de junho de 2012 10.47.01, Peter Kümmel wrote:
When Fooint is used, we would need the meta type information
with 'int' not with T:
static const char qt_meta_stringdata_Fooint[] = {
Fooint\0\0t\0asignal(int)\0
};
Who
On 20.06.2012 13:38, Thiago Macieira wrote:
On quarta-feira, 20 de junho de 2012 13.09.40, Peter Kümmel wrote:
On 20.06.2012 12:31, Thiago Macieira wrote:
On quarta-feira, 20 de junho de 2012 10.47.01, Peter Kümmel wrote:
When Fooint is used, we would need the meta type information
After the noise here real code:
https://qt.gitorious.org/~syntheticpp/qt/qt4/commit/c1b839494d90e8c1a93b0dd2e08a2a365095d89f
Based on Qt 4.8.2.
moc creates a header when it finds a template, if not then nothing changes.
(It builds Qt with the patch, but it's a hack in the parser)
In summary
On 19.06.2012 08:44, Thiago Macieira wrote:
Yes, I know about it. No, I did not look at it. I cannot do that because I
need to write code of my own. I cannot look at other people's code and submit
to the Qt Project under the CLA, unless it's in the public domain.
You must not read other
On 19.06.2012 09:11, Rene Jensen wrote:
Is this crazy talk? I would imagine that given a set of containers like ...
hmm ... QSmartList, QSmartMap, QSmartHash
inheriting from QObject (yes, I know ... moc and templates bla bla - I could
live with fixed key/value-types if that's
what it takes
On 19.06.2012 09:39, Thiago Macieira wrote:
On terça-feira, 19 de junho de 2012 09.21.46, Peter Kümmel wrote:
On 19.06.2012 08:44, Thiago Macieira wrote:
Yes, I know about it. No, I did not look at it. I cannot do that because I
need to write code of my own. I cannot look at other people's
On 19.06.2012 09:58, Thiago Macieira wrote:
On terça-feira, 19 de junho de 2012 09.54.15, Peter Kümmel wrote:
So even no Apache licensed code could be used within Qt?
Irrelevant. The CLA says that I can only submit code I authored myself. That
excludes everything that has a copyright
BTW, are there any plans to use lock-free techniques somewhere within Qt?
Or have you already evaluated it? The lock-free strategy looks a bit
like transactional memory: try it until it is right.
Peter
___
Development mailing list
On 19.06.2012 10:00, Thiago Macieira wrote:
On terça-feira, 19 de junho de 2012 09.51.32, Peter Kümmel wrote:
On 19.06.2012 09:11, Rene Jensen wrote:
Is this crazy talk? I would imagine that given a set of containers like
... hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject
On 19.06.2012 11:28, Thiago Macieira wrote:
On terça-feira, 19 de junho de 2012 10.22.02, Peter Kümmel wrote:
Moc can understand template code just fine for the output it produces. The
problem is that the meta object format does not allow for signals and
slots
containing template parameters
On 19.06.2012 11:04, Olivier Goffart wrote:
On Tuesday 19 June 2012 10:22:02 Peter Kümmel wrote:
On 19.06.2012 10:00, Thiago Macieira wrote:
On terça-feira, 19 de junho de 2012 09.51.32, Peter Kümmel wrote:
On 19.06.2012 09:11, Rene Jensen wrote:
Is this crazy talk? I would imagine that given
On 19.06.2012 22:50, Brad King wrote:
On 06/19/2012 04:09 PM, Peter Kümmel wrote:
Some small questions to the workflow:
- I read on the workflow description site
Topic Branch
...
Heads not published (no named branch on server)
What does this mean? I see all the named branches
On 07.06.2012 08:35, Rohan McGovern wrote:
Molkentin Daniel (Nokia-MP/Berlin) said:
It means that the current CI infrastructure is operated by Nokia and
can't have build nodes plugged in from outside of Nokia premises. So,
if you need to manage your own build nodes, there is currently no way
On 22.05.2012 21:44, Thiago Macieira wrote:
On terça-feira, 22 de maio de 2012 20.52.47, Peter Kümmel wrote:
Does anybody know if it is possible to use Qt (at lease QtCore)
on FreeRTOS, http://www.freertos.org/
Qt runs on QNX, but does this mean it would also run on FreeRTOS?
Or is QNX
On 16.05.2012 20:31, qtnext wrote:
I am using Qt since 12 years or more... I have done a lot of work using
qwidget, qgraphiscview,
I have done some small apps with qml to display media : it works very well
... just the animation are a a litlle bit
jerky and work not well on very small
On 17.05.2012 14:42, Иван Комиссаров wrote:
Well, i do care about what happen to QWidgets. Maybe i'm old-fashioned (i'm
23 years old, heh), but i do have lot of code based on QWidgets. And that
code works. So, you suggest me to thow away all code i've made, because
QWidgets have bad design?
.
Atlant
-Original Message-
From: development-bounces+aschmidt=dekaresearch@qt-project.org
[mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On
Behalf Of Peter Kümmel
Sent: Thursday, May 17, 2012 02:12
To: development@qt-project.org
Subject: Re
On 13.01.2012 14:10, Mathias Hasselmann wrote:
Am Freitag, den 13.01.2012, 13:00 + schrieb Giuseppe D'Angelo:
On 13 January 2012 12:32, Mathias Hasselmannmath...@openismus.com wrote:
what about the slightly more garden-variety approach of deprecating
the old one and introducing a new
98 matches
Mail list logo
