Hi,
we'd like to change the format of qt_attribution.json files a tiny bit.
Currently, the Copyright key takes a string as value, and for
readability purposes we used invalid JSON like this:
"Copyright": "Copyright (C) 2002, 2003 CodeFactory AB
Copyright (C) 2004, 2005 Red Hat, Inc."
We
On 8/1/23 14:22, Haowei Hsu wrote:
However, it turns out that there is an error in the Step 7:
You're doing a prefix build [1] but you did not build & install before
building the docs. The error indicates a missing file in the install prefix.
Try a non-prefix build instead. Without
On 2/15/23 14:46, Jörg Bornemann via Development wrote:
we're proposing a new QUIP: License specification in Qt's modules
Please review https://codereview.qt-project.org/c/meta/quips/+/436096
And because QUIP 3 suggests that the initial text is also sent to the
mailing list - here's the
On 11/21/22 03:38, Thiago Macieira wrote:
I've just finished a qtbase build on Linux with two sub-architectures and the
symbol comparison of all the resulting libraries has shown zero difference.
Tomorrow I will test all other modules (except qtwebengine). The code is ugly,
so I'd appreciate
On 5/24/22 15:14, Lisandro Damián Nicanor Pérez Meyer wrote:
I'll try to participate in the summit slot for this. Maybe we can
reuse Debian's DEP5 files?
Yes, we might use them for 3rdparty libs in the future. In fact, they
are part of the REUSE spec.
And webengine is... a pain. But I
On 11/26/21 1:26 AM, Thiago Macieira wrote:
We're just the canary. There are a lot of people cross-compiling from Linux
because the environment is much faster.
If there are a lot of people doing this we should consider raising
cross-compiling from Linux to Windows from "unsupported" to
On 11/25/21 5:03 PM, Thiago Macieira wrote:
The patches that do the move are here:
https://codereview.qt-project.org/c/qt/qtbase/+/382055
https://codereview.qt-project.org/c/qt/qttools/+/382099
Please review.
Belated -1 after testing. Can I ask that it be reverted?
Reverting because of the
On 11/16/21 12:06 PM, EXT Craig Scott wrote:
[proposal to move macdeployqt and windeployqt to qtbase]
Both macdeployqt and windeployqt are small and don’t depend on anything
other that QtCore (their tests do depend on QtTest as well).
With feature freeze for 6.3 only a few weeks away, it
On 11/15/21 5:41 PM, Marius Kittler wrote:
Am Montag, 15. November 2021, 16:46:31 CET schrieben Sie:
On Monday, 15 November 2021 05:52:46 PST Joerg Bornemann wrote:
There's already a target called host_tools to build the necessary tools.
An install target/component for it is missing though
On 11/10/21 4:26 PM, Thiago Macieira wrote:
Considering tools aren't going to be bootstrapped any more, the host build of
the tools might be quite complete. It needs to include at least every library
that the tools depend on. So for example it will need to go all the way to
qttools to build
On 11/5/21 12:06 AM, Volker Hilsheimer wrote:
Does anyone other than developers of Qt (and for us this could be a real time
saver!) really need and benefit from this? I’d rather not want to ask our
support team to support customers and users with a colorful blend of moc and
library versions.
On 10/29/21 11:43 AM, Joerg Bornemann wrote:
With https://codereview.qt-project.org/c/qt/qtbase/+/378053 it's now
possible to turn off the package version check and to use moc of a
different Qt version. This requires that moc stays either compatible or
handles that /version argument outlined
On 10/28/21 5:52 PM, Thiago Macieira wrote:
On Wednesday, 27 October 2021 23:02:38 PDT Joerg Bornemann wrote:
a problem, I just want to know if this is required.
ping for decision prior to 6.3 feature freeze.
With https://codereview.qt-project.org/c/qt/qtbase/+/378053 it's now
possible
On 10/27/21 7:18 PM, Thiago Macieira wrote:
On Friday, 10 September 2021 07:58:55 PDT Thiago Macieira wrote:
Qt 6 supports using the moc from a different build of Qt, to help with the
bootstrapping issue and also so you don't always run a debug-mode moc in
your debug builds of Qt.
Is that moc
On 9/22/21 11:30 AM, Rasool, Ansar wrote:
I am trying to build qtsystems 5.15.1 on my Ubuntu 18.04 host but it
throws build error for first time. Error is given below:
...
from the build logs, it seems that the qml-inputinfo.pro file tries to
installs the qml-inputinfo.qml app multiple times
On 9/14/21 9:08 PM, Joerg Bornemann wrote:
I've experimented with this and came up with
https://codereview.qt-project.org/c/qt/qtbase/+/370958
which allows to build qtbase dev (6.3.0) against a host Qt 6.1.2.
Doesn't work with non-qtbase repos though.
And this is, because Qt6Foo depends
On 9/15/21 5:21 AM, Thiago Macieira wrote:
On Tuesday, 14 September 2021 09:03:59 PDT Joerg Bornemann wrote:
Unless QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON which is used in yocto
context.
I don't see why Yocto Project recipes need to be special.
They don't need to be special, it's just
On 9/14/21 4:35 PM, Thiago Macieira wrote:
FWIW, in multi-config builds, with a recent enough CMake version, tools
are built in release config only.
$ cmake --version
cmake version 3.21.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
Should I upgrade?
No, that's
On 9/14/21 6:10 PM, Joerg Bornemann wrote:
On 9/14/21 4:29 PM, Thiago Macieira wrote:
On Tuesday, 14 September 2021 00:51:21 PDT Joerg Bornemann wrote:
The maintenance burden is next level. This would mean to keep all
internal API that's used in lib/cmake compatible. Apparently forward
On 9/14/21 4:29 PM, Thiago Macieira wrote:
On Tuesday, 14 September 2021 00:51:21 PDT Joerg Bornemann wrote:
The maintenance burden is next level. This would mean to keep all
internal API that's used in lib/cmake compatible. Apparently forward and
backward if I read your requirements correctly
On 9/14/21 5:45 PM, Thiago Macieira wrote:
On Tuesday, 14 September 2021 08:37:55 PDT Joerg Bornemann wrote:
Only moc should link to the Bootstrap lib. Period.
Well, I guess rcc could also use some good pinch of bootstrapping.
And tracegen for that matter.
Well, tracegen might, since it's
On 9/14/21 4:30 PM, Thiago Macieira wrote:
On Tuesday, 14 September 2021 00:56:08 PDT Joerg Bornemann wrote:
No it's not. There are more tools in other repos that are used in a
cross-build. Bootstrapped or not does barely matter for cross-building.
A proper host-tools-only build has been
On 9/14/21 12:11 PM, Marius Kittler wrote:
Am Dienstag, 14. September 2021, 09:51:21 CEST schrieb Joerg Bornemann:
The maintenance burden is next level. This would mean to keep all
internal API that's used in lib/cmake compatible. Apparently forward and
backward if I read your requirements
On 9/13/21 8:21 PM, Thiago Macieira wrote:
Alternatively it would also be interesting to provide a "tools only" build
to be able to provide host tools of the required version. However, I
actually like not having to build tools over and over again for every
target so a "compatible" moc sounds
On 9/14/21 9:25 AM, Fabian Kosmale wrote:
I wouldn't mind adding/helping with adding/reviewing the necessary code to moc
so that it has that
compatibility support. I can certainly see the use case for it. However, I
think there are still two
things missing:
- a confirmation from Jörg that the
On 9/13/21 5:30 PM, Thiago Macieira wrote:
For a cross-build, currently, the host Qt needs to have the same version
as the target Qt. When trying to build, let's say, Qt for Android 6.2.0
with a host Qt 6.1.2, you're getting an error:
Could not find a configuration file for package
On 9/10/21 4:58 PM, Thiago Macieira wrote:
Qt 6 supports using the moc from a different build of Qt, to help with the
bootstrapping issue and also so you don't always run a debug-mode moc in your
debug builds of Qt.
Is that moc required to be from the same Qt version as the Qt you're trying to
Hi there!
I'd like to nominate Craig Scott as approver.
Craig, whom you might know as CMake co-maintainer and author of
"Professional CMake: A Practical Guide", is helping us with the Qt6
build system since last year. He's a never drying up source of CMake
wisdom which he shares in his
Hi there!
I'd like to nominate Alexey Edelev as approver.
Alexey has worked on the Qt6 build system and tools since he started
last year in TQtC. He also did several CMake upstream fixes, mostly
related to AUTOMOC/AUTOUIC.
His gerrit dashboard is here:
Hi,
The CMake build in Qt 6 uses configure.cmake files that have been
converted from the configure.json files. If you've changed a
configure.cmake file you probably have been asked to change
configure.json too - to keep the content in sync.
This modus operandi is tedious and error-prone.
At
On 5/22/21 3:06 AM, Giuseppe D'Angelo via Development wrote:
As detailed in the other thread, I'd like to gather lazy consensus for
moving the official IRC presence from Freenode to Libera.Chat.
+1
Cheers,
Joerg
___
Development mailing list
On 5/21/21 2:49 PM, Benjamin TERRIER wrote:
Please don't cut half of what I said to make me say something I did not say.
I did not do that at all. I merely quoted what I wanted to answer.
You said that during Trolltech times that Qt Windows was commercial
only and the open source part was
On 5/21/21 12:41 PM, Benjamin TERRIER wrote:
And now:
- all new modules and supported platforms are Commercial/GPLv3 only.
Which is very different from commercial-only.
Can we conclude that contributions from outside the company are going to
be nearly non-existent?
Based on the facts? No.
On 5/20/21 5:16 PM, Jason H wrote:
*if you wonder why I keep calling them Digia and not the Qt Company, it is
because the actions of late don't really feel like Qt of old (Nokia, TrollTech)
would have treated opens source users that way. Looking at the management:
On 5/6/21 12:16 AM, Scott Bloom wrote:
One thing to consider here.
Visual Studio is now shipping CMake, its also getting updated for patches of a
given version of VS, and is not the same from VS 2019 or VS 2017
I know of a couple of teams that are using the VS version of CMake on windows
to
On 3/1/21 10:03 AM, Edward Welbourne wrote:
Can fixqt4headers.pl be removed from Qt6?
Seems sane to me.
One less perl script ...
Here we go: https://codereview.qt-project.org/c/qt/qtbase/+/336822
Cheers,
Joerg
___
Development mailing list
Hi,
I noticed that we still have fixqt4headers.pl in our bin directory.
For the uninitiated, this is it's documentation:
https://doc.qt.io/qt-5/portingcppapp.html
That page is already gone in Qt6.
Can fixqt4headers.pl be removed from Qt6?
Cheers,
Joerg
On 2/26/21 2:23 PM, Kai Köhne wrote:
With https://codereview.qt-project.org/c/qt/qtbase/+/336652 a copy is made
if a hard-link cannot be created.
Right, but that is at configure time, this doesn’t help with the online
installer.
To be pedantic, it's at cmake --install time. :-)
If we go
On 2/24/21 8:54 AM, Elvis Stansvik wrote:
I guess it rules out installing to e.g. a FAT-formatted USB-stick, but I
don't know if that's a thing. Could be considered an edge case and
documented not to work.
With https://codereview.qt-project.org/c/qt/qtbase/+/336652 a copy is
made if a
On 2/24/21 12:56 PM, Bogdan Vatra wrote:
Let me give you another non-android example:
You want to create a standalone SDK for linux armhf using yocto. You'll
generate the SDK with everything including Qt for host and for target, the sdk
is a huge auto extract archive which can be shared with
On 2/24/21 9:30 AM, Bogdan Vatra wrote:
Do you still believe that I'm one of the few affected by this?
Don't you think that everyone who's using cross compiling is affected?
I have seen cross-compiling folks using the cross-platform abilities of
Qt to prototype stuff on desktop. The
On 2/23/21 8:52 PM, Thiago Macieira wrote:
On Tuesday, 23 February 2021 00:00:22 PST Joerg Bornemann wrote:
On 2/20/21 2:44 AM, Thiago Macieira wrote:
Besides, doesn't Windows now have symlinks?
For admin users only unless an admin user enables them for everyone.
Hard-links are available
On 2/23/21 12:27 PM, BogDan Vatra via Development wrote:
OK, biting.
- first and foremost, we need to waste time to **fully** build and install it
for host platform (desktop).
No, you don't need a full build. You need the tools that are called by
the build system. The support for creating a
On 2/20/21 2:44 AM, Thiago Macieira wrote:
Besides, doesn't Windows now have symlinks?
For admin users only unless an admin user enables them for everyone.
Hard-links are available though on NTFS.
Cheers,
Joerg
___
Development mailing list
On 2/16/21 5:36 PM, Thiago Macieira wrote:
We're simply asking that we make official what is already done everywhere.
Yes, and that's all good, and with
https://codereview.qt-project.org/c/qt/qtbase/+/334054 we will have an
offical recommendation.
I will also add a documentation page in the
On 2/12/21 8:28 PM, Thiago Macieira wrote:
On Friday, 12 February 2021 01:21:39 PST Joerg Bornemann wrote:
Each line of user_facing_tool_links.txt consists of the installation
path of a user-facing application followed by a space and the versioned
link name in INSTALL_PUBLICBINDIR
Hi,
here comes an update on the status of co-installability of Qt5 and Qt6.
For the main issue QTBUG-89170, I've created
https://codereview.qt-project.org/c/qt/qtbase/+/334054
Package maintainers, please review this patch.
Let me paste parts of the commit message to fill you in what this is
On 2/4/21 12:20 PM, Volker Hilsheimer wrote:
The 6.1 branch’s sha1 is whatever the sha1 in dev was when the branch was
created. Things start to diverge from there, but at branching sha1, the new
branch’s consistent set is whatever .qtmodules and dependencies.yaml states at
that time. Does it
On 2/3/21 5:36 PM, Volker Hilsheimer wrote:
Milk, Joerg.
Blame my handwriting!
But why not get rid of the gap in the first place, ie instead of having a gap
between
- final dependency update sha1s are fixed, full update round started
- 6.1 branch is created
What stops us from simply
On 2/3/21 11:42 AM, Edward Welbourne wrote:
The change in question cannot have the Pick-to: 6.1 footer, because
the branch does not exist. How can I avoid to forget cherry-picking
that change, once 6.1 is in place?
Yes, that’s a risk with cherry-pick mode.
That's the confirmation I was
On 2/1/21 1:34 PM, Jani Heikkinen wrote:
Qt 6.1 Feature Freeze is in effect now. So please do not add any new features,
API changes ect in 'dev' anymore until we have done branching from 'dev' to
'6.1'. We are trying to do branching from 'dev' to '6.1' as soon as possible
but at first we
On 1/15/21 8:46 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
Second, it's not a feature.
I disagree, *it's* a feature, a much needed and awaited feature.
What I meant was: feature freeze should not be the barrier for this change.
Cheers,
Joerg
On 1/11/21 6:20 PM, Thiago Macieira wrote:
On Monday, 11 January 2021 02:45:13 PST Jani Heikkinen wrote:
Qt 6.1 Feature Freeze will be effect at the end of January so there is only
3 weeks left to implement new features for Qt 6.1!
Where's the tool renaming changes in the CMakeLists.txt? It's
On 1/13/21 5:28 PM, Thiago Macieira wrote:
On Wednesday, 13 January 2021 05:37:21 PST Volker Hilsheimer wrote:
* stop using git submodules
Using them serves no real purposes anymore. We anyway have our own scripting
in form of init-repository to avoid that people have to deal with that
stuff.
On 10/27/20 5:34 PM, Thiago Macieira wrote:
Have we fixed it?
The discussion apparently petered out as everytime this came up - or
maybe I just missed that we now have consensus on how to name things and
where to put stuff?
Kai created https://bugreports.qt.io/browse/QTBUG-89170 to track
On 12/4/20 5:42 AM, NIkolai Marchenko wrote:
Let's be honest with your users:
P0: almost sure to block a release.
P1: We will act on it if the maintainer is in the mood some day when
it's still fresh
P2: We will fix it, maybe
P3: thank you for informing us.
That's neither helpful nor true.
On 11/25/20 4:22 PM, Thiago Macieira wrote:
What is the one generated in qtbase/lib/cmake/Qt6/qt.toolchain.cmake for?
There, we store information specific to the build of qtbase.
It's passed to CMake when you call qt-cmake / qt-configure-module to
build further parts of Qt.
CMake allows
On 11/24/20 9:32 PM, Thiago Macieira wrote:
Like the "How to build unit tests & examples on demand with Qt6/CMake?"
thread, now I need to build a 32-bit build of Qt but I don't know how.
TL;DR:
need to set PKG_CONFIG_LIBDIR in the environment and pass to cmake:
-DCMAKE_ASM_FLAGS=-m32
On 11/18/20 12:41 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
Tools I don't know if they should or shouldn't be in this list:
- pixeltool: it's a screen magnifier, never used it before, but
clearly not something used at build time. Sounds like a user-facing
app for me.
That's not a tool
On 11/18/20 12:49 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
You need to have a host Qt installed, including qmake.
The cross-built Qt's qmake is a wrapper script that calls the host Qt's
qmake and passes a qt.conf file, adjusting qmake's properties.
This wrapper script in the cross-built
On 11/17/20 9:50 PM, Thiago Macieira wrote:
qt-cmake6
entry point for building CMake-based Qt-applications
Why is this not simply cmake?
Right. For the host Qt in /usr/... this is most probably not needed and
could just be cmake using the global search paths.
Joerg
On 11/17/20 6:07 PM, Thiago Macieira wrote:
3) there's a question of cross-compilation relating to qmake and host tools,
which I have not followed and do not understand the current state of. Need
input here.
The situation is as follows for the cross-building case:
You need to have a host Qt
On 11/13/20 8:24 PM, Sune Vuorela wrote:
Oh. And I'm surprised by the Qt-people sudden love of QtChooser
There's no sudden love. Just surprise that all of a sudden, shortly
before the release, the established solution for co-installability must
be changed.
It is certainly possible to add a
On 9/17/20 11:37 AM, André Hartmann wrote:
I like to propose Alex Trotsenko as approver.
+1 from me as well
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On 8/8/20 12:23 PM, mirchd wrote:
compile environment
Visual Studio Community 2019 Version 16.6.5
qt source git:5.15
windows 10 1803 Chinese (Simplified)
[...]
Please create a bug report at https://bugreports.qt.io/
You're specifying "-nomake tests" but get build errors in tests/auto.
Please
On 6/10/20 4:39 AM, André Pönitz wrote:
Android multi-ABI is currently not implemented, and we don't plan to do it for
6.0.
Isn't Android support part of qtbase?
It is. Android multi-ABI is "building Qt for Android for multiple ABIs
in one go" instead of "building Qt per ABI". The former
On 6/9/20 9:27 AM, Shawn Rutledge wrote:
FWIW the configuration mechanism seems a bit less friendly so far with all
those -DSHOUTED options like -DFEATURE_developer_build=ON instead of configure
-developer-build. But there is cmake-gui, which generates checkboxes for all
the options after
On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:
- is it possible to cross compile Qt in one go (just like we do with qmake)?
Assuming you're talking about the multi-ABI Android build you've added
to Qt5. This is not yet implemented, but certainly possible with the
Ninja Multi-Config
On 5/7/20 10:23 AM, Christian Kandeler wrote:
I'd like to nominate Ivan Komissarov as an approver.
Ivan has been doing valuable work in the qbs project for a while now, both as a
contributor and a reviewer.
I trust him to use his approver rights responsibly.
+1
BR,
Joerg
On 4/24/20 18:10, Giuseppe D'Angelo via Development wrote:
On 4/24/20 8:57 AM, Joerg Bornemann wrote:
Alternatively, proposal 3 (aka "do almost nothing"):
template class QVector { implementation }
template using QList = QVector;
No deprecation of QVector.
No replacemen
On 4/23/20 15:52, Thiago Macieira wrote:
Proposed:
template using QVector = QList; // mark deprecated
template class QList { $(implementation to be moved); }
Proposal 2:
template class QList { $(implementation to be moved); }
template using QVector = QList;
no
On 2/25/20 10:31, Edward Welbourne wrote:
> How about: because we can always over-ride them if we really disagree;
> and their prioritising of the bug is an opening for discussion of why
> it's so important to them - which, after all, we might have missed.
>
> I'd rather have a dialog than a
On 2/18/20 12:17 PM, Edward Welbourne wrote:
> We would presumably want to subsequently rationalise the MS and Unix
> APIs to have a common form, instead of having naked MS types in the API
> for one and something else for the other. That would mean deprecating
> the existing MS-specific API in
On 2/18/20 3:26 AM, Sujan Dasmahapatra wrote:
> QWindow *appWindow = QWindow::fromWinId(process->processId());
That cannot work. QProcess::processId() returns, well, a process id, not
a window handle. You will have to write native code that enumerates all
window handles of the process and if
On 11/22/19 7:21 AM, Kai Pastor, DG0YT wrote:
> Am 21.11.19 um 20:23 schrieb André Pönitz:
>> On Thu, Nov 21, 2019 at 07:48:41PM +0100, Oswald Buddenhagen wrote:
>>> a more radical and much simpler approach would be switching to gettext
>> The most prominent difference is the (usually) per-class
On 11/8/19 9:35 PM, Alessandro Portale wrote:
> I like to propose Cristian Adam as an approver.
+1
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On 8/6/19 1:47 PM, René J. V. Bertin wrote:
> I have a 114Mb big JSON file that I'd like to be able to parse but that is
> rejected because of its size.
>
> Is it possible to rebuild Qt with a larger maximum document size for the JSON
> parser?
Unfortunately, this isn't possible at the moment.
On 6/17/19 5:26 PM, Thiago Macieira wrote:
> On Monday, 17 June 2019 00:04:10 PDT Joerg Bornemann wrote:
>> This will break every user project that's build in debug mode with
>> Visual Studio's toolchain (whichever currently available build tool you
>> use), because it builds
On 6/17/19 6:46 PM, Matthew Woehlke wrote:
> On 17/06/2019 12.08, Bogdan Vatra via Development wrote:
>> Or use a buildsystem that doesn't take to the hell?
>
> Real world experience has shown that there is no such thing.
>
> As much as people like to bitch about how "convoluted" CMake is, CMake
On 6/15/19 12:06 PM, Sérgio Martins via Development wrote:
> The current definition of "debug" for MSVC Qt is:
> 1) Unoptimized (via /O flags)
> 2) Has debug symbols
> 3) Links to another c++ runtime library, which lets you debug into
> (/MDd). (And this is what prevents you from mixing release
On 6/12/19 10:28 AM, Mutz, Marc via Development wrote:
> On 2019-06-12 09:20, Ulf Hermann wrote:
>>> I don't think that (non-)COW is a problem in the scenario under
>>> discussion.
>>
>> Having the thing COW makes the porting simpler at the cost of suboptimal
>> performance. If we wrote a
On 6/5/19 5:49 PM, Mutz, Marc via Development wrote:
> As a library implementer, you are simply not _allowed_ the freedom to
> use a convenient tool over the most efficient one. That is, to put it
> mildly, a disservice to users and a disgrace to the profession of
> programmers. 8KiB just to
On 4/14/19 10:01 PM, Martin Koller wrote:
> I have updated https://codereview.qt-project.org/#/c/177571/
> but Qt Sanity Bot does not check it.
> Why ?
> I have now a +2 from Bogdan but can not merge.
The bot seems to be back again, and the change is merged.
Note that you can manually assign a
On 4/2/19 5:14 PM, Mitch Curtis wrote:
> As described in https://bugreports.qt.io/browse/QTBUG-66320, currently Qt
> users are on their own if they want to call helper functions that can fail a
> test. The reason is documented:
>
> Note: This macro can only be used in a test function that
On 3/21/19 5:39 PM, Tobias Hunger wrote:
> We do not want to port all the qmake-quirks over to cmake. We get enough
> quirks
> for free straight from cmake:-)
I believe that this means a reduced feature set for the CMake port.
What kind of things do we expect to go away that we take for granted
On 3/21/19 5:01 PM, Alex Blasche wrote:
- We can synchronize CMakeFiles and *.pro files
>>> I do not understand this part.
>> We can ask people to update CMakeFiles after updating pro files.
>
> I don't think that you can make this a requirement at this point in time. You
> may find
On 27/02/2019 07:59, J-P Nurmi wrote:
> Is it technically possible to start() and then detach()?
>
> QProcess process;
> process.setFoo(...);
> process.start(...);
> process.waitForBar();
> process.read(...);
> process.detach();
In principle, yes. But what happens when detaching a process
On 27/02/2019 11:03, Konstantin Shegunov wrote:
> ]...] I use the static `QProcess::startDetached`
> to start the daemon and detach from the controlling terminal (on Linux).
> I need *AN* API to do this, otherwise I'd have to (re)implement
> double-forking myself. If there are changes I'm
On 2/18/19 1:49 PM, xinxin wrote:
> freetype 2.8 add a new render mode, Qt program ugly than gtk program on
> linux now
That's this bugreport: https://bugreports.qt.io/browse/QTBUG-73855
Please let's continue the discussion there.
BR,
Joerg
___
On 1/18/19 2:26 PM, Simon Hausmann wrote:
>
> I’m a fan of the idea that for Qt6 we remove all copies of third party
> libraries and provide convenient binaries of them in the qt installed (as
> separate package in there) as well as via vcpkg for those wanting to build
> from source.
>
> Flex
On 1/7/19 1:51 PM, Alex Blasche wrote:
> After Ossi stepping down as maintainer for Linguist and related tools
> (lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a
> long history working on Qt and even more specifically with Qt's translation
> tools.
+1
[insert
On 12/19/18 4:43 PM, Tobias Hunger wrote:
> I want to propose Christian Kandeler to take over. He is a capable
> developer with a deep understanding of the code involved and I am sure
> he will do a terrific job going forward.
+1
Disclaimer: He knows where I park my bicycle.
BR,
Joerg
On 10/30/18 12:16 PM, Bogdan Vatra via Development wrote:
Late to the game, but I feel the urge to comment on some things.
> c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and I
> found some problems, see how QBS developers treat them here: https://
>
On 08/08/2018 01:41 PM, Edward Welbourne wrote:
I'm not the only one :
https://github.com/search?p=1=QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS=Code
This URL got me:
We could not perform this search
Must include at least one user, organization, or repository
so I'm none
On 08/02/2018 10:05 AM, BogDan Vatra via Development wrote:
Well, if we want to have first class Qt on Android support, this feature
is a
must. Now, if we can use it also for other platforms that's a
bonus.
Which feature exactly? Creating binaries for multiple targets in on compile
run?
On 08/02/2018 08:18 AM, Simon Hausmann wrote:
Given that the output of the moc changes depending on what platform and
compiler dependent pre-processor macros are supplied, I would say that the
output is not cross-platform.
...which is why qbs does *not* have such a feature.
moc_XXX.cpp and
On 07/25/2018 05:12 PM, Alex Blasche wrote:
I'd like to nominate Miguel for approver rights.
+1
Disclaimer: He's sitting next to Oliver.
Joerg
___
Development mailing list
Development@qt-project.org
On 04/27/2018 10:58 AM, Michal Klocek wrote:
I would like to nominate Jüri Valdmann for Approver.
+1
Disclaimer: he's sitting next to me.
BR,
Joerg
___
Development mailing list
Development@qt-project.org
On 04/11/2018 02:06 PM, Edward Welbourne wrote:
That sounds like a promising line of enquiry - except that I can't find
where we generate target_wrapper.sh - the word target_wrapper doesn't
appear to exist in our source tree (aside from a couple of .gitignore
files).
The wrapper script is
On 01/09/2018 09:09 AM, Igor Mironchik wrote:
What is gerrit cover message? Is it a comment message on gerrit CR web
page?
Yes, that's just a comment in gerrit's web interface.
The label above the text edit says "cover message".
Joerg
___
1 - 100 of 181 matches
Mail list logo
